- proces 9196a8 má stránku 151867 slot 174 v režimu X a chce stránku 140302 slot 31 v režimu S
- proces 88b5b8 má stránku 140302 slot 31 v režimu X a chce stránku 151867 slot 174 v režimu S
- dvě smazání probíhají pod
isolationlevel="repeatable read (3)"
K zablokování tedy dochází na základní hromadě tabulky (zámky RID namísto zámků klíčů znamenají hromadu, nikoli Bstrom). Vysoká úroveň izolace (pravděpodobně způsobená kódem DTC, soudě podle názvu xact) činí nastavení RCSI irelevantním.
Jaký typ jsou sloupce PARTYEXTERNALREF a PARTYTYPE? Předávané parametry jsou NVARCHAR (tj. Unicode) a pokud jsou sloupce VARCHAR (tj. Ascii), pak kvůli pravidlům přednost datového typu NC index by se nepoužil. Kvůli skenování tabulek spolu s vysokou úrovní izolace při používání je uváznutí téměř nevyhnutelné.
Řešením by bylo použít parametry typu VARCHAR pro @P0 a @P1, takže index NC by byl využit, aby se zabránilo prohledávání tabulky.
Pokud jsou parametry již typu VARCHAR a z prováděcího plánu můžete potvrdit, že se používá vyhledávání na NC, moje první otázka by byla další provádí transakce jiná než příkazy delete?
BTW, uvedete pouze název indexu NC, ale předpokládám, že je na (PARTYEXTERNALREF, ISCOUNTERPARTY, PARTYID) .
Aktualizovat
Vzhledem k tomu, že váš komentář říká, že sloupce jsou NVARCHAR, pak je hypotéza skenování tabulek pravděpodobně chybná. Existují tři další možnosti, jak způsobit uváznutí, které vyžadují vyšetřování:
- jakýkoli jiný příkaz spuštěný transakcí před příkazem DELETE (toto je nejpravděpodobnější)
- jakékoli překrytí v řádcích vybraných dvěma příkazy DELETE zapojenými do uváznutí
- kolize hash
Pouze pro první dvě hypotézy můžete hned teď něco udělat (prozkoumat, zda jsou správné). U toho posledního vám můžu říct, jak to ověřit, ale není to triviální. Je nepravděpodobné, že se to stane a je to trochu obtížné prokázat, ale je to možné. Protože znáte případ uváznutí (přiložený XML), použijte jej jako základ vyšetřování:
- obnovte kopii databáze k určitému časovému okamžiku se zastavením na 2011-09-02T19:00:29.690
- spusťte
DBCC TRACEON(3604,-1) - pomocí
DBCC PAGE (<restored db id>, 1, 151867, 3)zkontrolujte hodnoty ve slotu 174 - pomocí DBCC PAGE(, 1, 140302, 3)“ zkontrolujte hodnoty v bloku 31
- spusťte
SELECT %%lockres%% FROM PARTIES WHERE PARTYEXTERNALREF = ... AND ISCOUNTERPARTY='N' and PARTYID=...a předejte hodnoty přečtené výše - porovná výsledné hodnoty hash zámku, pokud se shodují, dojde ke kolizi hash a to způsobilo uváznutí.