Guide för dödlägen

Gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalysplattformssystem (PDW)SQL-databas i Förhandsversion av Microsoft Fabric

I den här artikeln beskrivs dödlägen i databasmotorn på djupet. Dödlägen orsakas av samtidiga och konkurrerande lås i databasen, ofta i flerstegstransaktioner. Mer information om transaktioner och lås finns i guiden för transaktionslåsning och radversioner.

Mer specifik information om identifiering och förebyggande av dödlägen i Azure SQL Database och SQL Database i Fabric finns i Analysera och förhindra dödlägen i Azure SQL Database och SQL Database i Fabric.

Förstå dödlägen

Ett dödläge uppstår när två eller flera aktiviteter permanent blockerar varandra genom att varje uppgift har ett lås på en resurs som de andra aktiviteterna försöker låsa. Till exempel:

• Transaktion A förvärvar ett delat lås på rad 1.

• Transaktion B får ett delat lås på rad 2.

• Transaktion A begär nu ett exklusivt lås på rad 2 och blockeras tills transaktion B har slutförts och släpper det delade lås som det har på rad 2.

• Transaktion B begär nu ett exklusivt lås på rad 1 och blockeras tills transaktionen A har slutförts och släpper det delade lås som det har på rad 1.

Transaktion A kan inte slutföras förrän transaktion B har slutförts, men transaktion B blockeras av transaktion A. Det här villkoret kallas även för ett cykliskt beroende: Transaktion A har ett beroende av transaktion B och transaktion B stänger cirkeln genom att ha ett beroende av transaktion A.

Båda transaktionerna i ett dödläge väntar för evigt, såvida inte dödläget bryts av en extern process. Databasens deadlockövervakare kontrollerar periodiskt processer som befinner sig i ett dödläge. Om övervakaren identifierar ett cykliskt beroende väljer den en av uppgifterna som offer och avslutar transaktionen med ett fel. Detta gör att den andra aktiviteten kan slutföra sin transaktion. Programmet med transaktionen som avslutades med ett fel kan försöka transaktionen igen, som vanligtvis slutförs när den andra låsta transaktionen har slutförts.

Deadlocking förväxlas ofta med normal blockering. När en transaktion begär ett lås på en resurs som är låst av en annan transaktion väntar den begärande transaktionen tills låset släpps. Som standardinställning går transaktioner i databasmotorn inte ut, såvida inte LOCK_TIMEOUT har angetts. Den begärande transaktionen blockeras, står inte i dödläge, eftersom den inte har gjort något för att blockera transaktionen som äger låset. Så småningom slutförs den ägande transaktionen och frigör låset, och sedan beviljas den begärande transaktionen låset och fortsätter. Dödlägen löses nästan omedelbart, medan blockering i teorin kan bestå på obestämd tid. Dödlägen kallas ibland för en dödlig omfamning.

Ett dödläge kan inträffa i alla system med flera trådar, inte bara i ett hanteringssystem för relationsdatabaser, och kan inträffa för andra resurser än lås på databasobjekt. En tråd i ett flertrådat operativsystem kan till exempel hämta en eller flera resurser, till exempel minnesblock. Om resursen som hämtas för närvarande ägs av en annan tråd kan den första tråden behöva vänta tills den ägande tråden släpper målresursen. Den väntande tråden sägs ha ett beroende av ägande tråden för den specifika resursen. I en instans av databasmotorn kan sessioner blockeras när icke-databasresurser hämtas, till exempel minne eller trådar.

I bilden har transaktion T1 ett beroende av transaktion T2 för tabelllåsresursen Part . På samma sätt har transaktion T2 ett beroende av transaktion T1 för tabelllåsresursen Supplier . Eftersom dessa beroenden utgör en cykel finns det ett dödläge mellan transaktionerna T1 och T2.

Här är en mer allmän illustration av ett dödläge:

• Aktivitet T1 har ett lås på resurs R1 (indikeras av pilen från R1 till T1) och har begärt ett lås på resurs R2 (som anges av pilen från T1 till R2).

• Aktivitet T2 har ett lås på resurs R2 (indikeras med pilen från R2 till T2) och har begärt ett lås på resurs R1 (indikeras av pilen från T2 till R1).

• Eftersom ingen av aktiviteterna kan fortsätta förrän en resurs är tillgänglig och ingen av resurserna kan släppas förrän en aktivitet fortsätter, finns det ett dödlägestillstånd.

Resurser som kan orsaka dödläge

Varje användarsession kan ha en eller flera aktiviteter som körs för dess räkning där varje uppgift kan hämta eller vänta med att hämta resurser. Följande typer av resurser kan orsaka blockering som kan leda till ett dödläge.

• Locks. Att vänta på att få lås på resurser, såsom objekt, sidor, rader, metadata och applikationer, kan orsaka ett dödläge. Till exempel har transaktion T1 ett delat (S) lås på rad r1 och väntar på att få ett exklusivt (X) lås på r2. Transaction T2 har ett delat (S) lås på r2 och väntar på att få ett exklusivt (X) lås på rad r1. Detta resulterar i en låscykel där T1 och T2 väntar på att varandra ska frigöra de låsta resurserna.

• Arbetartrådar. En uppgift som har placerats i kön och väntar på en ledig arbetstråd kan orsaka ett låst läge. Om den köade aktiviteten äger resurser som blockerar alla arbetstrådar, uppstår ett dödläge. Sessions-S1 startar till exempel en transaktion och hämtar ett delat (S) lås på rad r1 och försätts sedan i viloläge. Aktiva sessioner som körs på alla tillgängliga arbetstrådar försöker hämta exklusiva (X) lås på rad r1. Eftersom session S1 inte kan hämta en arbetstråd kan den inte bekräfta transaktionen och släppa låset på rad r1. Detta resulterar i ett dödläge.

• Memory. När samtidiga begäranden väntar på minnesbidrag som inte kan uppfyllas med det tillgängliga minnet, kan ett dödläge uppstå. Två samtidiga frågor, Q1 och Q2, körs till exempel som användardefinierade funktioner som hämtar 10 MB respektive 20 MB minne. Om varje fråga behöver 30 MB och det totala tillgängliga minnet är 20 MB måste Q1 och Q2 vänta tills varandra frigör minne, vilket resulterar i ett dödläge.

• Resurser relaterade till parallell frågekörning. Koordinator-, producent- eller konsumenttrådar som är associerade med en exchange-port kan blockera varandra och orsaka ett dödläge, vanligtvis när minst en annan process inkluderas som inte ingår i den parallella frågan. När en parallell fråga startar körningen avgör databasmotorn också graden av parallellitet och antalet nödvändiga arbetstrådar baserat på den aktuella arbetsbelastningen. Om systemarbetsbelastningen oväntat ändras, till exempel när nya frågor börjar köras på servern eller om systemet får slut på arbetstrådar, kan ett dödläge uppstå.

• Flera MARS-resurser (Active Result Sets). Dessa resurser används för att styra interfoliering av flera aktiva begäranden under MARS. Mer information finns i Using Multiple Active Result Sets (MARS) in SQL Server Native Client.

  • Användarresurs. När en tråd väntar på en resurs som kan styras av ett användarprogram anses resursen vara en extern resurs eller användarresurs och behandlas som ett lås.

  • Session mutex. Aktiviteterna som körs i en session interfolieras, vilket innebär att endast en aktivitet kan köras under sessionen vid en viss tidpunkt. Innan uppgiften kan köras måste den ha exklusiv åtkomst till sessionsmutexen.

  • Transaktionsmutex. Alla aktiviteter som körs i en transaktion interfolieras, vilket innebär att endast en aktivitet kan köras under transaktionen vid en viss tidpunkt. Innan uppgiften kan köras måste den ha exklusiv åtkomst till transaktionsmutexen.

    För att en uppgift ska kunna köras under MARS måste den hämta sessions mutex. Om uppgiften körs under en transaktion måste den sedan hämta transaktions-mutex. Detta garanterar att endast en aktivitet är aktiv samtidigt i en viss session och en viss transaktion. När de nödvändiga mutexen har hämtats kan uppgiften köras. När uppgiften har slutförts, eller ger med sig mitt i begäran, släpper den först transaktionslåsmekanismen, följt av sessionslåsmekanismen, i omvänd ordning av förvärvet. Dödlägen kan dock uppstå med dessa resurser. I följande pseudokod körs två uppgifter, användarbegäran U1 och användarbegäran U2, i samma session.

    U1:    Rs1=Command1.Execute("insert sometable EXEC usp_someproc");
    U2:    Rs2=Command2.Execute("select colA from sometable");
    

    Den lagrade proceduren som körs från användarbegäran U1 har hämtat sessions mutex. Om den lagrade proceduren tar lång tid att köra förutsätts det av databasmotorn att den lagrade proceduren väntar på indata från användaren. Användarbegäran U2 väntar på sessionsmutex medan användaren väntar på att få resultatuppsättningen från U2 och U1 väntar på en användarresurs. Det här är ett dödlägestillstånd som logiskt illustreras som:

    

Dödlägen kan också inträffa när en tabell partitioneras och LOCK_ESCALATION inställningen av ALTER TABLE är inställd på AUTO. När LOCK_ESCALATION är inställt AUTOpå ökar samtidigheten genom att tillåta databasmotorn att låsa tabellpartitioner på HoBT-nivå i stället för på tabellnivå. Men när separata transaktioner innehåller partitionslås i en tabell och vill ha ett lås någonstans på den andra transaktionspartitionen, orsakar detta ett dödläge. Den här typen av dödläge kan undvikas genom att ange LOCK_ESCALATION till TABLE. Den här inställningen minskar dock samtidigheten genom att tvinga stora uppdateringar av en partition att vänta på ett tabelllås.

Identifiering av dödläge

Alla resurser som anges i avsnittet Resurser som kan blockeras deltar i identifieringsschemat för databasmotorns dödläge. Upptäckten av dödläge utförs av en låsövervakningstråd som regelbundet utför en sökning genom alla uppgifter och processer i en instans av databasmotorn. Följande punkter beskriver sökprocessen:

• Standardintervallet är 5 sekunder.

• Om låsövervakningstråden hittar dödlägen sjunker intervallet för identifiering av dödlägen från 5 sekunder till så lågt som 100 millisekunder beroende på frekvensen för dödlägen.

• Om låsövervakningstråden slutar hitta dödlägen ökar databasmotorn intervallen mellan sökningarna till 5 sekunder.

• Om ett dödläge identifieras antas det att de nya trådarna som måste vänta på ett lås går in i dödlägescykeln. De första låsväntningarna efter att ett deadlock upptäckts utlöser omedelbart en deadlock-sökning, istället för att vänta till nästa intervall för deadlock-upptäckning. Om det aktuella intervallet till exempel är 5 sekunder och ett dödläge just har identifierats startar nästa låsvänte omedelbart dödlägesdetektorn. Om den här låsväntan är en del av ett dödläge identifieras det direkt i stället för under nästa deadlock-sökning.

Databasmotorn utför vanligtvis endast periodisk identifiering av dödlägen. Eftersom antalet dödlägen som påträffas i systemet vanligtvis är litet, bidrar periodisk identifiering av dödläge till att minska kostnaderna för identifiering av dödlägen i systemet.

När låsövervakaren initierar en deadlock-sökning för en viss tråd identifierar den resursen som tråden väntar på. Låsövervakaren hittar sedan ägarna för den specifika resursen och fortsätter rekursivt dödlägesökningen efter dessa trådar tills den hittar en cykel. En cykel som identifieras på det här sättet utgör ett dödläge.

När ett dödläge har identifierats avslutar databasmotorn ett dödläge genom att välja en av trådarna som ett dödlägesoffer. Databasmotorn avslutar den aktuella batchen som körs för tråden, rullar tillbaka transaktionen för deadlock-offret och returnerar fel 1205 till applikationen. När transaktionen för dödlägesoffret återställs frigörs alla lås som innehas av transaktionen. Detta gör att transaktionerna i de andra trådarna kan avblockeras och fortsätta. Felet 1205 (deadlock victim) registrerar information om vilken typ av resurser som är inblandade i ett dödläge.

Som standard väljer databasmotorn den transaktion som kör transaktionen som är den billigaste att återställa som dödlägesoffer. En användare kan också ange prioriteten för sessioner i en dödlägessituation med hjälp av -instruktionen SET DEADLOCK_PRIORITY . DEADLOCK_PRIORITY kan anges till LOW, NORMAL, eller HIGHeller alternativt kan ställas in på valfritt heltalsvärde i intervallet från -10 till 10. I vissa fall kan databasmotorn välja att tillfälligt ändra prioriteten för dödlägeshantering för att uppnå bättre parallellitet.

Prioriteten för dödläget har standardvärdet NORMAL, eller 0. Om två sessioner har olika dödlägesprioriteter väljs transaktionen i sessionen med lägre prioritet som dödlägesoffret. Om båda sessionerna har samma prioritet för dödläget väljs den transaktion som är minst kostsam att rulla tillbaka. Om sessioner som deltar i dödlägescykeln har samma prioritet för dödläget och samma kostnad väljs ett offer slumpmässigt. En uppgift som rullas tillbaka kan inte väljas som ett dödlägesoffer.

När du arbetar med COMMON Language Runtime (CLR) identifierar dödlägesövervakaren automatiskt dödlägen för synkroniseringsresurser (övervakare, läsare/skrivlås och trådkoppling) som används i hanterade procedurer. Dödläget löses dock genom att ett undantag utlöses i den procedur som valdes för att vara ett dödlägesoffer. Det är viktigt att förstå att undantaget inte automatiskt frigör resurser som för närvarande ägs av offret. resurserna måste uttryckligen frisläppas. I enlighet med undantagsbeteendet kan undantaget som används för att identifiera ett dödlägesoffer fångas upp och avvisas.

Informationsverktyg för dödläge

För att visa information om dödlägen tillhandahåller databasmotorn övervakningsverktyg i form av den xml_deadlock_report utökade händelsen, två spårningsflaggor och deadlock-grafhändelsen i SQL Profiler.

Den xml_deadlock_report utökade händelsen är den rekommenderade metoden för att samla in information om dödläge.

Utökad händelse för dödläge

I SQL Server 2012 (11.x) och senare versioner bör den xml_deadlock_report utökade händelsen användas i stället för händelseklassen deadlock graph i SQL Trace eller SQL Profiler.

Den system_health händelsesessionen xml_deadlock_report registrerar händelser som standard. Dessa händelser innehåller dödlägesdiagrammet. system_health Eftersom sessionen är aktiverad som standard behöver du inte konfigurera en separat händelsesession för att samla in information om dödläge.

Dödlägesdiagrammet som insamlats har normalt tre distinkta noder:

• victim-list. Processidentifierare för dödlägesoffer.
• process-list. Information om alla processer som ingår i dödläget.
• resource-list. Information om de resurser som är inblandade i dödläget.

Du kan visa event_file måldata för system_health sessionen i Management Studio. Om några xml_deadlock_report händelser inträffar visar Management Studio en grafisk beskrivning av de uppgifter och resurser som är inblandade i ett dödläge, enligt följande exempel:

Följande fråga kan visa alla dödlägeshändelser som fångats av ring_buffer-målet för system_health-sessionen:

SELECT xdr.value('@timestamp', 'datetime') AS deadlock_time,
       xdr.query('.') AS event_data
FROM (SELECT CAST ([target_data] AS XML) AS target_data
      FROM sys.dm_xe_session_targets AS xt
           INNER JOIN sys.dm_xe_sessions AS xs
               ON xs.address = xt.event_session_address
      WHERE xs.name = N'system_health'
            AND xt.target_name = N'ring_buffer') AS XML_Data
CROSS APPLY Target_Data.nodes('RingBufferTarget/event[@name="xml_deadlock_report"]') AS XEventData(xdr)
ORDER BY deadlock_time DESC;

Här är resultatet.

I följande exempel visas ett exempel på utdata från event_data kolumnen:

<event name="xml_deadlock_report" package="sqlserver" timestamp="2022-02-18T08:26:24.698Z">
  <data name="xml_report">
    <type name="xml" package="package0" />
    <value>
      <deadlock>
        <victim-list>
          <victimProcess id="process27b9b0b9848" />
        </victim-list>
        <process-list>
          <process id="process27b9b0b9848" taskpriority="0" logused="0" waitresource="KEY: 5:72057594214350848 (1a39e6095155)" waittime="1631" ownerId="11088595" transactionname="SELECT" lasttranstarted="2022-02-18T00:26:23.073" XDES="0x27b9f79fac0" lockMode="S" schedulerid="9" kpid="15336" status="suspended" spid="62" sbid="0" ecid="0" priority="0" trancount="0" lastbatchstarted="2022-02-18T00:26:22.893" lastbatchcompleted="2022-02-18T00:26:22.890" lastattention="1900-01-01T00:00:00.890" clientapp="SQLCMD" hostname="ContosoServer" hostpid="7908" loginname="CONTOSO\user" isolationlevel="read committed (2)" xactid="11088595" currentdb="5" lockTimeout="4294967295" clientoption1="538968096" clientoption2="128056">
            <executionStack>
              <frame procname="AdventureWorks2022.dbo.p1" line="3" stmtstart="78" stmtend="180" sqlhandle="0x0300050020766505ca3e07008ba8000001000000000000000000000000000000000000000000000000000000">
SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+    </frame>
              <frame procname="adhoc" line="4" stmtstart="82" stmtend="98" sqlhandle="0x020000006263ec01ebb919c335024a072a2699958d3fcce60000000000000000000000000000000000000000">
unknown    </frame>
            </executionStack>
            <inputbuf>
SET NOCOUNT ON
WHILE (1=1)
BEGIN
    EXEC p1 4
END
   </inputbuf>
          </process>
          <process id="process27b9ee33c28" taskpriority="0" logused="252" waitresource="KEY: 5:72057594214416384 (e5b3d7e750dd)" waittime="1631" ownerId="11088593" transactionname="UPDATE" lasttranstarted="2022-02-18T00:26:23.073" XDES="0x27ba15a4490" lockMode="X" schedulerid="6" kpid="5584" status="suspended" spid="58" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2022-02-18T00:26:22.890" lastbatchcompleted="2022-02-18T00:26:22.890" lastattention="1900-01-01T00:00:00.890" clientapp="SQLCMD" hostname="ContosoServer" hostpid="15316" loginname="CONTOSO\user" isolationlevel="read committed (2)" xactid="11088593" currentdb="5" lockTimeout="4294967295" clientoption1="538968096" clientoption2="128056">
            <executionStack>
              <frame procname="AdventureWorks2022.dbo.p2" line="3" stmtstart="76" stmtend="150" sqlhandle="0x03000500599a5906ce3e07008ba8000001000000000000000000000000000000000000000000000000000000">
UPDATE t1 SET c2 = c2+1 WHERE c1 = @p    </frame>
              <frame procname="adhoc" line="4" stmtstart="82" stmtend="98" sqlhandle="0x02000000008fe521e5fb1099410048c5743ff7da04b2047b0000000000000000000000000000000000000000">
unknown    </frame>
            </executionStack>
            <inputbuf>
SET NOCOUNT ON
WHILE (1=1)
BEGIN
    EXEC p2 4
END
   </inputbuf>
          </process>
        </process-list>
        <resource-list>
          <keylock hobtid="72057594214350848" dbid="5" objectname="AdventureWorks2022.dbo.t1" indexname="cidx" id="lock27b9dd26a00" mode="X" associatedObjectId="72057594214350848">
            <owner-list>
              <owner id="process27b9ee33c28" mode="X" />
            </owner-list>
            <waiter-list>
              <waiter id="process27b9b0b9848" mode="S" requestType="wait" />
            </waiter-list>
          </keylock>
          <keylock hobtid="72057594214416384" dbid="5" objectname="AdventureWorks2022.dbo.t1" indexname="idx1" id="lock27afa392600" mode="S" associatedObjectId="72057594214416384">
            <owner-list>
              <owner id="process27b9b0b9848" mode="S" />
            </owner-list>
            <waiter-list>
              <waiter id="process27b9ee33c28" mode="X" requestType="wait" />
            </waiter-list>
          </keylock>
        </resource-list>
      </deadlock>
    </value>
  </data>
</event>

Spårningsflagga 1204 och spårningsflagga 1222

När dödlägen inträffar och spårningsflagga 1204 eller spårningsflagga 1222 aktiveras rapporteras information om dödläge i SQL Server-felloggen. Spårningsflagga 1204 ger information om dödläge som formateras av var och en av noderna som är inblandade i dödläget. Spårningsflagga 1222 formaterar information om dödläge, först efter processer och sedan efter resurser. Det är möjligt att aktivera båda spårflaggorna för att få två representationer av samma dödlägeshändelse.

Förutom att definiera egenskaperna för spårningsflaggorna 1204 och 1222 visar följande tabell också likheterna och skillnaderna.

Exempel på spårningsflagga 1204

I följande exempel visas utdata när spårningsflagga 1204 är aktiverad. I det här fallet är tabellen i Nod 1 en heap utan index, och tabellen i Nod 2 är en heap med ett icke-grupperat index. Indexnyckeln i Nod 2 uppdateras när dödläget inträffar.

Deadlock encountered .... Printing deadlock information
Wait-for graph

Node:1

RID: 6:1:20789:0               CleanCnt:3 Mode:X Flags: 0x2
 Grant List 0:
   Owner:0x0315D6A0 Mode: X
     Flg:0x0 Ref:0 Life:02000000 SPID:55 ECID:0 XactLockInfo: 0x04D9E27C
   SPID: 55 ECID: 0 Statement Type: UPDATE Line #: 6
   Input Buf: Language Event:
BEGIN TRANSACTION
   EXEC usp_p2
 Requested By:
   ResType:LockOwner Stype:'OR'Xdes:0x03A3DAD0
     Mode: U SPID:54 BatchID:0 ECID:0 TaskProxy:(0x04976374) Value:0x315d200 Cost:(0/868)

Node:2

KEY: 6:72057594057457664 (350007a4d329) CleanCnt:2 Mode:X Flags: 0x0
 Grant List 0:
   Owner:0x0315D140 Mode: X
     Flg:0x0 Ref:0 Life:02000000 SPID:54 ECID:0 XactLockInfo: 0x03A3DAF4
   SPID: 54 ECID: 0 Statement Type: UPDATE Line #: 6
   Input Buf: Language Event:
     BEGIN TRANSACTION
       EXEC usp_p1
 Requested By:
   ResType:LockOwner Stype:'OR'Xdes:0x04D9E258
     Mode: U SPID:55 BatchID:0 ECID:0 TaskProxy:(0x0475E374) Value:0x315d4a0 Cost:(0/380)

Victim Resource Owner:
 ResType:LockOwner Stype:'OR'Xdes:0x04D9E258
     Mode: U SPID:55 BatchID:0 ECID:0 TaskProxy:(0x0475E374) Value:0x315d4a0 Cost:(0/380)

Exempel på spårningsflagga 1222

I följande exempel visas utdata när spårningsflagga 1222 är aktiverad. I det här fallet är en tabell en heap utan index, och den andra tabellen är en heap med ett icke-grupperat index. I den andra tabellen uppdateras indexnyckeln när dödläget inträffar.

deadlock-list
 deadlock victim=process689978
  process-list
   process id=process6891f8 taskpriority=0 logused=868
   waitresource=RID: 6:1:20789:0 waittime=1359 ownerId=310444
   transactionname=user_transaction
   lasttranstarted=2022-02-05T11:22:42.733 XDES=0x3a3dad0
   lockMode=U schedulerid=1 kpid=1952 status=suspended spid=54
   sbid=0 ecid=0 priority=0 transcount=2
   lastbatchstarted=2022-02-05T11:22:42.733
   lastbatchcompleted=2022-02-05T11:22:42.733
   clientapp=Microsoft SQL Server Management Studio - Query
   hostname=TEST_SERVER hostpid=2216 loginname=DOMAIN\user
   isolationlevel=read committed (2) xactid=310444 currentdb=6
   lockTimeout=4294967295 clientoption1=671090784 clientoption2=390200
    executionStack
     frame procname=AdventureWorks2022.dbo.usp_p1 line=6 stmtstart=202
     sqlhandle=0x0300060013e6446b027cbb00c69600000100000000000000
     UPDATE T2 SET COL1 = 3 WHERE COL1 = 1;
     frame procname=adhoc line=3 stmtstart=44
     sqlhandle=0x01000600856aa70f503b8104000000000000000000000000
     EXEC usp_p1
    inputbuf
      BEGIN TRANSACTION
       EXEC usp_p1
   process id=process689978 taskpriority=0 logused=380
   waitresource=KEY: 6:72057594057457664 (350007a4d329)
   waittime=5015 ownerId=310462 transactionname=user_transaction
   lasttranstarted=2022-02-05T11:22:44.077 XDES=0x4d9e258 lockMode=U
   schedulerid=1 kpid=3024 status=suspended spid=55 sbid=0 ecid=0
   priority=0 transcount=2 lastbatchstarted=2022-02-05T11:22:44.077
   lastbatchcompleted=2022-02-05T11:22:44.077
   clientapp=Microsoft SQL Server Management Studio - Query
   hostname=TEST_SERVER hostpid=2216 loginname=DOMAIN\user
   isolationlevel=read committed (2) xactid=310462 currentdb=6
   lockTimeout=4294967295 clientoption1=671090784 clientoption2=390200
    executionStack
     frame procname=AdventureWorks2022.dbo.usp_p2 line=6 stmtstart=200
     sqlhandle=0x030006004c0a396c027cbb00c69600000100000000000000
     UPDATE T1 SET COL1 = 4 WHERE COL1 = 1;
     frame procname=adhoc line=3 stmtstart=44
     sqlhandle=0x01000600d688e709b85f8904000000000000000000000000
     EXEC usp_p2
    inputbuf
      BEGIN TRANSACTION
        EXEC usp_p2
  resource-list
   ridlock fileid=1 pageid=20789 dbid=6 objectname=AdventureWorks2022.dbo.T2
   id=lock3136940 mode=X associatedObjectId=72057594057392128
    owner-list
     owner id=process689978 mode=X
    waiter-list
     waiter id=process6891f8 mode=U requestType=wait
   keylock hobtid=72057594057457664 dbid=6 objectname=AdventureWorks2022.dbo.T1
   indexname=nci_T1_COL1 id=lock3136fc0 mode=X
   associatedObjectId=72057594057457664
    owner-list
     owner id=process6891f8 mode=X
    waiter-list
     waiter id=process689978 mode=U requestType=wait

Profilers deadlock graph-händelse

SQL Profiler har en händelse som visar en grafisk beskrivning av de uppgifter och resurser som ingår i ett dödläge. I följande exempel visas utdata från SQL Profiler när deadlock graph-händelsen aktiveras.

SQL Profiler- och SQL Trace-funktionerna är inaktuella och ersätts av Utökade händelser. Utökade händelser har mindre prestandakostnader och är mer konfigurerbara än SQL Trace. Överväg att använda dödläget Extended Events i stället för att spåra dödlägen i SQL Profiler.

Mer information om deadlock-händelsen finns i Lås:Deadlock-händelseklass. Mer information om SQL Profiler-grafer för dödläge finns i Spara dödlägesdiagram (SQL Server Profiler).

Extended Events tillhandahåller motsvarigheter till SQL Trace-händelseklasser. Mer information finns i Se motsvarigheterna för utökade händelser till SQL Trace Event Classes. Extended Events rekommenderas över SQL Trace.

Hantera dödlägen

När en instans av databasmotorn väljer en transaktion som ett dödlägesoffer avslutas den aktuella batchen, transaktionen återställs och fel 1205 returneras till programmet. Det returnerade meddelandet är strukturerat på följande sätt:

Your transaction (process ID #...) was deadlocked on {lock | communication buffer | thread} resources with another process and has been chosen as the deadlock victim. Rerun your transaction.

Eftersom vilken applikation som helst som skickar Transact-SQL-frågor kan väljas som ett deadlockoffer, bör applikationer ha en felhanterare som kan hantera fel 1205. Om ett program inte hanterar felet kan programmet fortsätta omedvetet om att transaktionen har återställts.

Om du implementerar en felhanterare som fångar upp fel 1205 kan ett program hantera dödlägen och vidta åtgärder (till exempel automatiskt skicka frågan som var inblandad i dödläget igen).

Programmet bör pausas en kort stund innan frågan skickas på nytt. Detta ger den andra transaktionen som är involverad i dödläget en chans att slutföra och släppa sina lås. Om längden på pausen randomiseras minimerar det sannolikheten för att dödläget uppstår på nytt när den omskickade frågeförfrågan begär sina lås. Till exempel kan felhanteraren kodas för att pausa under en slumpmässig varaktighet mellan en och tre sekunder.

Hantera med TRY... CATCH

Du kan använda TRY... CATCH för att hantera dödlägen. Fel 1205 kan fångas av CATCH blocket.

Mer information finns i Hantering av dödlägen.

Minimera dödlägen

Även om deadlock-problem inte kan undvikas helt kan riskerna för att de inträffar minskas genom att du följer vissa kodningskonventioner. Genom att minimera mängden deadlock-problem kan du öka transaktionsdataflödet och minska systemets omkostnader eftersom färre transaktioner:

• Återställs, vilket gör allt arbete som utförts av transaktionen ogjort.
• Skickas på nytt av program eftersom de återställdes när deadlock-problemet inträffade.

Så här minimerar du dödlägen:

• Få åtkomst till objekt i samma ordning.
• Undvik användarinteraktion i transaktioner.
• Håll transaktionerna korta och i en batch.
• Undvik högre isoleringsnivåer, till exempel REPEATABLE READ och SERIALIZABLE när de inte behövs.
• Använd en isoleringsnivå som baseras på radversionshantering.
  • Aktivera databasalternativet READ_COMMITTED_SNAPSHOT för att använda radversionshantering för transaktioner med isoleringsnivån READ COMMITTED .
  • Använd "snapshot isolation"-transaktioner.
• Använd bundna anslutningar.

Komma åt objekt i samma ordning

Om alla samtidiga transaktioner kommer åt objekt i samma ordning är det mindre troligt att dödlägen inträffar. Om två samtidiga transaktioner till exempel hämtar ett lås på Supplier tabellen och sedan på Part tabellen blockeras en transaktion på Supplier tabellen tills den andra transaktionen har slutförts. När den första transaktionen committeras eller rullas tillbaka fortsätter den andra, och ett dödläge inträffar inte. Om du använder lagrade procedurer för alla dataändringar kan du standardisera ordningen för åtkomst till objekt.

Undvik användarinteraktion i transaktioner

Undvik transaktioner som inkluderar användarinteraktion, eftersom hastigheten för batchar som körs utan användarintervention är mycket snabbare än den hastighet med vilken en användare måste svara manuellt på frågor, till exempel svara på en fråga om en parameter som begärs av ett program. Detta försämrar systemets dataflöde eftersom låsen som används av transaktionen frigörs först när transaktionen checkas in eller återställs. Även om ett dödläge inte inträffar blockeras andra transaktioner som har åtkomst till samma resurser i väntan på att transaktionen ska slutföras.

Håll transaktionerna korta och i en batch

Ett deadlock inträffar vanligtvis när flera långvariga transaktioner körs samtidigt i samma databas. Ju längre transaktionen är, desto längre hålls de exklusiva låsen eller uppdateringslåsen, vilket blockerar annan aktivitet och leder till möjliga dödlägen.

Att hålla transaktioner i en batch minimerar nätverksrundan under en transaktion, vilket minskar eventuella fördröjningar i slutförandet av transaktionen på grund av klientbearbetning.

Undvik högre isoleringsnivåer

Avgör om en transaktion kan köras på en lägre isoleringsnivå. Med hjälp av READ COMMITTED kan en transaktion läsa data som tidigare lästs (men inte ändrats) av en annan transaktion utan att vänta på att transaktionen ska slutföras. READ COMMITTED innehåller delade lås under en kortare tid än en högre isoleringsnivå, till exempel SERIALIZABLE. Detta minskar låskonflikter.

Använd en radversionsbaserad isoleringsnivå

När databasalternativet READ_COMMITTED_SNAPSHOT har angetts ONanvänder en transaktion som körs under READ COMMITTED isoleringsnivån radversioner i stället för delade lås under läsåtgärder.

Ögonblicksbildisolering använder också radversionshantering, som inte använder delade lås under läsåtgärder. Innan en transaktion kan köras under ögonblicksbildisolering måste databasalternativet ALLOW_SNAPSHOT_ISOLATION anges ON.

Använd radversionsbaserade isoleringsnivåer för att minimera dödlägen som kan uppstå mellan läs- och skrivåtgärder.

Använda bundna anslutningar

Med hjälp av bundna anslutningar kan två eller flera anslutningar som öppnas av samma program samarbeta med varandra. Alla lås som erhålls av de sekundära anslutningarna behandlas som om de hade erhållits av den primära anslutningen, och vice versa. Därför blockerar de inte varandra.

Orsaka ett dödläge

Du kan behöva orsaka ett dödläge i utbildnings- eller demonstrationssyfte.

Följande exempel fungerar i exempeldatabasen AdventureWorksLT2019 med standardschemat och data när READ_COMMITTED_SNAPSHOT har aktiverats. Om du vill ladda ned det här exemplet går du till AdventureWorks-exempeldatabaser.

Ett exempel som orsakar ett dödläge när optimerad låsning är aktiverat finns i Optimerad låsning och dödlägen.

För att orsaka ett dödläge måste du ansluta två sessioner till AdventureWorksLT2019-databasen. Vi refererar till dessa sessioner som Session A och Session B. Du kan skapa dessa två sessioner genom att skapa två frågefönster i SQL Server Management Studio (SSMS).

Kör följande batch i Session A. Den här koden påbörjar en explicit transaktion och kör en instruktion som uppdaterar SalesLT.Product tabellen. För att göra detta förvärvar transaktionen ett uppdateringslås (U) på kvalificerade rader i tabell SalesLT.Product, vilka sedan konverteras till exklusiva (X) lås. Vi lämnar transaktionen öppen.

BEGIN TRANSACTION;

UPDATE SalesLT.Product
    SET SellEndDate = SellEndDate + 1
WHERE Color = 'Red';

Kör nu följande batch i Session B. Den här koden påbörjar inte uttryckligen en transaktion. I stället fungerar den i autokommit-transaktionsläge. Detta uttalande uppdaterar tabellen SalesLT.ProductDescription. Uppdateringen tar ett uppdateringslås (U) på de kvalificerande raderna i SalesLT.ProductDescription-tabellen. Frågan kopplas till andra tabeller, inklusive tabellen SalesLT.Product.

UPDATE SalesLT.ProductDescription
    SET Description = Description
FROM SalesLT.ProductDescription AS pd
     INNER JOIN SalesLT.ProductModelProductDescription AS pmpd
         ON pd.ProductDescriptionID = pmpd.ProductDescriptionID
     INNER JOIN SalesLT.ProductModel AS pm
         ON pmpd.ProductModelID = pm.ProductModelID
     INNER JOIN SalesLT.Product AS p
         ON pm.ProductModelID = p.ProductModelID
WHERE p.Color = 'Silver';

För att slutföra den här uppdateringen behöver session B delade (S) lås på rader i tabellen SalesLT.Product, inklusive de rader som är låsta av session A. Session B blockeras på SalesLT.Product.

Återgå till session A. Kör följande UPDATE instruktion. Denna sats utförs som en del av den tidigare öppna transaktionen.

UPDATE SalesLT.ProductDescription
    SET Description = Description
FROM SalesLT.ProductDescription AS pd
     INNER JOIN SalesLT.ProductModelProductDescription AS pmpd
         ON pd.ProductDescriptionID = pmpd.ProductDescriptionID
     INNER JOIN SalesLT.ProductModel AS pm
         ON pmpd.ProductModelID = pm.ProductModelID
     INNER JOIN SalesLT.Product AS p
         ON pm.ProductModelID = p.ProductModelID
WHERE p.Color = 'Red';

Den andra uppdateringssatsen i Session A blockeras av Session B på SalesLT.ProductDescription.

Session A och Session B blockerar nu varandra ömsesidigt. Ingen av transaktionerna kan fortsätta eftersom var och en behöver en resurs som är låst av den andra.

Efter några sekunder identifierar dödlägesövervakaren att transaktionerna i session A och session B blockerar varandra ömsesidigt och att ingen av dem kan göra framsteg. Du ser ett dödläge inträffa, med Session A som utvalt dödlägesofferet. session B slutförs framgångsrikt. Ett felmeddelande visas i frågefönstret i Session A med text som liknar följande exempel:

Msg 1205, Level 13, State 51, Line 7
Transaction (Process ID 51) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Om ett dödläge inte uppstår, kontrollera att READ_COMMITTED_SNAPSHOT är aktiverat i exempeldatabasen. Dödlägen kan inträffa i valfri databaskonfiguration, men det här exemplet kräver att det READ_COMMITTED_SNAPSHOT är aktiverat.

Du kan visa information om dödläget i ring_buffer målet för händelsesessionen system_health , som är aktiverad och aktiv som standard i SQL Server och Azure SQL Managed Instance. Överväg följande fråga:

WITH cteDeadLocks ([Deadlock_XML])
AS (SELECT CAST (target_data AS XML) AS [Deadlock_XML]
    FROM sys.dm_xe_sessions AS xs
         INNER JOIN sys.dm_xe_session_targets AS xst
             ON xs.[address] = xst.event_session_address
    WHERE xs.[name] = 'system_health'
          AND xst.target_name = 'ring_buffer')
SELECT x.Graph.query('(event/data/value/deadlock)[1]') AS Deadlock_XML,
       x.Graph.value('(event/data/value/deadlock/process-list/process/@lastbatchstarted)[1]', 'datetime2(3)') AS when_occurred,
       DB_Name(x.Graph.value('(event/data/value/deadlock/process-list/process/@currentdb)[1]', 'int')) AS DB --Current database of the first listed process
FROM (SELECT Graph.query('.') AS Graph
      FROM cteDeadLocks AS c
      CROSS APPLY c.[Deadlock_XML].nodes('RingBufferTarget/event[@name="xml_deadlock_report"]') AS Deadlock_Report(Graph)) AS x
ORDER BY when_occurred DESC;

Du kan visa XML-koden i Deadlock_XML kolumnen i SSMS genom att välja cellen som visas som en hyperlänk. Spara utdata som en .xdl-fil, stäng den, och öppna sedan .xdl-filen i SSMS för en visuell återgivning av ett dödlåsdiagram. Grafen för dödläge bör se ut ungefär som i följande bild.

Optimerade låsningar och dödlägen

Med optimerad låsning hålls inte sid- och radlås förrän transaktionen har slutförts. De släpps så snart en rad har uppdaterats. Om READ_COMMITTED_SNAPSHOT är aktiverat används inte uppdateringslås (U). Därför minskar sannolikheten för dödlägen.

Föregående exempel orsakar inte ett dödläge när optimerad låsning är aktiverad eftersom den förlitar sig på uppdateringslåsen (U).

Följande exempel kan användas för att orsaka ett dödläge i en databas som har optimerad låsning aktiverad.

Skapa först en exempeltabell och lägg till data.

CREATE TABLE t2
(
    a INT PRIMARY KEY NOT NULL,
    b INT NULL
);

INSERT INTO t2
VALUES (1, 10),
(2, 20),
(3, 30);

Följande T-SQL-batchar, som körs i följd i två separata sessioner, skapar ett dödläge.

I session 1:

BEGIN TRANSACTION xactA;

UPDATE t2
    SET b = b + 10
WHERE a = 1;

I session 2:

BEGIN TRANSACTION xactB;

UPDATE t2
    SET b = b + 10
WHERE a = 2;

I session 1:

UPDATE t2
    SET b = b + 100
WHERE a = 2;

I session 2:

UPDATE t2
    SET b = b + 20
WHERE a = 1;

I det här fallet har varje session ett exklusivt (X) lås på sin egen transaktions-ID-resurs (TID) och väntar på det delade (S) låset på den andra TID, vilket resulterar i ett dödläge.

Följande förkortade dödlägesrapport innehåller element och attribut som är specifika för optimerad låsning. Under varje resurs i dödlåsrapporten <resource-list>, rapporterar varje <xactlock>-element de underliggande resurserna och TID-låsinformationen för varje medlem i ett dödlås.

<deadlock>
 <victim-list>
  <victimProcess id="process12994344c58" />
 </victim-list>
 <process-list>
  <process id="process12994344c58" taskpriority="0" logused="272" waitresource="XACT: 23:2476:0 KEY: 23:72057594049593344 (8194443284a0)" waittime="447" ownerId="3234906" transactionname="xactA" lasttranstarted="2025-10-08T21:36:34.063" XDES="0x12984ba0480" lockMode="S" schedulerid="2" kpid="204928" status="suspended" spid="95" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2025-10-08T21:36:40.857" lastbatchcompleted="2025-10-08T21:36:34.063" lastattention="2025-10-08T21:36:11.340" clientapp="Microsoft SQL Server Management Studio - Query" hostname="WS1" hostpid="23380" loginname="user1" isolationlevel="read committed (2)" xactid="3234906" currentdb="23" currentdbname="AdventureWorksLT" lockTimeout="4294967295" clientoption1="671090784" clientoption2="390200">
   <inputbuf>
UPDATE t2
    SET b = b + 20
WHERE a = 1;
   </inputbuf>
  </process>
  <process id="process1299c969828" taskpriority="0" logused="272" waitresource="XACT: 23:2477:0 KEY: 23:72057594049593344 (61a06abd401c)" waittime="3083" ownerId="3234886" transactionname="xactB" lasttranstarted="2025-10-08T21:36:30.303" XDES="0x12995c84480" lockMode="S" schedulerid="2" kpid="63348" status="suspended" spid="88" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2025-10-08T21:36:38.223" lastbatchcompleted="2025-10-08T21:36:30.303" lastattention="1900-01-01T00:00:00.303" clientapp="Microsoft SQL Server Management Studio - Query" hostname="WS1" hostpid="23380" loginname="user1" isolationlevel="read committed (2)" xactid="3234886" currentdb="23" currentdbname="AdventureWorksLT" lockTimeout="4294967295" clientoption1="671090784" clientoption2="390200">
   <inputbuf>
UPDATE t2
    SET b = b + 100
WHERE a = 2;
   </inputbuf>
  </process>
 </process-list>
 <resource-list>
  <xactlock xdesIdLow="2476" xdesIdHigh="0" dbid="23" id="lock1299fa06c00" mode="X">
   <UnderlyingResource>
    <keylock hobtid="72057594049593344" dbid="23" objectname="e6fc405e-1ee8-49df-a2b3-54ee0151d851.dbo.t2" indexname="PK__t2__3BD0198ED3CBA65E" />
   </UnderlyingResource>
   <owner-list>
    <owner id="process1299c969828" mode="X" />
   </owner-list>
   <waiter-list>
    <waiter id="process12994344c58" mode="S" requestType="wait" />
   </waiter-list>
  </xactlock>
  <xactlock xdesIdLow="2477" xdesIdHigh="0" dbid="23" id="lock129940b2380" mode="X">
   <UnderlyingResource>
    <keylock hobtid="72057594049593344" dbid="23" objectname="e6fc405e-1ee8-49df-a2b3-54ee0151d851.dbo.t2" indexname="PK__t2__3BD0198ED3CBA65E" />
   </UnderlyingResource>
   <owner-list>
    <owner id="process12994344c58" mode="X" />
   </owner-list>
   <waiter-list>
    <waiter id="process1299c969828" mode="S" requestType="wait" />
   </waiter-list>
  </xactlock>
 </resource-list>
</deadlock>

Relaterat innehåll

• översikt över utökade händelser
• sys.dm_tran_locks (Transact-SQL)
• Händelseklass för Deadlock Graph
• Dödlägen med läsrepeterbar isoleringsnivå
• Lås:Händelseklass för låsblockeringskedja
• Lås:Deadlock-händelseklass
• SET DEADLOCK_PRIORITY (Transact-SQL)
• Analysera och förhindra dödlägen i Azure SQL Database och SQL Database i Fabric
• Öppna, visa och skriva ut en dödlägesfil i SQL Server Management Studio (SSMS)