Dva dotazy způsobující zablokování jsou SELECT níže (process id="process3980de4558" ):
select @existing = team_it_cube_attr_05 from tbl_Ref_Attr_Prod_Team where prod_id = @rec_key
A UPDATE dotaz níže (process id="process386ed48188" ):
UPDATE D
SET D.team_rss_attr_01 = LEFT(S.mkt_prodchar_13,25)...
The <resource-list> sekce poznamenává SELECT dotaz vlastnil exkluzivní zámek (X) na stránce a při čtení dat se pokoušel získat zámek sdíleného záměru (IS) na jiné stránce. UPDATE dotaz již vlastnil zámek IS a pokoušel se získat zámek X na stránce, aby mohl provést aktualizaci.
Vzhledem ke spojení proti této tabulce:
...from tbl_Ref_Attr_Prod_Team where prod_id = @rec_key...
...INNER JOIN tbl_Ref_Attr_Prod_Team D ON D.prod_key=P.prod_key...
SELECT dotaz již vlastní exkluzivní zámek. Pravděpodobně to znamená, že je součástí větší transakce, která již provedla UPDATE v předchozím dotazu. Zámky z předchozích dotazů budou zachovány, aby byla zachována integrita dat během transakce (v závislosti na úroveň izolace transakcí
).
UPDATE dotaz potřebuje číst tabulku tbl_Ref_Attr_Prod_team . Získává zámky sdíleného záměru na stránkách a řádcích při čtení dat. Když UPDATE dotaz najde odpovídající řádky, pokusí se převést zámky IS na zámky X. Zámky IS nejsou kompatibilní se zámky X. Protože SELECT dotaz již má zámek IS na jedné nebo více z těchto stránek, dotazy se vzájemně zablokují.
Jednou z možných příčin by byly chybějící indexy na tbl_Ref_Attr_Prod_team.prod_key . Bez indexu v tomto sloupci, UPDATE dotaz bude skenovat všechny řádky v tabulce tbl_Ref_Attr_Prod_team .
I když index na prod_key existuje Pokud je v tabulce malý počet řádků, SQL Server se může rozhodnout, že výkon by byl lepší, kdyby dotaz prohledával celou tabulku namísto hledání indexu. Zaznamenání plánu dotazů, když dojde k uváznutí, by tuto teorii potvrdilo.
Při zavádění nových databází se pravidelně setkáváme s malými zablokováními tabulek. Zpočátku jsou tabulky malé a skenování tabulek způsobuje nejrůznější uváznutí. Později, když jsou tabulky větší, vypočítané náklady na skenování tabulky převyšují náklady na hledání indexu a k uváznutí již nedochází. V testovacích prostředích, kde je počet řádků trvale malý, jsme se uchýlili k použití FORESEEK a WITH INDEX rady k vynucení hledání indexu namísto skenování. Těšíme se, že budeme moci vynutit plány dotazů prostřednictvím funkce úložiště dotazů SQL Server 2016.