- proces 9196a8 har side 151867 slot 174 i X-tilstand og ønsker side 140302 slot 31 i S-tilstand
- proces 88b5b8 har side 140302 slot 31 i X-tilstand og ønsker side 151867 slot 174 i S-tilstand
- de to sletninger kører under
isolationlevel="repeatable read (3)"
Så dødvandet opstår på bordets basisbunke (RID-låse i stedet for nøglelåse indebærer en heap ikke et Btree). Det høje isolationsniveau (sandsynligvis forårsaget af DTC, at dømme ud fra det faktiske navn) gør RCSI-indstillingen irrelevant.
Hvilken type er kolonnerne PARTYEXTERNALREF og PARTYTYPE? De indgivne parametre er NVARCHAR (dvs. Unicode), og hvis kolonnerne er VARCHAR (dvs. Ascii), så på grund af reglerne i datatypepræference NC-indekset ville ikke blive brugt. På grund af den involverede bordscanning, sammen med det høje isolationsniveau i brug, er en dødvande næsten uundgåelig.
Løsningen ville være at bruge VARCHAR-typeparametre for @P0 og @P1, så NC-indekset ville blive udnyttet til at undgå tabelscanningen.
Hvis parametrene allerede er af typen VARCHAR, og du kan bekræfte fra udførelsesplanen, at en søgning på NC er brugt, ville mit første spørgsmål være hvad ellers er transaktionen i gang, andet end sletningserklæringerne?
BTW, du giver kun navnet på NC-indekset, men jeg antager, at det er på (PARTYEXTERNALREF, ISCOUNTERPARTY, PARTYID) .
Opdater
Siden din kommentar siger, at kolonnerne er NVARCHAR så er tabellernes scanningshypotese sandsynligvis forkert. Der er yderligere tre muligheder for at skabe et dødvande, som kræver undersøgelse:
- enhver anden erklæring, der køres af transaktionen før SLET (dette er det mest sandsynlige)
- enhver overlapning i rækkerne valgt af to DELETE-sætninger involveret i dødvandet
- hashkollision
For de første to hypoteser er det kun dig, der kan gøre noget lige nu (undersøg om de er rigtige). For det sidste kan jeg fortælle dig, hvordan du verificerer det, men det er ikke trivielt. Det er usandsynligt, at det sker og lidt svært at bevise, men det er muligt. Da du kender som dødvandssag (den vedhæftede XML), skal du bruge den som undersøgelsesbase:
- gendan en punkt-i-tidskopi af databasen med stop kl. 2011-09-02T19:00:29.690
- kør
DBCC TRACEON(3604,-1) - ved at bruge
DBCC PAGE (inspicer værdierne i slot 174, 1, 151867, 3) - brug DBCC PAGE(, 1, 140302, 3)` inspicér værdierne ved plads 31
- kør
VÆLG %%lockres%% FRA PARTER, HVOR PARTYEXTERNALREF =... OG ISCOUNTERPARTY='N' og PARTYID=...og indtast værdierne læst ovenfor - sammenligner de resulterende låsehashværdier, hvis de matcher, har du en hashkollision, og dette forårsagede dødvandet.