Terima kasih, pencerahannya, terima kasih Pak Tommy, dan Pak Ujang
Imansyah --- Tomi Wijanto <[EMAIL PROTECTED]> wrote: > > 1. Saya mau tanya kegunaan script ini > > alter session set events = 'immediate trace name > > flush_cache'; > > Perintah di atas akan membersihkan memori > buffer_cache > di oracle. Biasanya di jalankan di oracle versi 9i > (gak yakin kalau bisa dijalankan di < 9i). > Kalau di oracle 10g, fungsi yg sama telah tersedia > dengan command: > alter system flush buffer_cache; > > > 3. Apakah dengan perintah ini, apabila database > > dalam keadaan peak bisa "normal" kembali, / tidak > > berat ? > > Perintah tsb biasanya tidak utk dijalankan di > production. Kegunaannya lebih utk testing. Misalkan > Anda ingin membandingkan performance I/O dari query > di > database yg berbeda, utk menghindari data yg diquery > sudah tersimpan di memori buffer, maka buffer_cache > di > flush di kedua db tsb. > > Kalau di lakukan di production, impactnya semua blok > data yg telah ada di buffer akan dihapus. Efeknya, > blok2 tsb harus kembali diambil dari disk yg jauh > lebih lama aksesnya dibandingkan memori. Jadi > efeknya > justru sangat jelek. > > > 2. Bagaimana release process yang sudah dikill > > (remark > > to kill) tidak menggantung lagi > > Biasanya, session tidak bisa di kill karena sedang > melakukan sesuatu yang agak berat. Misalkan saja > update/delete dalam jumlah yg besar, atau transaksi > terdistribusi melalui dblink. Setelah bbrp saat > (bisa > lama juga sih), normalnya proses pmon akan > membersihkan proses tsb. Saya rasa itu normal > karena > oracle harus menjaga konsistensi data. > Kecuali Anda melihat kalau proses tersebut terus > memakan resource dan tetap exist dalam waktu yg > lama. > Untuk itu lebih baik kontak oracle support > (metalink). > > > 4. Untuk server database bagaimana mengatur > downtime > > yang bagus. > > > > terima kasih > > > > Imansyah > > > > down-timenya pada saat database tidak dipakai user > :)..hehe.. > > Secara garis besar kita memiliki 2 jenis downtime, > yg > direncanakan (misal: apply patch, reorganisasi data) > dan tidak direncanakan (misal: db/server > crash,bencana > alam). > Umumnya kita berusaha meminimalkan impact dari > setiap > downtime terhadap bisnis. > > Downtime yg direncanakan mungkin tidak terlalu > masalah, yang penting eksekusi harus sesuai dengan > yg > direncanakan, makanya perlu di-test berulang2 > sebelum > dijalankan di production. > > Downtime yg tidak direncanakan inilah yg mesti > dipersiapkan utk seminimal mungkin. Misalnya > menggunakan cluster utk proteksi thd server/instance > crash, menggunakan standby db utk proteksi thd > bencana; duplikasi jalur network, disk, ups. > Seberapa > tinggi high-availability yg ingin dicapai akan > dibatasi oleh cost utk implementasi. Jadi perlu > justifikasi bisnis disini. > > Cuma utk hal yg basic, pastikan dulu untuk > mendapatkan > database yang stabil, sehingga database tidak > sering2 > down hanya karena masalah sepele. Pastikan > konfigurasi > database sudah benar, jumlah disk yg dialokasikan > cukup, aplikasi terkontrol, dan resource cpu/memori > memang reasonable sesuai dgn workload. > > > regards, > tomi > > > > > ____________________________________________________________________________________ > Get your own web address. > Have a HUGE year through Yahoo! Small Business. > http://smallbusiness.yahoo.com/domains/?p=BESTDEAL > ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
