Optimerad låsning

Gäller för: SQL Server 2025 (17.x) Azure SQL DatabaseAzure SQL Managed InstanceSQL Database i Microsoft Fabric

Optimerad låsning erbjuder en förbättrad mekanism för transaktionslåsning för att minska blockering av lås och låsminnesförbrukning för samtidiga transaktioner.

Vad är optimerad låsning?

Optimerad låsning hjälper till att minska låsminnet eftersom mycket få lås hålls även för stora transaktioner. Dessutom undviker optimerad låsning låseskaleringar och kan undvika vissa typer av dödlägen. Detta ger mer samtidig åtkomst till tabellen.

Optimerad låsning består av två primära komponenter: transaktions-ID (TID) låsning och låsning efter kvalificering (LAQ).

• Ett transaktions-ID (TID) är en unik identifierare för en transaktion. Varje rad är märkt med den senaste TID som ändrade den. I stället för potentiellt många lås på nycklar eller radidentifierare används ett enda lås på TID för att skydda alla modifierade rader. Mer information finns i transaktions-ID (TID) som låser.
• Lås efter kvalificering (LAQ) är en optimering som utvärderar frågepredikat med hjälp av den senaste bekräftade versionen av raden utan att hämta ett lås, vilket förbättrar samtidigheten. LAQ kräver lästillåten ögonblicksbildisolering (RCSI). För mer information, se Lås efter kvalificering (LAQ).

Till exempel:

• Utan optimerad låsning kan uppdatering av 1 000 rader i en tabell kräva 1 000 exklusiva radlås (X) som hålls kvar till slutet av transaktionen.
• Med optimerad låsning kan uppdatering av 1 000 rader i en tabell kräva 1 000 X radlås, men varje lås släpps så snart varje rad uppdateras och endast ett X TID-lås hålls kvar till slutet av transaktionen. Eftersom lås frigörs snabbt minskar användningen av låsminnet, och låseskalering inträffar mycket mindre ofta, vilket förbättrar samtidigheten i arbetsbelastningen.

Note

Aktivering av optimerad låsning minskar eller eliminerar rad- och sidlås som hämtas av DML-instruktioner (Data Modification Language), till exempel INSERT, UPDATE, DELETE, MERGE. Det påverkar inte andra typer av databas- och objektlås, till exempel schemalås.

Availability

I följande tabell sammanfattas tillgängligheten och det aktiverade tillståndet för optimerad låsning mellan SQL-plattformar.

Platform	Available	Aktiverad som standard
Azure SQL Database	Yes	Ja (alltid aktiverat)
SQL-databas i Microsoft Fabric	Yes	Ja (alltid aktiverat)
Azure SQL Managed InstanceAUTD	Yes	Ja (alltid aktiverat)
Azure SQL Managed Instance2025	Yes	Ja (alltid aktiverat)
Azure SQL Managed Instance2022	No	N/A
SQL Server 2025 (17.x)	Yes	Nej (kan aktiveras per databas)
SQL Server 2022 (16.x) och äldre versioner	No	N/A

Aktivera och inaktivera

Om du vill aktivera eller inaktivera optimerad låsning för en SQL Server-databas använder du ALTER DATABASE ... SET OPTIMIZED_LOCKING = ON | OFF kommandot . Mer information finns i ALTER DATABASE SET-alternativ.

Optimerad låsning bygger på andra databasfunktioner:

• Du måste aktivera accelererad databasåterställning (ADR) på en databas innan du kan aktivera optimerad låsning. Om du vill inaktivera ADR måste du inaktivera optimerad låsning först om den är aktiverad.
• För den största fördelen med optimerad låsning bör läsa incheckad ögonblicksbildisolering (RCSI) aktiveras för databasen. Komponenten LAQ för optimerad låsning gäller endast om RCSI är aktiverat.

ADR är alltid aktiverat i Azure SQL Database, Azure SQL Managed Instance och SQL Database i Microsoft Fabric. RCSI är aktiverat som standard i Azure SQL Database och SQL Database i Microsoft Fabric.

Om du vill kontrollera att de här alternativen är aktiverade för den aktuella databasen ansluter du till databasen och kör följande T-SQL-fråga:

SELECT database_id,
       name,
       is_accelerated_database_recovery_on,
       is_read_committed_snapshot_on,
       is_optimized_locking_on
FROM sys.databases
WHERE name = DB_NAME();

Är optimerad låsning aktiverad?

Optimerad låsning är aktiverad per databas. Anslut till databasen och använd sedan följande fråga för att kontrollera om optimerad låsning är aktiverad:

SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsOptimizedLockingOn') AS is_optimized_locking_enabled;

Result	Description
0	Optimerad låsning är inaktiverad.
1	Optimerad låsning är aktiverad.
NULL	Optimerad låsning är inte tillgänglig.

Du kan också använda katalogvyn sys.databases . Om du till exempel vill se om optimerad låsning är aktiverad för alla databaser kör du följande fråga:

SELECT database_id,
       name,
       is_optimized_locking_on
FROM sys.databases;

Låsningsöversikt

Det här är en kort sammanfattning av beteendet när optimerad låsning inte är aktiverad. Mer information finns i guiden Transaktionslåsning och Radversioner.

I databasmotorn är låsning en mekanism som förhindrar att flera transaktioner uppdaterar samma data samtidigt för att garantera ACID- egenskaper för transaktioner.

När en transaktion behöver ändra data begär den ett lås på data. Låset beviljas om inga andra motstridiga lås lagras på data och transaktionen kan fortsätta med ändringen. Om ett annat konflikterande lås innehas på datan, måste transaktionen vänta tills låset släpps innan den kan fortsätta.

När flera transaktioner försöker komma åt samma data samtidigt måste databasmotorn lösa potentiellt komplexa konflikter med samtidiga läsningar och skrivningar. Låsning är en av de mekanismer som motorn kan använda för att tillhandahålla semantik för ANSI SQL-transaktionen isoleringsnivåer. Även om det är viktigt att låsa i databaser kan minskad samtidighet, dödlägen, komplexitet och låskostnader påverka prestanda och skalbarhet.

Låsning av transaktions-ID (TID)

När radversioneringsbaserade isoleringsnivåer används eller när ADR är aktiverat, innehåller varje rad internt i databasen ett transaktions-ID (TID). TID persisteras med raden. Varje transaktion som ändrar en rad stämplar raden med dess TID.

Vid TID-låsning, istället för att låsa nyckeln för raden, låses TID för raden. Den ändringstransaktion som har ett X-lås på sin TID. Andra transaktioner tar ett S-lås på TID och väntar tills den första transaktionen är avslutad. Med TID-låsning fortsätter sid- och radlås att vidtas för ändringar, men varje sida och radlås släpps så snart varje rad har ändrats. Det enda låset som hålls till slutet av transaktionen är det enda X lås på TID-resursen och ersätter flera sid- och radlås (nyckel).

Tänk dig följande exempel som visar lås för den aktuella sessionen medan en skrivtransaktion är aktiv:

/* Is optimized locking is enabled? */
SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsOptimizedLockingOn') AS is_optimized_locking_enabled;

CREATE TABLE t0
(
a int PRIMARY KEY,
b int NULL
);

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

BEGIN TRANSACTION;

UPDATE t0
SET b = b + 10;

SELECT *
FROM sys.dm_tran_locks
WHERE request_session_id = @@SPID
      AND
      resource_type IN ('PAGE','RID','KEY','XACT');

COMMIT TRANSACTION;
GO

DROP TABLE IF EXISTS t0;

Om optimerad låsning är aktiverad innehåller begäran bara ett enda X lås på resursen XACT (transaktion).

Om optimerad låsning inte är aktiverad innehåller samma begäran fyra lås – ett IX (exklusivt) lås på sidan som innehåller raderna och tre X nyckellås på varje rad:

Den sys.dm_tran_locks dynamiska hanteringsvyn (DMV) är användbar för att undersöka eller felsöka låsningsproblem. Här används den för att observera optimerad låsning i praktiken.

Lås efter kvalificering (LAQ)

LaQ-komponenten i optimerad låsning bygger på TID-infrastrukturen och ändrar hur DML-instruktioner som INSERT, UPDATEoch DELETE hämtar lås.

Utan optimerad låsning kontrolleras frågepredikat rad för rad i en genomsökning genom att först ta ett uppdaterings -U) radlås. Om predikatet är uppfyllt tas ett exklusivt (X) radlås innan raden uppdateras och hålls kvar till slutet av transaktionen.

Med optimerad låsning, och när ögonblicksbildisoleringsnivån READ COMMITTED (RCSI) är aktiverad, kan predikat kontrolleras optimistiskt på den senaste bekräftade versionen av raden utan att ta några lås. Om predikatet inte uppfylls flyttas frågan till nästa rad i genomsökningen. Om predikatet är uppfyllt tas ett X radlås för att uppdatera raden.

Med andra ord tas låset efter att raden har kvalificerats för ändring. X-radlåset släpps så snart raduppdateringen är klar, före transaktionens slut.

Eftersom predikatutvärdering utförs utan att hämta några lås blockeras inte samtidiga frågor som ändrar olika rader.

Till exempel:

/* Confirm that optimized locking and read committed snapshot isolation (RCSI) are both enabled on this database. */
SELECT database_id,
       name,
       is_accelerated_database_recovery_on,
       is_optimized_locking_on,
       is_read_committed_snapshot_on
FROM sys.databases
WHERE name = DB_NAME();

CREATE TABLE t1
(
a int NOT NULL,
b int NULL
);

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

Session 1	Session 2
BEGIN TRANSACTION; UPDATE t1 SET b = b + 10 WHERE a = 1;
	BEGIN TRANSACTION; UPDATE t1 SET b = b + 10 WHERE a = 2;
COMMIT TRANSACTION;
	COMMIT TRANSACTION;

Utan optimerad låsning blockeras session 2 eftersom session 1 har ett U-lås på den rad som session 2 måste uppdatera. Men med optimerad låsning blockeras inte session 2 eftersom U-lås inte tas, och i den senaste bekräftade versionen av rad 1 är kolumn a lika med 1, vilket inte uppfyller predikatet för session 2.

LAQ utförs optimistiskt under antagandet att en rad inte ändras efter att ha kontrollerat predikatet. Om predikatet är uppfyllt och raden inte har ändrats efter kontroll av predikatet ändras den av den aktuella transaktionen.

Eftersom låsen U inte tas kan en samtidig transaktion ändra raden när predikatet har utvärderats. Om det finns en aktiv transaktion som har ett X TID-lås på raden väntar databasmotorn på att den ska slutföras. Om raden har ändrats efter att predikatet utvärderades tidigare omvärderar databasmotorn (kvalificerar om) predikatet igen innan raden ändras. Om predikatet fortfarande är uppfyllt ändras raden.

Predikatomvalificering stöds av en delmängd av frågemotoroperatorerna. Om predikatomvärdering behövs, men frågeplanen använder en operator som inte stöder predikatomvalificering, avbryter databasmotorn internt instruktionsbearbetningen och startar om den utan LAQ. När en sådan abort inträffar utlöses den lock_after_qual_stmt_abort utökade händelsen.

Vissa instruktioner, till exempel UPDATE -instruktioner med variabeltilldelning och -instruktioner med OUTPUT-satsen , kan inte avbrytas och startas om utan att deras semantik ändras. För sådana påståenden används inte LAQ.

I följande exempel utvärderas predikatet igen eftersom en annan transaktion har ändrat raden:

CREATE TABLE t3
(
a int NOT NULL,
b int NULL
);

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

Session 1	Session 2
BEGIN TRANSACTION; UPDATE t3 SET b = b + 10 WHERE a = 1;
	BEGIN TRANSACTION; UPDATE t3 SET b = b + 10 WHERE a = 1;
COMMIT TRANSACTION;
	COMMIT TRANSACTION;

Hoppa över indexlås (SIL)

Med TID-låsning används kortvariga exklusiva (X) radlås och avsiktligt exklusiva (IX) sidlås för att ändra rader. När RCSI och LAQ används är dessa lås bara nödvändiga om det kan finnas andra frågeställningar som har tillgång till raden och förväntar sig att den ska vara stabil. Exempel på dessa frågeställningar är de som körs under REPEATABLE READ- eller SERIALIZABLE-isoleringsnivån med hjälp av motsvarande låsningsledtrådar. Sådana frågor kallas radlåsningsfrågor (RLQ).

När det inte finns några RLQ-frågor som kommer åt en rad kan databasmotorn hoppa över att ta rad- och sidlås när du ändrar en rad och endast använda en exklusiv sidspärr. Den här optimeringen minskar låsningskostnaderna samtidigt som ACID-transaktionssemantik bevaras. Att hoppa över rad- och sidlås är särskilt fördelaktigt för transaktioner som ändrar ett stort antal rader.

För närvarande används SIL-optimeringen endast i följande fall:

• INSERT uttalanden angående heaps.
  • IX sidolås förbigås.
• UPDATE -instruktioner för klustrade index, icke-grupperade index och heaps.
  • IX sidlås och X radlås hoppas över.

SIL-optimeringen används för närvarande inte i följande fall:

• DELETE-uttalanden.
• UPDATE instruktioner på heaps om raden innehåller befintliga vidarebefordran pekare eller om nya vidarebefordran pekare läggs till av uppdateringen.
• Om den ändrade raden har några kolumner som använder LOB-datatyperna, till exempel varchar(max), nvarchar(max), varbinary(max)och json.
• För rader på sidor som har delats i samma transaktion.

LAQ-heuristik

Som beskrivs i Lås efter kvalificering (LAQ), när LAQ används, kan instruktioner som använder frågeoperatorer som inte stöder predikatomvalificering startas om internt och bearbetas utan LAQ. Om detta sker ofta kan omarbetningskostnaderna bli betydande. För att minimera omkostnaderna använder optimerad låsning en heuristikbaserad feedbackmekanism som inaktiverar LAQ om omkostnaderna överskrider tröskelvärdena.

För feedbackmekanismen mäts det arbete som utförs av en instruktion i antalet logiska läsningar. Om databasmotorn ändrar en rad som har ändrats av en annan transaktion efter att instruktionsbearbetningen har startat, behandlas det arbete som utförs av -instruktionen som potentiellt bortkastat eftersom -instruktionen kan behöva bearbetas på nytt.

När instruktioner körs underhåller databasmotorn LAQ-feedbackdata som spårar potentiellt bortkastat arbete, förekomster av ombearbetning av instruktioner och det totala arbete som kan bearbetas på nytt av instruktionerna.

LAQ inaktiveras om förhållandet mellan potentiellt bortkastat arbete och det totala arbetet eller förhållandet mellan antalet omarbetade instruktioner och det totala antalet instruktioner överskrider respektive tröskelvärden. Om båda dessa förhållanden faller under tröskelvärdena aktiveras LAQ igen.

LAQ-feedbackdata spåras på två nivåer:

• För en frågeplan.

  • Databasmotorn börjar spåra LAQ-feedback för en plan för den första förekomsten av ombearbetning av instruktioner.
  • Om en fråga samlas in i Query Store hämtas även LAQ-feedback i Query Store. Databasmotorn använder den här feedbacken för att hålla LAQ aktiverat eller inaktiverat för planen om databasen startas om.
  • Frågeplaner med insamlad LAQ-feedback har en rad med ett matchande plan_id värde i sys.query_store_plan_feedback katalogvy. Kolumnerna feature_id och feature_desc är inställda på 4 LAQ Feedback respektive .

• För en databas.

  • Feedback sammanställs för alla uttryck som inte har feedback på frågeplansnivå, till exempel om en sökfråga inte registreras i Query Store.
  • Feedback spåras sedan databasstarten och återskapas efter varje start.

När du beslutar att använda LAQ för ett uttryck använder systemet frågeplansåterkoppling om det är tillgängligt. I annat fall använder den feedback på databasnivå. Det innebär att vissa instruktioner kan köras med LAQ, och vissa kan köras utan LAQ. LAQ kan till exempel vara inaktiverat för en frågeplan, men aktiverat för databasen och vice versa.

LAQ-begränsningar

Lås efter kvalificering används inte i följande scenarier:

• När inaktiverad av LAQ-heuristik.
• Vid konflikt med låsningstips, till exempel UPDLOCK, READCOMMITTEDLOCK, XLOCK eller HOLDLOCK används.
• När transaktionsisoleringsnivån är annan än READ COMMITTED, eller när databasalternativet READ_COMMITTED_SNAPSHOT är inaktiverat.
• När tabellen som modificeras har ett kolumnlagringsindex.
• När DML-instruktionen innehåller variabeltilldelning.
• När DML-instruktionen har en OUTPUT-sats.
• När DML-instruktionen använder mer än en indexsöknings- eller genomsökningsoperator för att läsa de rader som ändras.
• I MERGE -uttalanden.

Frågebeteendeändringar med optimerad låsning och RCSI

Samtidiga arbetsbelastningar under skrivskyddad ögonblicksbildisolering (RCSI) som förlitar sig på strikt körningsordning för transaktioner kan uppleva skillnader i frågebeteende när optimerad låsning är aktiverad.

Tänk dig följande exempel där transaktion T2 uppdaterar tabellen t4 baserat på kolumn b som uppdaterades under transaktion T1.

CREATE TABLE t4
(
a int NOT NULL,
b int NULL
);

INSERT INTO t4
VALUES (1,1);
GO

Session 1	Session 2
BEGIN TRANSACTION T1; UPDATE t4 SET b = 2 WHERE a = 1;
	BEGIN TRANSACTION T2; UPDATE t4 SET b = 3 WHERE b = 2;
COMMIT TRANSACTION;
	COMMIT TRANSACTION;

Nu ska vi utvärdera resultatet av det tidigare scenariot med och utan lås efter kvalificering (LAQ).

utan LAQ

Utan LAQ blockeras UPDATE-instruktionen i transaktion T2 i väntan på att transaktionen T1 ska slutföras. När T1 har slutförts uppdaterar T2 kolumnen för radinställning från b till 3 eftersom T2:s villkor är uppfyllt.

Efter båda transaktionerna innehåller tabellen t4 följande rader:

 a | b
 1 | 3

med LAQ

Med LAQ använder transaktion T2 den senaste bekräftade versionen av raden där kolumnen b är lika med 1 för att utvärdera dess predikat (b = 2). Raden kvalificerar sig inte, och därför hoppas den över och instruktionen slutförs utan att blockeras av transaktion T1. I det här exemplet tar LAQ bort blockering men leder till olika resultat.

Efter båda transaktionerna innehåller tabellen t4 följande rader:

 a | b
 1 | 2

Important

Även utan LAQ bör program inte förutsätta att databasmotorn garanterar strikt ordning utan att använda låstips när radversionsbaserade isoleringsnivåer används. Vår allmänna rekommendation för kunder som kör samtidiga arbeten under RCSI där man förlitar sig på strikt utföringsordning av transaktioner (som visas i föregående exempel) är att använda strängare isoleringsnivåer som REPEATABLE READ och SERIALIZABLE.

Diagnostiska tillägg för optimerad låsning

Följande förbättringar hjälper dig att övervaka och felsöka blockering och dödlägen när optimerad låsning är aktiverad:

• Väntetyper för optimerad låsning
  • XACT väntetyper för låset S på TID och resursbeskrivningar i sys.dm_os_wait_stats:
    • LCK_M_S_XACT_READ – Inträffar när en uppgift väntar på ett delat lås på en XACTwait_resource typ, med syfte att läsa.
    • LCK_M_S_XACT_MODIFY – Inträffar när en uppgift väntar på att få ett delat lås på en XACTwait_resource typ, med avsikt att göra ändringar.
    • LCK_M_S_XACT – Inträffar när en uppgift väntar på ett delat lås på en XACTwait_resource typ, där avsikten inte kan härledas. Det här scenariot är inte vanligt.
• Låsa resurssynlighet
  • XACT låser resurser. Mer information resource_description finns i sys.dm_tran_locks.
• Synlighet för väntande resurs
  • XACT vänta på resurser. Mer information wait_resource finns i sys.dm_exec_requests.
• Deadlock-graf
  • Under varje resurs i dödlägesrapporten <resource-list>rapporterar <xactlock>-elementet de underliggande resurserna samt specifik information om lås för varje medlem i ett dödläge. Mer information och ett exempel finns i Optimerad låsning och dödlägen.
• Utökade händelser
  • Händelsen lock_after_qual_stmt_abort utlöses när en instruktion omprövas internt på grund av en konflikt med en annan transaktion. För mer information, se Lås efter kvalificering (LAQ).
  • Händelsen locking_stats utlöses för varje databas varannat minut och innehåller sammanställd låsningsstatistik för tidsintervallet, till exempel antalet låseskaleringar, om TID-låsning och LAQ-komponenter för optimerad låsning är aktiverade och antalet frågor där LAQ inte användes av olika skäl. Den här händelsen utlöses även om optimerad låsning är inaktiverad.
  • I SQL Server och Azure SQL Managed Instance locking_stats2 utlöses händelsen för varje databas varannat minut och tillhandahåller statistik över hoppa över indexlås och LAQ-heuristik för tidsintervallet .

Metodtips med optimerad låsning

Aktivera skrivskyddade ögonblicksbildisolering (RCSI)

För att maximera fördelarna med optimerad låsning rekommenderar vi att du aktiverar skrivskyddad ögonblicksbildisolering (RCSI) på databasen och använder READ COMMITTED isolering som standardisoleringsnivå.

I Azure SQL Database och SQL Database i Microsoft Fabric är RCSI aktiverat som standard och READ COMMITTED är standardisoleringsnivån. När RCSI är aktiverat och när du använder isoleringsnivån READ COMMITTED läser läsarna en version av raden från snapshoten som togs i början av instruktionen. Med LAQ kvalificerar författare rader enligt predikatet baserat på den senaste bekräftade versionen av raden och utan att hämta U lås. Med LAQ väntar en sökfråga bara om raden uppfyller kraven och det finns en aktiv skrivprocess på den raden. Om du kvalificerar baserat på den senaste bekräftade versionen och endast låser de kvalificerade raderna minskar blockeringen och ökar samtidigheten.

Undvik att låsa ledtrådar

Även om tabell- och frågeledtrådar, som ,, UPDLOCK, READCOMMITTEDLOCK, XLOCK, HOLDLOCKosv., respekteras när optimerad låsning är aktiverad, minskar de effekten av denna optimering. Låsledtrådar tvingar databasmotorn att ta rad- eller sidlås och hålla kvar dem till slutet av transaktionen för att respektera avsikten med låsledtrådarna. Vissa program har logik där låstips behövs, till exempel när du läser en rad med UPDLOCK tips och sedan uppdaterar den senare. Vi rekommenderar att du endast använder låstips där det behövs.

Med optimerad låsning finns det inga begränsningar för befintliga frågor och frågor behöver inte skrivas om. Frågor som inte använder tips drar nytta av optimerad låsning mest.

Ett tabelltips för en tabell i en fråga inaktiverar inte optimerad låsning för andra tabeller i samma fråga. Dessutom påverkar optimerad låsning endast låsningsbeteendet för tabeller som uppdateras av en DML-instruktion, till exempel INSERT, UPDATE, DELETEeller MERGE. Till exempel:

CREATE TABLE t5
(
a int NOT NULL,
b int NOT NULL
);

CREATE TABLE t6
(
a int NOT NULL,
b int NOT NULL
);
GO

INSERT INTO t5 VALUES (1,10),(2,20),(3,30);
INSERT INTO t6 VALUES (1,10),(2,20),(3,30);
GO

UPDATE t5 SET t5.b = t6.b
FROM t5
INNER JOIN t6 WITH (UPDLOCK)
ON t5.a = t6.a;

I föregående frågeexempel påverkas endast tabell t6 av låstipset, medan t5 fortfarande kan dra nytta av optimerad låsning.

UPDATE t5
    SET t5.b = t6.b
FROM t5 WITH (REPEATABLEREAD)
     INNER JOIN t6
         ON t5.a = t6.a;

I föregående frågeexempel använder endast tabell t5REPEATABLE READ isoleringsnivå och håller lås tills slutet av transaktionen. Andra uppdateringar av t5 kan fortfarande dra nytta av optimerad låsning. Samma sak gäller för HOLDLOCK-ledtråd.

Vanliga frågor och svar

Är optimerad låsning aktiverad som standard i både nya och befintliga databaser?

I Azure SQL Database, Azure SQL Managed Instance^AUTD och SQL Database i Microsoft Fabric, ja. I SQL Server 2025 (17.x) inaktiveras optimerad låsning som standard, men kan aktiveras på alla användardatabaser som har accelererad databasåterställning aktiverad.

Hur kan jag identifiera om optimerad låsning är aktiverat?

Se Är optimerad låsning aktiverat?

Vad händer om jag vill tvinga frågekommandon att blockera trots optimerad låsning?

Om RCSI är aktiverat använder du tabelltipset READCOMMITTEDLOCK för att tvinga fram blockering mellan två frågor när optimerad låsning är aktiverad.

Används optimerad låsning på skrivskyddade sekundära repliker?

Nej, eftersom DML-instruktioner inte kan köras på skrivskyddade repliker och motsvarande rad- och sidlås inte tas.

Används optimerad låsning vid ändring av data i tempdb och i temporära tabeller?

Inte just nu.

Relaterat innehåll

• Guide för transaktionslåsning och radversionering
• RCSI (Isolering vid läsning av åtagna ögonblicksbilder)
• sys.dm_tran_locks (Transact-SQL)
• Accelererad databasåterställning