LATCH_EX Menunggu pada Sumberdaya METADATA_SEQUENCE_GENERATOR

Kami memiliki proses yang menghasilkan laporan inventaris. Di sisi klien, proses memisahkan sejumlah utas pekerja yang dapat dikonfigurasi untuk membangun sepotong data untuk laporan yang sesuai dengan satu penyimpanan dari banyak (berpotensi ribuan, biasanya lusinan). Setiap utas pekerja memanggil layanan web yang menjalankan prosedur tersimpan.

Proses basis data untuk memproses setiap chunk mengumpulkan banyak data ke dalam tabel #T Temporary. Pada akhir setiap potongan pemrosesan, data ditulis ke tabel permanen di tempdb. Akhirnya, pada akhir proses, satu utas di sisi klien meminta semua data dari tabel tempdb permanen.

Semakin banyak pengguna yang menjalankan laporan ini, semakin lambat hasilnya. Saya menganalisis aktivitas dalam database. Pada satu titik, saya melihat 35 permintaan terpisah semua diblokir pada satu titik dalam proses. Semua SPID ini memiliki urutan 50 ms menunggu jenis LATCH_EXsumber daya METADATA_SEQUENCE_GENERATOR (00000010E13CA1A8). Satu SPID memiliki sumber ini, dan yang lainnya memblokir. Saya tidak menemukan apa pun tentang sumber daya tunggu ini di pencarian web.

Tabel di tempdb yang kami gunakan memang memiliki IDENTITY(1,1)kolom. Apakah SPID ini menunggu kolom IDENTITAS? Metode apa yang bisa kita gunakan untuk mengurangi atau menghilangkan pemblokiran?

Server adalah bagian dari sebuah cluster. Server menjalankan 64-bit SQL Server 2012 Standard Edition SP1 pada 64-bit Windows 2008 R2 Enterprise. Server memiliki 64 GB RAM dan 48 prosesor, tetapi database hanya dapat menggunakan 16 karena ini adalah edisi standar.

(Perhatikan bahwa saya tidak senang dengan desain menggunakan tabel permanen di tempdb untuk menampung semua data ini. Mengubah itu akan menjadi tantangan teknis dan politik yang menarik, tapi saya terbuka untuk saran.)

PEMBARUAN 4/23/2013

Kami telah membuka kasing dukungan dengan Microsoft. Saya akan terus memperbarui pertanyaan ini saat kami mempelajari lebih lanjut.

UPDATE 5/10/2013

Insinyur dukungan SQL Server setuju bahwa menunggu disebabkan oleh kolom IDENTITAS. Menghapus IDENTITAS menghilangkan menunggu. Kami tidak dapat menduplikasi masalah pada SQL 2008 R2; itu terjadi hanya pada SQL 2012.

Dengan asumsi Anda dapat mengisolasi masalah ke generasi nilai identitas (coba hapus kolom itu sebagai ujian), apa yang saya sarankan adalah ini:

1. Hapus IDENTITYproperti dari kolom di tabel final.
2. Hasilkan nilai identitas di masing-masing tabel #T Temporary.
3. Saat memuat tabel akhir, gabungkan pengidentifikasi numerik untuk toko tertentu dengan nilai identitas dari langkah 2.

Jadi, jika Anda memiliki id toko 3 dan 4, Anda akan mendapatkan nilai id akhir seperti ini:

3000000001
3000000002
3000000003
...
4000000001
4000000002
...

Atau sesuatu yang mirip dengan itu. Anda mendapatkan idenya.

Ini akan menghilangkan kebutuhan untuk membuat serial tentang IDENTITYgenerasi sambil mempertahankan keunikan dalam hasil akhir.

Atau, tergantung pada bagaimana prosesnya bekerja, masukkan nilai id akhir yang dihitung ke dalam tabel #Tentara. Kemudian Anda bisa membuat tampilan yang UNION ALLmenyatukan mereka, menghilangkan kebutuhan untuk menyalin data sama sekali.

(Diperbarui Februari 2019)

Ini adalah posting lama, yang mengatakan bahwa saya akhirnya berhasil meyakinkan Microsoft bahwa fakta yang terjadi memang cacat.

Pembaruan: MS Mengonfirmasi kerusakan dan menetapkannya sebagai bug # of 12628722.

Saya telah melihat posting ini pada November 2018 yang lalu ketika kita mulai menderita hal yang sama setelah kita meningkatkan dari Sql Server 2005 ke Sql Server 2017. Tabel 3,3 juta baris yang digunakan untuk mengambil 10 detik untuk memasukkan massal tiba-tiba mulai mengambil 10 menit pada tabel dengan Identitykolom.

Ternyata ada dua masalah di balik ini:

1. Microsoft mengubah perilaku di Sql Server 2014 untuk memaksa Sisipan Massal untuk berjalan paralel - dalam versi sebelumnya Sisipan Massal diberi rencana Serialized.
2. Setelah berjalan paralel pada 32 core box kami, mesin menghabiskan lebih banyak waktu dengan core saling mengunci daripada benar-benar melakukan pekerjaan.

Butuh waktu 4 minggu tetapi setelah liburan saya mendapat hadiah terlambat dari Santa - konfirmasi bahwa masalah itu memang cacat.

Ada beberapa kemungkinan penyelesaian yang kami temukan sampai ini diperbaiki:

1. Gunakan Option (MaxDop 1)dalam kueri untuk mengubah sisipan massal kembali menjadi paket bersambung.
2. Tutupi kolom Identity dengan melemparkannya (mis. Select Cast(MyIdentityColumn As Integer) As MyIdentityColumn)
   • ini mencegah properti identitas disalin saat menggunakan SELECT...INTO
3. Hapus kolom identitas seperti dijelaskan di atas.
4. Ubah mode kompatibilitas database ke Sql Server 2012 atau lebih rendah untuk membangun kembali paket serial.

Pembaruan: Perbaikan yang akan diterapkan MS adalah mengembalikan jenis Sisipan ini kembali menggunakan Serialized rencana. Ini direncanakan untuk Sql Server 2017 CU14 (tidak ada berita tentang versi lain dari Sql Server - maaf!). Ketika diimplementasikan, Trace Flag 9492 perlu dinyalakan, baik di tingkat server, atau via DBCC TraceOn .