Berikut adalah beberapa acara tunggu Oracle Umum yang harus diketahui semua orang.
Menunggu acara
Anda dapat menemukan sesi acara mana yang menunggunya dengan mengikuti kueri
select event from V$session_wait where sid=&1
Saya mencoba menjelaskan beberapa acara tunggu Oracle yang umum, ada penyebab dan penyelesaiannya
antrean
Proses sedang menunggu di oracle enqueue (kunci yang dapat Anda lihat di v$lock). Ini biasanya terjadi ketika satu pengguna mencoba memperbarui baris dalam tabel yang sedang diperbarui oleh pengguna lain. Pemblokir dapat diketahui dengan menggunakan kueri berikut
select * from dba_waiters
pin cache perpustakaan
Proses ingin menyematkan objek dalam memori di cache perpustakaan untuk pemeriksaan, memastikan tidak ada proses lain yang dapat memperbarui objek pada saat yang sama. Ini terjadi ketika Anda mengkompilasi atau mengurai objek atau tampilan PL/SQL. Hindari mengkompilasi objek PL/SQL atau tampilan Oracle pada waktu penggunaan yang tinggi untuk menghindari acara menunggu ini
kunci pemuatan cache perpustakaan
Proses sedang menunggu kesempatan untuk memuat objek atau bagian dari objek ke dalam cache perpustakaan. (Hanya satu proses yang dapat memuat objek atau bagian objek pada satu waktu.)
bebas kait
Proses sedang menunggu latch yang dipegang oleh proses lain. (Acara menunggu ini tidak berlaku untuk proses yang berputar sambil menunggu latch; ketika sebuah proses berputar, itu tidak menunggu.). Latches adalah perangkat serialisasi ringan yang digunakan untuk mengoordinasikan akses multi-pengguna ke struktur data, objek, dan file.
Latches adalah kunci yang dirancang untuk dipegang dalam jangka waktu yang sangat singkat misalnya, waktu yang diperlukan untuk mengubah struktur data dalam memori. Mereka digunakan untuk melindungi struktur memori tertentu, seperti cache buffer blok database atau cache library di kumpulan bersama.
Oracle Latches biasanya diminta secara internal dalam mode 'bersedia menunggu'. Ini berarti bahwa jika kait tidak tersedia, sesi yang meminta akan tidur untuk waktu yang singkat dan mencoba lagi operasi nanti. Kait lain mungkin diminta dalam mode 'segera', yang konsepnya mirip dengan SELECT FOR UPDATE NO-WAIT, artinya proses akan melakukan sesuatu yang lain, seperti mencoba mengambil kait saudara setara yang mungkin gratis, daripada duduk dan menunggu kait ini tersedia. Karena banyak permintaan mungkin menunggu latch pada saat yang sama, Anda mungkin melihat beberapa proses menunggu lebih lama daripada yang lain.
Kait diberikan agak acak, berdasarkan keberuntungan undian, jika Anda mau. Sesi mana pun yang meminta kait tepat setelah dirilis akan mendapatkannya. Tidak ada antrian pelayan hanya segerombolan pelayan yang terus mencoba lagi.
buffer sibuk menunggu
Proses ingin mengakses blok data yang saat ini tidak ada di memori, tetapi proses lain telah mengeluarkan permintaan I/O untuk membaca blok ke memori. (Proses sedang menunggu proses lain selesai membawa blok ke memori.). Blok panas dapat ditemukan menggunakan tampilan V$BH
file db tersebar baca
Proses telah mengeluarkan permintaan I/O untuk membaca serangkaian blok yang berdekatan dari file data ke dalam buffer cache, dan menunggu operasi selesai. Ini biasanya terjadi selama pemindaian tabel penuh atau pemindaian indeks penuh.
Kami harus memeriksa apakah kueri harus menggunakan pemindaian tabel lengkap. Pastikan statistik pengoptimal Oracle mutakhir. Gunakan pemangkasan Partisi untuk mengurangi jumlah blok yang dikunjungi
Jika kueri yang telah berjalan dengan baik untuk sementara waktu tiba-tiba mencatat banyak waktu pada file db yang tersebar acara baca dan belum ada perubahan kode, Anda mungkin ingin memeriksa untuk melihat apakah satu atau lebih indeks telah dijatuhkan atau menjadi tidak dapat digunakan.
pembacaan berurutan file db
Proses telah mengeluarkan permintaan I/O untuk membaca satu blok dari file data ke cache buffer, dan menunggu operasi selesai. Ini biasanya terjadi selama pencarian indeks atau pengambilan dari tabel oracle oleh ROWID ketika blok data yang diperlukan belum ada di memori. Jangan terkecoh dengan nama yang membingungkan dari acara tunggu ini!
Kita harus memeriksa apakah indeks yang tepat digunakan. Indeks yang salah dapat membuat kueri berkinerja buruk. Pastikan statistik pengoptimal adalah yang terbaru.
pembacaan paralel file db
Proses telah mengeluarkan beberapa permintaan I/O secara paralel untuk membaca blok dari file data ke dalam memori, dan menunggu semua permintaan selesai. Dokumentasi mengatakan bahwa acara tunggu ini hanya terjadi selama pemulihan, tetapi sebenarnya itu juga terjadi selama aktivitas reguler ketika suatu proses mengelompokkan banyak permintaan I/O blok tunggal dan mengeluarkannya secara paralel. (Terlepas dari namanya, Anda tidak akan melihat peristiwa tunggu ini selama kueri paralel atau DML paralel. Dalam kasus tersebut, peristiwa tunggu dengan PX dalam namanya terjadi sebagai gantinya.)
penulisan paralel file db
Proses, biasanya DBWR, telah mengeluarkan beberapa permintaan I/O secara paralel untuk menulis blok kotor dari cache buffer ke disk, dan menunggu semua permintaan selesai.
baca jalur langsung, tulis jalur langsung
Proses telah mengeluarkan permintaan I/O asinkron yang melewati cache buffer, dan menunggu sampai selesai. Peristiwa menunggu ini biasanya melibatkan segmen pengurutan.
Pernyataan SQL dengan fungsi yang memerlukan sortir, seperti ORDER BY, GROUP BY, UNION, DISTINCT, dan ROLLUP, write sort berjalan ke tablespace sementara ketika ukuran input lebih besar dari area kerja di PGA
Pastikan statistik pengoptimal sesuai dengan data dan kueri menggunakan tabel penggerak yang tepat. Periksa untuk melihat apakah kolom indeks komposit dapat diatur ulang agar sesuai dengan klausa ORDER BY untuk menghindari pengurutan seluruhnya.
Pastikan nilai yang sesuai PGA_AGGREGATE_TARGET disetel. Jika memungkinkan, gunakan UNION ALL daripada UNION.
Kait kolam bersama
Kait kumpulan bersama digunakan untuk melindungi operasi penting saat mengalokasikan dan mengosongkan memori di kumpulan bersama. Perselisihan untuk kumpulan bersama dan kait cache perpustakaan terutama disebabkan oleh penguraian keras yang intens. Penguraian keras berlaku untuk kursor dan kursor baru yang sudah usang dan harus dijalankan kembali
Biaya penguraian pernyataan SQL baru mahal baik dari segi persyaratan CPU maupun frekuensi cache pustaka dan kumpulan bersama kait mungkin perlu diperoleh dan dilepaskan.
Menghilangkan SQL literal juga berguna untuk menghindari kunci kumpulan bersama
mengontrol pembacaan berurutan file
Proses menunggu blok dibaca dari file kontrol. Ini terjadi secara umum
- membuat cadangan file kontrol
- berbagi informasi (antar kejadian) dari file kontrol
- membaca blok lain dari file kontrol
- membaca blok header
Jika ini adalah acara tunggu utama, itu berarti lokasi file kontrol perlu diubah ke lokasi disk yang lebih cepat
kontrol penulisan paralel file
Proses telah mengeluarkan beberapa permintaan I/O secara paralel untuk menulis blok ke semua file kontrol, dan menunggu semua penulisan selesai.
ruang buffer log
Proses menunggu ruang tersedia di buffer log (Ruang hanya tersedia setelah LGWR menulis konten buffer log saat ini ke disk.) Ini biasanya terjadi saat aplikasi menghasilkan redo lebih cepat daripada yang bisa ditulis LGWR ke disk.
Ini juga bisa terjadi, jika I/O ke disk tempat redo log berada lambat
Seharusnya tidak ada ruang buffer log yang menunggu seperti itu di database. Pertimbangkan untuk membuat buffer log lebih besar jika kecil atau pertimbangkan untuk memindahkan file log ke disk yang lebih cepat seperti disk bergaris.
Select event, total_waits, total_timeouts, time_waited, average_wait
from v$system_event
where event = 'log buffer space';
Select sid, event, seconds_in_wait, state
from v$session_wait
where event = 'log buffer space';
Select name, value
from v$sysstat
where name in ('redo log space requests');
The pct_buff_alloc_retries harus nol atau kurang dari 0,01 (<1%). Jika lebih besar pertimbangkan untuk membuat buffer log lebih besar. Jika lebih besar pertimbangkan untuk memindahkan file log ke disk yang lebih cepat seperti disk bergaris.
Select v1.value as redo_buff_alloc_retries, v2.value as redo_entries, trunc(v1.value/v2.value,4) as pct_buff_alloc_retries from v$sysstat v1, v$sysstat v2 where v1.name = 'redo buffer allocation retries' and v2.name = 'redo entries';
file log baca berurutan
Proses menunggu blok dibaca dari online redo log ke memori. Ini terutama terjadi saat startup instans dan ketika arsip proses ARCH mengisi log redo online.
penulisan paralel file log
Proses menunggu blok ditulis ke semua anggota redo log online dalam satu grup. LGWR biasanya satu-satunya proses untuk melihat acara menunggu ini. Itu akan menunggu sampai semua blok telah ditulis ke semua anggota.
sinkronisasi file log
Proses menunggu LGWR untuk menyelesaikan flushing buffer log ke disk. Ini terjadi ketika pengguna melakukan transaksi. (Sebuah transaksi tidak dianggap berkomitmen sampai semua pengulangan untuk memulihkan transaksi telah berhasil ditulis ke disk.)
Proses LGWR yang lambat dapat memperkenalkan waktu tunggu sinkronisasi file log yang membuat pengguna mengalami waktu tunggu selama komit atau rollback. Peristiwa menunggu penulisan paralel file log dan sinkronisasi file log saling terkait dan harus ditangani secara bersamaan.
Kita harus mencoba mengalokasikan log redo ke disk performa tinggi (Solid state disk). Kita juga harus mencoba mengurangi beban pada LGWR dengan mengurangi komit dalam aplikasi.
Bagian hot-backup manual juga dapat menimbulkan stres pada sistem dengan menghasilkan banyak hal yang diulang, Jadi hindari itu selama waktu sibuk
Terkadang LGWR kekurangan resource CPU. Jika server sangat sibuk, maka LGWR juga dapat kekurangan CPU. Ini akan menyebabkan respons yang lebih lambat dari LGWR, meningkatkan 'sinkronisasi file log'. Bagaimanapun, panggilan sistem dan panggilan I/O ini harus menggunakan CPU. Dalam hal ini, 'sinkronisasi file log' adalah gejala sekunder dan menyelesaikan akar penyebab penggunaan CPU yang tinggi akan mengurangi waktu tunggu 'sinkronisasi file log'.
Karena masalah kekurangan memori, LGWR juga dapat dihapus. Hal ini juga dapat menyebabkan respons yang lebih lambat dari LGWR.
mengurungkan ekstensi segmen
Sesi sedang menunggu segmen urung diperpanjang atau diciutkan.
tulis tunggu lengkap
Sesi sedang menunggu buffer yang diminta untuk ditulis ke disk; buffer tidak dapat digunakan saat sedang ditulis.
Latch:rantai buffer cache
Kait rantai buffer cache digunakan untuk melindungi daftar buffer di cache buffer. Kait ini digunakan saat mencari, menambahkan, atau menghapus buffer dari cache buffer.
Blok dalam cache buffer ditempatkan pada daftar tertaut (rantai buffer cache) yang menggantung dari tabel hash. Rantai hash tempat blok ditempatkan didasarkan pada DBA dan KELAS dari blok tersebut. Setiap rantai hash dilindungi oleh satu kait anak. Proses perlu mendapatkan kait yang relevan untuk memungkinkan mereka memindai rantai hash untuk buffer sehingga daftar tertaut tidak berubah di bawahnya.
Perselisihan pada gerendel ini biasanya berarti ada blok yang sedang dalam perebutan hebat (dikenal sebagai blok panas).
Untuk mengidentifikasi rantai buffer yang banyak diakses, dan karenanya bersaing untuk blok, lihat statistik latch untuk kait rantai buffer cache menggunakan tampilan V$LATCH_CHILDREN. Jika ada cache buffer chains child latch tertentu yang memiliki lebih banyak GETS, MISSES, dan SLEEPS jika dibandingkan dengan child latches lainnya, maka ini adalah persaingan untuk child latch.
Kait ini memiliki alamat memori, yang diidentifikasi oleh kolom ADDR.
SELECT addr, sleeps FROM v$latch_children c, v$latchname n WHERE n.name='cache buffers chains' and c.latch#=n.latch# and sleeps > 100 ORDER BY sleeps /
Gunakan nilai dalam kolom ADDR yang digabungkan dengan tampilan V$BH untuk mengidentifikasi blok yang dilindungi oleh kait ini. Misalnya, mengingat alamat (V$LATCH_CHILDREN.ADDR) dari kait yang diperebutkan, ini menanyakan nomor file dan blok:
SELECT file#, dbablk, class, state, TCH FROM X$BH WHERE HLADDR='address of latch';
X$BH.TCH adalah hitungan sentuhan untuk buffer. Nilai tinggi untuk X$BH.TCH menunjukkan blok panas.
Banyak blok dilindungi oleh setiap kait. Salah satu buffer ini mungkin akan menjadi blok panas. Setiap blok dengan nilai TCH tinggi adalah blok panas potensial. Lakukan kueri ini beberapa kali, dan identifikasi blok yang muncul secara konsisten di output.
Setelah Anda mengidentifikasi blok panas, kueri DBA_EXTENTS menggunakan nomor file dan nomor blok untuk mengidentifikasi segmen.
Informasi Penting tentang acara tunggu
Tampilan v$session_wait menampilkan informasi tentang acara tunggu yang sedang menunggu sesi aktif. Berikut adalah deskripsi tampilan ini, dan berisi beberapa kolom yang sangat berguna, terutama referensi P1 dan P2 ke objek yang terkait dengan peristiwa wait.
desc v$session_wait Name Null? Type --------------------------- -------- ------------ SID NUMBER SEQ# NUMBER EVENT VARCHAR2(64) P1TEXT VARCHAR2(64) P1 NUMBER P1RAW RAW(4) P2TEXT VARCHAR2(64) P2 NUMBER P2RAW RAW(4) P3TEXT VARCHAR2(64) P3 NUMBER P3RAW RAW(4) WAIT_CLASS_ID NUMBER WAIT_CLASS# NUMBER WAIT_CLASS VARCHAR2(64) WAIT_TIME NUMBER SECONDS_IN_WAIT NUMBER STATE VARCHAR2(19)
Menggunakan v$session_wait, mudah untuk menginterpretasikan setiap parameter peristiwa wait menggunakan kolom teks deskriptif yang sesuai untuk parameter tersebut. Juga, kolom kelas tunggu ditambahkan sehingga berbagai acara tunggu dapat dikelompokkan ke dalam area pemrosesan terkait seperti jaringan, aplikasi, idle, konkurensi, dll.
Kolom ini juga ditambahkan ke tabel v$session mulai 10g dan seterusnya . Jadi Anda bisa menggunakan v$session untuk menemukan semua detailnya
Setiap peristiwa tunggu berisi parameter lain yang memberikan informasi tambahan tentang peristiwa tersebut.
Cara menemukan informasi tentang peristiwa tunggu dan parameternya
The meaning of each wait event corresponds know by querying the V$EVENT_NAME p1, p2, p3 of col name format a25; col p1 format a10; col p2 format a10; col p3 format a10; SELECT NAME, PARAMETER1 P1, PARAMETER2 P2, PARAMETER3 P3 FROM V$EVENT_NAME WHERE NAME = '&event_name';
Katakanlah misalnya kita mengambil
Nilai input event_name:file db tersebar baca
Nilai asli 3:WHERE NAME =‘&event_name A’
Nilai baru 3:WHERE NAME =‘file db tersebar baca’
Nama P1 P2 P3
file db tersebar baca file # blok # blok
file #:nomor file data
Block #:nomor blok awal
blok:untuk membaca nomor blok data
Sekarang mari kita lihat bagaimana informasi di atas dapat membantu kita menangkap berbagai hal
Misalkan sesi tertentu menunggu acara buffer busy waitings, objek database yang menyebabkan acara wait ini dapat dengan mudah ditentukan:
select username, event, p1, p2 from v$session_wait where sid = 4563;
Keluaran kueri ini untuk sesi tertentu dengan SID 4563 mungkin terlihat seperti ini:
USERNAME EVENT SID P1 P2 ---------- ----------------- --- -- --- APPS buffer busy waits 4563 11 545
Kolom P1 dan P2 memungkinkan DBA untuk menentukan nomor file dan blok yang menyebabkan peristiwa menunggu ini. Kueri di bawah ini mengambil nama objek yang memiliki blok data 155, nilai P2 di atas:
SQL> select segment_name,segment_type from dba_extents where file_id = 11 and 45 between block_id and block_id + blocks – 1;
Kemampuan untuk menganalisis dan memperbaiki peristiwa tunggu Oracle Database sangat penting dalam proyek penyesuaian apa pun. Sebagian besar aktivitas dalam database melibatkan pembacaan data, sehingga jenis penyetelan ini dapat memberikan dampak positif yang besar pada kinerja.
Catatan:Saat melakukan analisis menunggu, penting untuk diingat bahwa semua database Oracle mengalami peristiwa menunggu, dan kehadiran menunggu tidak selalu menunjukkan masalah. Faktanya, semua basis data yang disetel dengan baik memiliki beberapa hambatan.
kita bisa menggunakan 10046 event untuk melacak event wait dari sesi juga
Juga Dibaca
Dokumentasi Oracle
v$active_session_history
Menjelaskan Paket di Oracle
