> 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
