De två frågorna som orsakar dödläget är SELECT nedan (process id="process3980de4558" ):
select @existing = team_it_cube_attr_05 from tbl_Ref_Attr_Prod_Team where prod_id = @rec_key
Och UPDATE fråga nedan (process id="process386ed48188" ):
UPDATE D
SET D.team_rss_attr_01 = LEFT(S.mkt_prodchar_13,25)...
<resource-list> avsnittet noterar SELECT fråga ägde ett exklusivt (X) lås på en sida och försökte skaffa ett avsiktsdelat (IS) lås på en annan sida medan den läste data. UPDATE sökfrågan ägde redan ett IS-lås och försökte skaffa ett X-lås på en sida för att utföra uppdateringen.
Med tanke på kopplingen mot denna tabell:
...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 query äger redan ett exklusivt lås. Det betyder förmodligen att det är en del av en större transaktion som redan har utfört en UPDATE i en tidigare fråga. Lås från tidigare frågor kommer att bibehållas för att bevara dataintegriteten under transaktionen (beroende på transaktionsisoleringsnivå
).
UPDATE frågan måste läsa tabellen tbl_Ref_Attr_Prod_team . Den skaffar avsiktsdelade lås på sidor och rader medan den läser data. När UPDATE sökfrågan hittar de matchande raderna kommer den att försöka konvertera IS-låsen till X-lås. IS-lås är inte kompatibla med X-lås. Eftersom SELECT sökfrågan har redan ett IS-lås på en eller flera av dessa sidor, sökfrågorna låser sig med varandra.
En möjlig orsak skulle vara saknade index på tbl_Ref_Attr_Prod_team.prod_key . Utan ett index på den här kolumnen visas UPDATE fråga kommer att skanna alla rader i tabellen tbl_Ref_Attr_Prod_team .
Även om ett index finns på prod_key , om det finns ett litet antal rader i tabellen kan SQL Server besluta att prestanda skulle bli bättre om frågan skannade hela tabellen istället för att söka efter index. Att spela in frågeplanen när dödläget inträffar skulle verifiera denna teori.
Vi stöter regelbundet på små låsta tabeller när vi skapar nya databaser. Inledningsvis är borden små, och bordsskanningar orsakar alla möjliga dödlägen. Senare, när tabellerna är större, överstiger den beräknade kostnaden för att skanna tabellen kostnaden för att söka efter index, och låsningarna uppstår inte längre. I testmiljöer där antalet rader för alltid är litet har vi tillgripit FORESEEK och WITH INDEX tips för att tvinga fram indexsökningar istället för skanningar. Vi ser fram emot att kunna tvinga fram frågeplaner via frågelagringsfunktionen i SQL Server 2016.