Untuk menyelesaikan rangkaian artikel singkat saya tentang kait, kali ini saya akan membahas beberapa kait lain di SQL Server yang mungkin kadang-kadang Anda lihat tetapi tidak layak mendapatkan artikel lengkap sendiri. Seperti biasa, saya sangat menyarankan Anda membaca posting awal dalam seri sebelum yang satu ini, sehingga Anda memiliki semua latar belakang pengetahuan umum tentang kait.
Kunci LOG_MANAGER
Kait LOG_MANAGER digunakan untuk sinkronisasi selama beberapa operasi yang melibatkan log transaksi, dan ada satu kait LOG_MANAGER per database (karena setiap database memiliki manajer log sendiri). Itu hanya dapat diperoleh dalam mode eksklusif dan dapat menjadi hambatan selama pertumbuhan file log transaksi. Skenario di mana itu akan menjadi jelas sebagai masalah adalah:
- File log memiliki kumpulan pertumbuhan otomatis kecil
- Ada banyak koneksi bersamaan yang menghasilkan catatan log transaksi
- File log terus bertambah
Ketika file log kehabisan ruang, itu perlu tumbuh. Utas pertama untuk mewujudkan lebih banyak ruang log diperlukan memperoleh kait LOG_MANAGER dalam mode EX dan melanjutkan untuk mengembangkan file log. Banyak utas lainnya terus mencoba menghasilkan catatan log dan masuk ke antrean untuk kait LOG_MANAGER, sehingga mereka dapat mengembangkan file log. Ketika utas pertama melepaskan kait, utas berikutnya mendapatkannya dan menyadari bahwa log telah tumbuh, jadi lepaskan dan lanjutkan. Dan seterusnya dan seterusnya. Kebetulan, pola kemacetan ini disebut konvoi kait .
Anda dapat menganggapnya sebagai hambatan yang sama persis dengan kait FGCB_ADD_REMOVE yang saya bahas sebelumnya di seri ini, tetapi dengan pertumbuhan file log alih-alih pertumbuhan file data. Namun, dengan kait FGCB_ADD_REMOVE, biasanya instans memiliki inisialisasi file instan yang diaktifkan, sehingga pertumbuhan file sangat cepat, tetapi dengan kait LOG_MANAGER, log *harus* diinisialisasi nol, dan waktu yang terbuang dalam antrian kait lebih lama .
Solusi untuk kemacetan ini memiliki tiga bagian:
- Atur pertumbuhan otomatis file log dengan benar, sehingga log tidak sering bertambah
- Ukuran log dengan benar untuk beban kerja, sehingga log tidak boleh bertambah sama sekali
- Pastikan log terhapus dengan benar, jadi log tidak perlu bertambah
Jika semua ini ada, Anda tidak akan melihat kait LOG_MANAGER menjadi hambatan biasa, dan saya akan membicarakan lebih lanjut tentang ini di postingan saya di sini.
ACCESS_METHODS_DATASET_PARENT Kait
Saat heap atau indeks sedang diakses, secara internal ada objek yang disebut HeapDataSetSession atau IndexDataSetSession. Ketika pemindaian paralel sedang dilakukan, utas yang melakukan pekerjaan sebenarnya dari pemindaian masing-masing memiliki kumpulan data "anak" (contoh lain dari dua objek yang baru saja saya jelaskan), dan kumpulan data utama, yang benar-benar mengendalikan pemindaian, disebut "orang tua".
Ketika salah satu utas pekerja pemindaian telah kehabisan set baris yang seharusnya dipindai, ia perlu mendapatkan rentang baru dengan mengakses kumpulan data induk, yang berarti memperoleh kait ACCESS_METHODS_DATASET_PARENT dalam mode eksklusif. Meskipun ini tampak seperti hambatan, sebenarnya tidak, dan tidak ada yang dapat Anda lakukan untuk menghentikan rangkaian yang melakukan pemindaian paralel agar tidak sesekali menampilkan LATCH_EX menunggu kait ini.
Pertanyaan yang harus Anda tanyakan pada diri sendiri adalah:haruskah kueri ini melakukan pemindaian paralel? Sangat mungkin terjadi sesuatu yang memaksa rencana kueri untuk menyertakan pemindaian paralel ketika itu mungkin bukan cara yang paling efisien untuk menjalankan kueri. Contoh hal yang dapat menyebabkan rencana berubah menjadi pemindaian paralel meliputi:
- Statistik kedaluwarsa
- Indeks nonclustered hilang atau hilang
- Kode baru yang memaksa pemindaian karena konversi implisit—ketidakcocokan tipe data antara kolom dan variabel/parameter, yang menghalangi penggunaan indeks nonclustered
- Kode baru memaksa pemindaian karena aritmatika dilakukan pada kolom tabel alih-alih variabel/parameter, yang sekali lagi menghalangi penggunaan indeks nonclustered
- Terjadi pertumbuhan data dan pemindaian adalah rencana yang paling efisien
Atau bisa juga kueri ini memerlukan pemindaian, dalam hal ini LATCH_EX menunggu ACCESS_METHODS_DATASET_PARENT hanyalah bagian dari lingkungan Anda.
ACCESS_METHODS_HOBT_VIRTUAL_ROOT Kait
Setiap instance dari latch ini melindungi entri dalam metadata Storage Engine untuk b-tree, khususnya ID halaman dari halaman root b-tree (halaman di bagian atas segitiga yang biasanya kita anggap sebagai indeks) . Saya secara khusus mengatakan b-pohon dan bukan indeks , karena indeks dapat memiliki beberapa partisi, masing-masing memiliki b-tree (pada dasarnya sebagian dari keseluruhan indeks, tetapi dengan batasan kunci bernilai rendah dan bernilai tinggi).
Setiap kali sebuah utas perlu melintasi b-tree, ia harus mulai dari halaman root dan turun ke tingkat daun. Untuk membaca metadata yang berisi ID halaman halaman root, utas harus memperoleh kait ACCESS_METHODS_HOBT_VIRTUAL_ROOT dalam mode SH, untuk memastikan ID halaman tidak dalam proses perubahan. Saat utas perlu mengubah ID halaman dari halaman root, utas tersebut harus mendapatkan kait dalam mode EX.
Mengapa halaman root dari b-tree pernah berubah? Seiring bertambahnya jumlah catatan indeks di halaman root, akhirnya akan terisi dan pemisahan halaman akan terjadi. Ketika itu terjadi, halaman root saat ini dan halaman yang dipecah menjadi level baru di b-tree, dan halaman root baru dibuat, dengan dua catatan indeks, menunjuk ke halaman root lama dan halaman itu dibagi menjadi. ID halaman root baru harus dimasukkan ke dalam metadata, sehingga kait diperoleh dalam mode EX. Ini akan terjadi beberapa kali dengan cepat saat indeks pada tabel kosong mulai diisi oleh sisipan, tetapi bukan sesuatu yang akan Anda lihat sebagai masalah kemacetan kinerja yang sedang berlangsung.
Ringkasan
Seperti yang saya yakin Anda telah kumpulkan dari seri ini, memahami latch dan bottleneck latch melibatkan mengetahui lebih banyak tentang apa yang terjadi di dalam Storage Engine daripada analisis statistik tunggu umum.
Saya biasanya menyarankan orang *tidak* untuk memulai pemecahan masalah kinerja dengan melihat statistik kait (melalui sys.dm_os_latch_stats ) tetapi untuk selalu memulai dengan statistik menunggu (lihat posting saya di sini) dan hanya menyelidiki kait jika LATCH_EX atau LATCH_SH adalah salah satu dari segelintir waktu tunggu teratas pada contoh SQL Server.
Jika Anda memiliki pertanyaan tentang kait, jangan ragu untuk menghubungi saya.
