- proces 9196a8 heeft pagina 151867 slot 174 in X-modus en wil pagina 140302 slot 31 in S-modus
- proces 88b5b8 heeft pagina 140302 slot 31 in X-modus en wil pagina 151867 slot 174 in S-modus
- de twee verwijderingen worden uitgevoerd onder
isolationlevel="repeatable read (3)"
Dus de deadlock vindt plaats op de basisheap van de tafel (RID-sloten in plaats van sleutelsloten impliceert een heap en geen Btree). Het hoge isolatieniveau (waarschijnlijk veroorzaakt door DTC, te oordelen naar de xact-naam) maakt de RCSI-instelling irrelevant.
Van welk type zijn de kolommen PARTYEXTERNALREF en PARTYTYPE? De parameters die worden doorgegeven zijn NVARCHAR (dwz Unicode) en als de kolommen VARCHAR zijn (dwz Ascii) dan vanwege de regels van voorrang gegevenstype de NC-index zou niet worden gebruikt. Door de bijbehorende tafelscan en het hoge isolatieniveau in gebruik, is een impasse bijna onvermijdelijk.
De oplossing zou zijn om parameters van het VARCHAR-type te gebruiken voor @P0 en @P1, zodat de NC-index zou worden gebruikt om de tabelscan te vermijden.
Als de parameters al van het type VARCHAR zijn en u uit het uitvoeringsplan kunt bevestigen dat een zoekactie op de NC wordt gebruikt, zou mijn eerste vraag zijn wat anders doet de transactie, behalve de verwijderinstructies?
Trouwens, je geeft alleen de naam van de NC-index, maar ik neem aan dat deze op (PARTYEXTERNALREF, ISCOUNTERPARTY, PARTYID) staat .
Bijwerken
Aangezien je commentaar zegt dat de kolommen zijn NVARCHAR dan is de tabelscanhypothese waarschijnlijk verkeerd. Er zijn nog drie mogelijkheden om een impasse te veroorzaken die onderzocht moeten worden:
- elke andere verklaring die door de transactie wordt uitgevoerd vóór de DELETE (dit is het meest waarschijnlijk)
- elke overlap in de rijen geselecteerd door twee DELETE-instructies die betrokken zijn bij de impasse
- hash-botsing
Alleen voor de eerste twee hypothesen kun je nu iets doen (onderzoeken of ze kloppen). Voor de laatste kan ik je vertellen hoe je het kunt verifiëren, maar het is niet triviaal. Het is onwaarschijnlijk dat dit gebeurt en een beetje moeilijk te bewijzen, maar het is mogelijk. Aangezien u een deadlock-zaak kent (de bijgevoegde XML), gebruikt u deze als onderzoeksbasis:
- herstel een point-in-time kopie van de database met stop bij 2011-09-02T19:00:29.690
- voer
DBCC TRACEON(3604,-1)uit - met behulp van
DBCC PAGE (<restored db id>, 1, 151867, 3)inspecteer de waarden in slot 174 - gebruik DBCC PAGE(, 1, 140302, 3)` inspecteer de waarden op slot 31
- voer
SELECT %%lockres%% FROM PARTIES WHERE PARTYEXTERNALREF = ... AND ISCOUNTERPARTY='N' and PARTYID=...en geef de bovenstaande waarden door - vergelijkt de resulterende lock-hash-waarden, als ze overeenkomen, heb je een hash-botsing en dit veroorzaakte de impasse.