Geoptimaliseerde vergrendeling

Van toepassing op: SQL Server 2025 (17.x) Azure SQL Database Azure SQL Managed Instance SQL-database in Microsoft Fabric

Geoptimaliseerde vergrendeling biedt een verbeterd mechanisme voor transactievergrendeling om het blokkerings- en geheugenverbruik van vergrendelingen voor gelijktijdige transacties te verminderen.

Wat is geoptimaliseerde vergrendeling?

Geoptimaliseerde vergrendeling helpt om het geheugen van de vergrendeling te verminderen, omdat er zeer weinig vergrendelingen worden bewaard, zelfs voor grote transacties. Bovendien voorkomt geoptimaliseerde vergrendeling escalaties en kunnen bepaalde soorten impasses worden vermeden. Hierdoor is er meer gelijktijdige toegang tot de tabel mogelijk.

Geoptimaliseerde vergrendeling bestaat uit twee primaire onderdelen: transactie-id (TID)-vergrendeling en slot na kwalificatie (LAQ).

Een transactie-id (TID) is een unieke id van een transactie. Elke rij wordt gelabeld met de laatste TID die deze heeft gewijzigd. In plaats van mogelijk veel sleutel- of rij-id-vergrendelingen, wordt één vergrendeling op de TID gebruikt om alle gewijzigde rijen te beveiligen. Zie Transaction ID (TID)-vergrendelingvoor meer informatie.
Vergrendelen na kwalificatie (LAQ) is een optimalisatie die querypredicaten evalueert met behulp van de meest recente vastgelegde versie van de rij zonder een vergrendeling te verkrijgen, waardoor gelijktijdigheid wordt verbeterd. LAQ vereist isolatie van vastgelegde momentopnamen (RCSI). Voor meer informatie, zie Lock after qualification (LAQ).

Voorbeeld:

Zonder geoptimaliseerde vergrendeling is het bijwerken van 1000 rijen in een tabel mogelijk 1000 exclusieve rijvergrendelingen (X) vereist tot het einde van de transactie.
Met geoptimaliseerde vergrendeling kan het bijwerken van 1000 rijen in een tabel 1.000 X rijvergrendelingen vereisen, maar elke vergrendeling wordt vrijgegeven zodra elke rij wordt bijgewerkt, en slechts één X TID-vergrendeling wordt bewaard tot het einde van de transactie. Omdat vergrendelingen snel worden vrijgegeven, wordt het geheugengebruik beperkt en escalatie van vergrendelingen veel minder waarschijnlijk is, waardoor de gelijktijdigheid van werkbelastingen wordt verbeterd.

Note

Het inschakelen van geoptimaliseerde vergrendeling vermindert of elimineert rij- en paginavergrendelingen die zijn verkregen door de DML-instructies (Data Modification Language), zoals INSERT, UPDATE, DELETE, MERGE. Dit heeft geen invloed op andere soorten database- en objectvergrendelingen, zoals schemavergrendelingen.

Availability

De volgende tabel bevat een overzicht van de beschikbaarheid en de ingeschakelde status van geoptimaliseerde vergrendeling op SQL-platforms.

Platform	Available	Standaard ingeschakeld
Azure SQL Database	Yes	Ja (altijd ingeschakeld)
SQL-database in Microsoft Fabric	Yes	Ja (altijd ingeschakeld)
Azure SQL Managed Instance^AUTD	Yes	Ja (altijd ingeschakeld)
Azure SQL Managed Instance²⁰²⁵	Yes	Ja (altijd ingeschakeld)
Azure SQL Managed Instance²⁰²²	No	N/A
SQL Server 2025 (17.x)	Yes	Nee (kan per database worden ingeschakeld)
SQL Server 2022 (16.x) en oudere versies	No	N/A

In- en uitschakelen

Gebruik de ALTER DATABASE ... SET OPTIMIZED_LOCKING = ON | OFF opdracht om geoptimaliseerde vergrendeling voor een SQL Server-database in of uit te schakelen. Raadpleeg ALTER DATABASE SET optiesvoor meer informatie.

Geoptimaliseerde vergrendeling bouwt voort op andere databasefuncties:

U moet versneld databaseherstel (ADR) inschakelen voor een database voordat u geoptimaliseerde vergrendeling kunt inschakelen. Omgekeerd moet u, om ADR uit te schakelen, eerst geoptimaliseerde vergrendeling uitschakelen als deze is ingeschakeld.
Om optimaal te profiteren van geoptimaliseerde vergrendeling, moet RCSI (Read Committed Snapshot Isolation) voor de database zijn ingeschakeld. Het LAQ onderdeel van geoptimaliseerde vergrendeling is alleen van kracht als RCSI is ingeschakeld.

ADR is altijd ingeschakeld in Azure SQL Database, Azure SQL Managed Instance en SQL Database in Microsoft Fabric. RCSI is standaard ingeschakeld in Azure SQL Database en SQL-database in Microsoft Fabric.

Als u wilt controleren of deze opties zijn ingeschakeld voor uw huidige database, maakt u verbinding met de database en voert u de volgende T-SQL-query uit:

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();

Is geoptimaliseerde vergrendeling ingeschakeld?

Geoptimaliseerde vergrendeling is ingeschakeld per database. Maak verbinding met uw database en gebruik vervolgens de volgende query om te controleren of geoptimaliseerde vergrendeling is ingeschakeld:

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

Result	Description
`0`	Geoptimaliseerde vergrendeling is uitgeschakeld.
`1`	Geoptimaliseerde vergrendeling is ingeschakeld.
`NULL`	Geoptimaliseerde vergrendeling is niet beschikbaar.

U kunt ook de catalogusweergave sys.databases gebruiken. Als u bijvoorbeeld wilt zien of geoptimaliseerde vergrendeling is ingeschakeld voor alle databases, voert u de volgende query uit:

SELECT database_id,
       name,
       is_optimized_locking_on
FROM sys.databases;

Overzicht van vergrendeling

Dit is een kort overzicht van het gedrag wanneer geoptimaliseerde vergrendeling niet is ingeschakeld. Raadpleeg de handleiding Transactievergrendeling en rijversiebeheer voor meer informatie.

In de database-engine is vergrendelen een mechanisme dat voorkomt dat meerdere transacties dezelfde gegevens tegelijkertijd bijwerken om de ACID- eigenschappen van transacties te garanderen.

Wanneer een transactie gegevens moet wijzigen, wordt een vergrendeling voor de gegevens aangevraagd. De vergrendeling wordt verleend als er geen andere conflicterende vergrendelingen op de gegevens worden vastgehouden, en de transactie kan doorgaan met de wijziging. Als een andere conflicterende vergrendeling op de gegevens wordt bewaard, moet de transactie wachten totdat de vergrendeling is vrijgegeven voordat deze kan worden voortgezet.

Wanneer meerdere transacties gelijktijdig toegang proberen te krijgen tot dezelfde gegevens, moet de database-engine mogelijk complexe conflicten met gelijktijdige lees- en schrijfbewerkingen oplossen. Vergrendelen is een van de mechanismen waarmee de engine de semantiek voor de isolatieniveaus van een ANSI SQL-transactie kan bieden . Hoewel het vergrendelen van databases essentieel is, kunnen minder gelijktijdigheid, impasses, complexiteit en vergrendelingsoverhead van invloed zijn op de prestaties en schaalbaarheid.

Vergrendeling van transactie-id (TID)

Wanneer isolatieniveaus op basis van rijversiebeheer worden gebruikt of wanneer ADR is ingeschakeld, bevat elke rij in de database intern een transactie-ID (TID). TID wordt samen met de rij opgeslagen. Elke transactie die een rij wijzigt, stempelt de rij met zijn TID.

Met TID-vergrendeling wordt, in plaats van een vergrendeling op de sleutel van de rij te nemen, een vergrendeling genomen op de TID van de rij. De wijzigingstransactie heeft een X-vergrendeling op zijn TID. Andere transacties verkrijgen een S-vergrendeling op de TID om te wachten totdat de eerste transactie voltooid is. Met TID-vergrendeling worden pagina- en rijvergrendelingen nog steeds gebruikt voor wijzigingen, maar elke pagina- en rijvergrendeling wordt vrijgegeven zodra elke rij wordt gewijzigd. De enige vergrendeling tot het einde van de transactie is de enkele X vergrendeling op de TID-resource, waarbij meerdere pagina- en rijvergrendelingen (sleutelvergrendelingen) worden vervangen.

Bekijk het volgende voorbeeld met vergrendelingen voor de huidige sessie terwijl een schrijftransactie actief is:

/* 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;

Als geoptimaliseerde vergrendeling is ingeschakeld, bevat de aanvraag slechts één X vergrendeling op de resource XACT (transactie).

Als geoptimaliseerde vergrendeling niet is ingeschakeld, bevat dezelfde aanvraag vier vergrendelingen: één IX (exclusieve intentievergrendeling) op de pagina met de rijen en drie X sleutelvergrendelingen op elke rij:

De sys.dm_tran_locks dynamische beheerweergave (DMV) is handig bij het onderzoeken of oplossen van vergrendelingsproblemen. Hier wordt het gebruikt om geoptimaliseerde vergrendeling in actie te observeren.

Vergrendeling na kwalificatie (LAQ)

Voortbouwend op de TID-infrastructuur verandert het LAQ-onderdeel van geoptimaliseerde vergrendeling hoe DML-instructies zoals INSERT, UPDATEen DELETE vergrendelingen verkrijgen.

Zonder geoptimaliseerde vergrendeling worden querypredicaten rij voor rij in een scan gecontroleerd door eerst een update (U) rijvergrendeling te nemen. Als aan het predicaat is voldaan, wordt een exclusieve rijvergrendeling (X) verkregen voordat de rij wordt bijgewerkt en vastgehouden tot het einde van de transactie.

Met geoptimaliseerde vergrendeling en wanneer het READ COMMITTED isolatieniveau voor momentopnamen (RCSI) is ingeschakeld, kunnen predicaten optimistisch worden gecontroleerd op de nieuwste vastgelegde versie van de rij zonder het nemen van vergrendelingen. Als het predicaat niet voldoet, wordt de query verplaatst naar de volgende rij in de scan. Als aan het predicaat wordt voldaan, wordt er een X-rijvergrendeling genomen om de rij te actualiseren.

Met andere woorden, de vergrendeling wordt genomen na kwalificatie voor wijziging van de rij. De X rijvergrendeling wordt vrijgegeven zodra de rijupdate is voltooid, vóór het einde van de transactie.

Aangezien predicaatevaluatie wordt uitgevoerd zonder dat er vergrendelingen worden verkregen, blokkeren query's die tegelijkertijd verschillende rijen wijzigen elkaar niet.

Voorbeeld:

/* 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

Sessie 1	sessie 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;`

Zonder geoptimaliseerde vergrendeling wordt sessie 2 geblokkeerd omdat sessie 1 een U-vergrendeling op de rij houdt die sessie 2 moet bijwerken. Met geoptimaliseerde vergrendeling wordt sessie 2 echter niet geblokkeerd omdat U vergrendelingen niet worden gebruikt en omdat in de meest recente vastgelegde versie van rij 1 kolom a gelijk is aan 1, wat niet voldoet aan het predicaat van sessie 2.

LAQ wordt optimistisch uitgevoerd op basis van de veronderstelling dat een rij niet wordt gewijzigd na het controleren van het predicaat. Als aan het predicaat wordt voldaan en de rij niet is gewijzigd nadat het predicaat is gecontroleerd, wordt deze gewijzigd door de huidige transactie.

Omdat de U vergrendelingen niet worden genomen, kan een gelijktijdige transactie de rij wijzigen nadat het predicaat is geëvalueerd. Als er een actieve transactie is met een X TID-vergrendeling op de rij, wacht de database-engine totdat deze is voltooid. Als de rij is gewijzigd nadat het predicaat eerder is geëvalueerd, evalueert de database-engine het predicaat opnieuw (hergekwalificeerd) voordat de rij wordt gewijzigd. Als er nog steeds aan de voorwaarde is voldaan, wordt de rij gewijzigd.

Herkwalificatie van predicates wordt ondersteund door een subset van de query-engine operators. Als herbeoordeling van predicaten nodig is, maar het queryplan een operator gebruikt die geen herkwalificatie van predicaten ondersteunt, wordt de verwerking van de instructie intern door de database-engine afgebroken en opnieuw gestart zonder LAQ. Wanneer een dergelijke abort optreedt, wordt de lock_after_qual_stmt_abort uitgebreide gebeurtenis geactiveerd.

Sommige instructies, bijvoorbeeld UPDATE instructies met variabele toewijzing en instructies met de OUTPUT-component , kunnen niet worden afgebroken en opnieuw worden gestart zonder hun semantiek te wijzigen. Voor dergelijke uitspraken is LAQ niet gebruikt.

In het volgende voorbeeld wordt het predicaat opnieuw geëvalueerd omdat een andere transactie de rij heeft gewijzigd:

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

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

Sessie 1	sessie 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;`

Indexvergrendelingen overslaan (SIL)

Met TID-vergrendeling worden exclusieve (X) rijvergrendelingen voor korte duur en intentie-exclusieve (IX) paginavergrendelingen gebruikt om rijen te wijzigen. Wanneer RCSI en LAQ worden gebruikt, zijn deze vergrendelingen alleen nodig als er andere query's zijn die toegang krijgen tot de rij en verwachten dat deze stabiel blijft. Voorbeelden van dergelijke query's zijn query's die worden uitgevoerd onder de REPEATABLE READ of SERIALIZABLE isolatieniveaus, of met behulp van de bijbehorende vergrendelingshints. Dergelijke query's worden ook wel rijvergrendelingsquery's (RLQ) genoemd.

Wanneer er geen RLQ-query's zijn die toegang hebben tot een rij, kan de database-engine het overnemen van rij- en paginavergrendelingen overslaan bij het wijzigen van een rij en alleen een exclusieve paginavergrendeling gebruiken. Deze optimalisatie vermindert de vergrendelingsoverhead terwijl acid-transactiesemantiek behouden blijft. Het overslaan van rij- en paginavergrendelingen heeft met name voordelen bij het wijzigen van een groot aantal rijen.

Momenteel wordt de SIL-optimalisatie alleen gebruikt in de volgende gevallen:

INSERT uitspraken over heaps.
- IX paginavergrendelingen worden overgeslagen.
UPDATE verklaringen over geclusterde indexen, niet-geclusterde indexen en heaps.
- IX paginavergrendelingen en X rijvergrendelingen worden overgeslagen.

De SIL-optimalisatie wordt momenteel niet gebruikt in de volgende gevallen:

DELETE verklaringen.
UPDATE instructies betreffende heaps als de rij bestaande doorstuurpunten bevat of als er door de update nieuwe doorstuurpunten worden toegevoegd.
Als de gewijzigde rij kolommen bevat met behulp van de LOB-gegevenstypen, zoals varchar(max), nvarchar(max), varbinary(max)en json.
Voor rijen op pagina's die zijn gesplitst in dezelfde transactie.

LAQ-heuristiek

Zoals beschreven in Lock na kwalificatie (LAQ), kunnen instructies die gebruikmaken van queryoperators die geen ondersteuning bieden voor predicaatrequalificatie intern opnieuw worden opgestart en verwerkt zonder LAQ. Als dit vaak gebeurt, kan de overhead van herverwerking aanzienlijk worden. Om de overhead te minimaliseren, gebruikt geoptimaliseerde vergrendeling een feedbackmechanisme op basis van heuristiek dat LAQ uitschakelt als de overhead de drempelwaarden overschrijdt.

Voor het feedbackmechanisme wordt het werk dat door een instructie wordt uitgevoerd, gemeten in het aantal logische leesbewerkingen. Als de database-engine een rij wijzigt die is gewijzigd door een andere transactie nadat de verwerking van de instructie is gestart, wordt het werk dat door de instructie wordt uitgevoerd, behandeld als mogelijk verspild omdat de instructie mogelijk opnieuw moet worden verwerkt.

Terwijl instructies worden uitgevoerd, onderhoudt de database-engine LAQ-feedbackgegevens die het mogelijk verspilde werk bijhouden, het aantal exemplaren van het opnieuw verwerken van instructies en het totale werk dat wordt uitgevoerd door de instructies die mogelijk opnieuw worden verwerkt.

LAQ is uitgeschakeld als de verhouding van het potentieel verspilde werk tot het totale werk, of de verhouding van het aantal herverwerkte instructies tot het totale aantal instructies de respectieve drempelwaarden overschrijdt. Als beide verhoudingen onder de drempelwaarden vallen, kan LAQ opnieuw worden ingeschakeld.

LAQ-feedbackgegevens worden op twee niveaus bijgehouden:

Voor een query plan.
- De database-engine start bij de eerste keer dat een instructie opnieuw wordt verwerkt met het bijhouden van LAQ-feedback voor een plan.
- Als een query wordt vastgelegd in Query Store, wordt ook LAQ-feedback vastgelegd in Query Store. De database-engine gebruikt deze feedback om LAQ ingeschakeld of uitgeschakeld te houden voor het plan als de database opnieuw wordt opgestart.
- Queryplannen met vastgelegde LAQ-feedback hebben een rij met een overeenkomende plan_id waarde in de sys.query_store_plan_feedback catalogusweergave. De feature_id en feature_desc kolommen zijn respectievelijk ingesteld op 4 en LAQ Feedback.
Voor een database.
- Feedback wordt geaggregeerd voor alle instructies die geen feedback op queryplanniveau hebben, bijvoorbeeld als een query niet wordt vastgelegd in Query Store.
- Feedback wordt bijgehouden sinds het opstarten van de database en opnieuw wordt gemaakt na elke opstart.

Bij het bepalen of LAQ moet worden gebruikt voor een verklaring, gebruikt het systeem de feedback van het queryplan, als deze beschikbaar is. Anders wordt gebruikgemaakt van feedback op databaseniveau. Dit betekent dat sommige instructies met LAQ kunnen worden uitgevoerd, terwijl andere zonder LAQ worden uitgevoerd. LAQ kan bijvoorbeeld worden uitgeschakeld voor een queryplan, maar is ingeschakeld voor de database en omgekeerd.

LAQ-beperkingen

Vergrendelen na kwalificatie wordt niet gebruikt in de volgende scenario's:

Wanneer deze functie is uitgeschakeld door LAQ-heuristieken.
Bij conflicterende vergrendelingshints, zoals UPDLOCK, READCOMMITTEDLOCK, XLOCKof HOLDLOCK worden gebruikt.
Wanneer het niveau van transactieisolatie anders is dan READ COMMITTEDof wanneer de READ_COMMITTED_SNAPSHOT databaseoptie is uitgeschakeld.
Wanneer de tabel die wordt gewijzigd, een columnstore-index heeft.
Wanneer de DML-instructie variabele toewijzing bevat.
Wanneer de DML-instructie een OUTPUT component heeft.
Wanneer de DML-instructie meer dan één indexzoek- of scanoperator gebruikt om de rijen te lezen die worden gewijzigd.
In MERGE verklaringen.

Wijzigingen in querygedrag met geoptimaliseerde vergrendeling en RCSI

Gelijktijdige werkbelastingen onder vastgelegde isolatie van momentopnamen (RCSI) die afhankelijk zijn van een strikte uitvoeringsvolgorde van transacties, kunnen verschillen ondervinden in het querygedrag wanneer geoptimaliseerde vergrendeling is ingeschakeld.

Bekijk het volgende voorbeeld waarbij transactie T2 de tabel bijwerkt t4 op basis van kolom b die is bijgewerkt tijdens transactie T1.

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

INSERT INTO t4
VALUES (1,1);
GO

Sessie 1	sessie 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;`

Laten we het resultaat van het vorige scenario evalueren met en zonder de vergrendeling na kwalificatie (LAQ).

Zonder LAQ

Zonder LAQ wordt de UPDATE-verklaring in transactie T2 geblokkeerd, wachtend tot transactie T1 is voltooid. Zodra T1 is voltooid, werkt T2 de rij-instellingenkolom bij van b naar 3 omdat aan het predicaat van T2 wordt voldaan.

Nadat beide transacties zijn doorgevoerd, bevat de tabel t4 de volgende rijen:

 a | b
 1 | 3

met LAQ

Met LAQ gebruikt transactie T2 de meest recente vastgelegde versie van de rij, waarbij kolom b gelijk is aan 1 om het predicaat (b = 2) te evalueren. De rij komt niet in aanmerking; vandaar dat het wordt overgeslagen en de instructie wordt voltooid zonder dat deze is geblokkeerd door transactie T1. In dit voorbeeld verwijdert LAQ blokkeringen, maar leidt dit tot verschillende resultaten.

Nadat beide transacties zijn doorgevoerd, bevat de tabel t4 de volgende rijen:

 a | b
 1 | 2

Important

Zelfs zonder LAQ mogen toepassingen niet aannemen dat de database-engine strikte volgorde garandeert zonder vergrendelingshints te gebruiken wanneer isolatieniveaus op basis van rijversies worden gebruikt. Onze algemene aanbeveling voor klanten die gelijktijdige workloads uitvoeren onder RCSI die afhankelijk zijn van een strikte uitvoeringsvolgorde van transacties (zoals in het vorige voorbeeld) is om strengere isolatieniveaus te gebruiken, zoals REPEATABLE READ en SERIALIZABLE.

Diagnostische toevoegingen voor geoptimaliseerde vergrendeling

De volgende verbeteringen helpen u bij het bewaken en oplossen van problemen met blokkeren en impasses wanneer geoptimaliseerde vergrendeling is ingeschakeld:

Wachttypen voor geoptimaliseerde vergrendeling
- XACT wachttypen voor de vergrendeling op de S TID en resourcebeschrijvingen in sys.dm_os_wait_stats:
  - LCK_M_S_XACT_READ: treedt op wanneer een taak wacht op een gedeelde vergrendeling op een XACTwait_resource type, met een intentie om te lezen.
  - LCK_M_S_XACT_MODIFY: treedt op wanneer een taak wacht op een gedeelde vergrendeling op een XACTwait_resource type, met een intentie om te wijzigen.
  - LCK_M_S_XACT: treedt op wanneer een taak wacht op een gedeelde vergrendeling op een XACTwait_resource type, waarbij de intentie niet kan worden afgeleid. Dit scenario is niet gebruikelijk.
Middelenzichtbaarheid vergrendelen
- XACT resources vergrendelen. Zie resource_description voor meer informatie.
Zichtbaarheid van wachtende resources
- XACT wacht op bronnen. Zie wait_resource voor meer informatie.
Impassegrafiek
- Onder elke resource in het impasserapport <resource-list>rapporteert elk <xactlock> element de onderliggende resources en specifieke informatie voor vergrendelingen van elk lid van een impasse. Zie Geoptimaliseerde vergrendelingen en impassesvoor meer informatie en een voorbeeld.
Uitgebreide gebeurtenissen
- De lock_after_qual_stmt_abort gebeurtenis wordt geactiveerd wanneer een instructie intern opnieuw wordt verwerkt vanwege een conflict met een andere transactie. Voor meer informatie, zie Lock after qualification (LAQ).
- De locking_stats gebeurtenis wordt elke paar minuten voor elke database geactiveerd en biedt statistische vergrendelingsstatistieken voor het tijdsinterval, zoals het aantal escalaties van vergrendelingen, of TID-vergrendeling en LAQ-onderdelen van geoptimaliseerde vergrendeling zijn ingeschakeld en het aantal query's waarvoor LAQ om verschillende redenen niet is gebruikt. Deze gebeurtenis wordt geactiveerd, zelfs als geoptimaliseerde vergrendeling is uitgeschakeld.
- In SQL Server en Azure SQL Managed Instance wordt de locking_stats2 gebeurtenis elke paar minuten afgevuurd voor elke database en worden de skip index locks en LAQ-heuristische statistieken voor het tijdsinterval geleverd.

Aanbevolen procedures met geoptimaliseerde vergrendeling

Isolatie van vastgelegde momentopnamen inschakelen (RCSI)

Om de voordelen van geoptimaliseerde vergrendeling te maximaliseren, is het raadzaam om lees vastgelegde momentopname-isolatie (RCSI) in te schakelen voor de database en isolatie te gebruiken READ COMMITTED als het standaardisolatieniveau.

In Azure SQL Database en SQL-database in Microsoft Fabric is RCSI standaard ingeschakeld en READ COMMITTED is het standaardisolatieniveau. Wanneer RCSI is ingeschakeld en het READ COMMITTED-isolatieniveau wordt gebruikt, lezen lezers een versie van de rij uit de momentopname aan het begin van de instructie. Met LAQ kwalificeren schrijvers rijen per predicaat op basis van de meest recente vastgelegde versie van de rij en zonder U vergrendelingen te verkrijgen. Met LAQ wacht een query alleen als de rij in aanmerking komt en er een actieve schrijftransactie voor die rij is. Kwalificeren op basis van de meest recente vastgelegde versie en het vergrendelen van alleen de gekwalificeerde rijen vermindert de blokkering en verhoogt de gelijktijdigheid.

Vermijd vergrendelingshints

Hoewel tabel- en queryhints zoals UPDLOCK, READCOMMITTEDLOCK, XLOCK, HOLDLOCK, enzovoort worden gehonoreerd wanneer geoptimaliseerde vergrendeling is ingeschakeld, verminderen ze het voordeel van geoptimaliseerde vergrendeling. Vergrendelingshints dwingen de database-engine rij- of paginavergrendelingen te nemen en vast te houden tot het einde van de transactie, om de intentie van de vergrendelingshints te respecteren. Sommige toepassingen hebben logica waarbij vergrendelingshints nodig zijn, bijvoorbeeld wanneer u een rij leest met de UPDLOCK hint en deze later bijwerkt. We raden u aan alleen vergrendelingshints te gebruiken wanneer dat nodig is.

Met geoptimaliseerde vergrendeling zijn er geen beperkingen voor bestaande query's en query's hoeven niet opnieuw te worden geschreven. Query's die geen hints gebruiken, profiteren van geoptimaliseerde vergrendeling.

Een tabelhint voor één tabel in een query schakelt geoptimaliseerde vergrendeling voor andere tabellen in dezelfde query niet uit. Bovendien is geoptimaliseerde vergrendeling alleen van invloed op het vergrendelingsgedrag van tabellen die worden bijgewerkt door een DML-instructie, zoals INSERT, UPDATE, DELETEof MERGE. Voorbeeld:

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;

In het vorige queryvoorbeeld wordt alleen de tabel t6 beïnvloed door de vergrendelingshint, terwijl t5 nog steeds kan profiteren van geoptimaliseerde vergrendeling.

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

In het vorige queryvoorbeeld gebruikt alleen de tabel t5 het REPEATABLE READ isolatieniveau en wachtvergrendelingen tot het einde van de transactie. Andere updates voor t5 kunnen nog steeds profiteren van geoptimaliseerde vergrendeling. Hetzelfde geldt voor de HOLDLOCK hint.

Veelgestelde vragen (FAQ)

Is geoptimaliseerde vergrendeling standaard ingeschakeld in zowel nieuwe als bestaande databases?

Azure SQL Database, Azure SQL Managed Instance^AUTD en SQL Database in Microsoft Fabric bieden dat, ja. In SQL Server 2025 (17.x) geoptimaliseerde vergrendeling is standaard uitgeschakeld, maar kan worden ingeschakeld voor elke gebruikersdatabase waarvoor versneld databaseherstel is ingeschakeld.

Hoe kan ik detecteren of geoptimaliseerde vergrendeling is ingeschakeld?

Zie Is geoptimaliseerde vergrendeling ingeschakeld?

Wat moet ik doen als ik wil afdwingen dat query's worden geblokkeerd ondanks geoptimaliseerde vergrendeling?

Als RCSI is ingeschakeld, gebruikt u de READCOMMITTEDLOCK tabelhint om blokkeren tussen twee query's af te dwingen wanneer geoptimaliseerde vergrendeling is ingeschakeld.

Wordt geoptimaliseerde vergrendeling gebruikt voor alleen-lezen secundaire replica's?

Nee, omdat DML-instructies niet kunnen worden uitgevoerd op alleen-lezen replica's en de bijbehorende rij- en paginavergrendelingen worden niet gebruikt.

Wordt geoptimaliseerde vergrendeling gebruikt bij het wijzigen van gegevens in tempdb en in tijdelijke tabellen?

Niet op dit moment.

Handleiding voor transactievergrendeling en rijversiebeheer
RCSI - (Vastgelegde momentopname-isolatie) lezen
sys.dm_tran_locks (Transact-SQL)
versneld databaseherstel

Feedback

Is deze pagina nuttig?

Last updated on 2025-11-24