- proses 9196a8 memiliki halaman 151867 slot 174 dalam mode X dan menginginkan halaman 140302 slot 31 dalam mode S
- proses 88b5b8 memiliki halaman 140302 slot 31 dalam mode X dan menginginkan halaman 151867 slot 174 dalam mode S
- dua penghapusan berjalan di bawah
isolationlevel="repeatable read (3)"
Jadi kebuntuan terjadi pada tumpukan dasar tabel (kunci RID alih-alih kunci kunci menyiratkan tumpukan bukan Btree). Tingkat isolasi yang tinggi (kemungkinan disebabkan oleh DTC, dilihat dari nama sebenarnya) membuat pengaturan RCSI tidak relevan.
Apa jenis kolom PARTYEXTERNALREF dan PARTYTYPE? Parameter yang diteruskan adalah NVARCHAR (mis. Unicode) dan jika kolomnya adalah VARCHAR (mis. Ascii) maka karena aturan prioritas tipe data indeks NC tidak akan digunakan. Karena pemindaian tabel yang terlibat, bersama dengan tingkat isolasi tinggi yang digunakan, kebuntuan hampir tidak dapat dihindari.
Solusinya adalah menggunakan parameter tipe VARCHAR untuk @P0 dan @P1 sehingga indeks NC akan dimanfaatkan untuk menghindari pemindaian tabel.
Jika parameter sudah bertipe VARCHAR dan Anda dapat mengonfirmasi dari rencana eksekusi bahwa pencarian pada NC digunakan, pertanyaan pertama saya adalah lain apakah transaksi dilakukan, selain pernyataan hapus?
BTW, Anda hanya memberikan nama indeks NC tapi saya asumsikan ada di (PARTYEXTERNALREF, ISCOUNTERPARTY, PARTYID) .
Perbarui
Karena komentar Anda mengatakan bahwa kolom adalah NVARCHAR maka hipotesis pemindaian tabel mungkin salah. Ada tiga kemungkinan lagi untuk menyebabkan kebuntuan yang perlu diselidiki:
- pernyataan lain yang dijalankan oleh transaksi sebelum DELETE (ini yang paling mungkin)
- setiap tumpang tindih pada baris yang dipilih oleh dua pernyataan DELETE yang terlibat dalam kebuntuan
- tabrakan hash
Untuk dua hipotesis pertama hanya Anda yang dapat melakukan apa pun sekarang (selidiki apakah itu benar). Untuk yang terakhir saya dapat memberitahu Anda cara memverifikasinya, tetapi tidak sepele. Itu tidak mungkin terjadi dan agak sulit untuk dibuktikan, tetapi itu mungkin. Karena Anda mengetahui kasus kebuntuan (XML terlampir), gunakan sebagai basis investigasi:
- memulihkan salinan database tepat waktu dengan berhenti di 09-02T19:00:29.690
- jalankan
DBCC TRACEON(3604,-1) - menggunakan
DBCC PAGE (<restored db id>, 1, 151867, 3)periksa nilai di slot 174 - menggunakan DBCC PAGE(, 1, 140302, 3)` periksa nilai pada slot 31
- jalankan
SELECT %%lockres%% FROM PARTIES WHERE PARTYEXTERNALREF = ... AND ISCOUNTERPARTY='N' and PARTYID=...dan berikan nilai yang dibaca di atas - bandingkan nilai hash kunci yang dihasilkan, jika cocok maka Anda mengalami benturan hash dan ini menyebabkan kebuntuan.
