Geoptimaliseerde vergrendeling

Van toepassing op: SQL Server 2025 (17.x) Preview Azure SQL DatabaseAzure SQL Managed InstanceSQL-database in Microsoft Fabric Preview

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. 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 1000 X rijvergrendelingen vereisen, maar elke vergrendeling wordt vrijgegeven zodra elke rij wordt bijgewerkt en slechts één 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.

Availability

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

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.

In Azure SQL Database en Azure SQL Managed Instance is ADR altijd ingeschakeld en RCSI is standaard ingeschakeld.

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 gebruikersdatabase. 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;

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). Deze TID blijft behouden op schijf. Elke transactie die een rij wijzigt, voorziet die rij van zijn TID-stempel.

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, zoals het observeren van geoptimaliseerde vergrendeling in actie.

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 RCSI (Snapshot Isolation Level) is ingeschakeld, kunnen predicaten optimistisch worden gecontroleerd op de nieuwste vastgelegde versie van de rij zonder vergrendelingen te nemen. 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

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 er geen U-sloten worden toegepast, kan een concurrente 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 (herkwalificatie) voordat de rij wordt gewijzigd. Als er nog steeds aan de voorwaarde is voldaan, wordt de rij gewijzigd.

Herkwalificatie van predicaat wordt ondersteund door een subset van de operators van de query-engine. Als het nodig is om het predicaat opnieuw te evalueren, maar het queryplan een operator gebruikt die geen ondersteuning biedt voor predicaatherkwalificatie, beëindigt de database-engine intern de verwerking van de instructie en start deze opnieuw 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

LAQ-heuristiek

Zoals beschreven in Lock na kwalificatie (LAQ), kunnen sommige verklaringen intern opnieuw worden opgestart en verwerkt zonder LAQ. Als dit vaak gebeurt, kan de overhead van herhaalde verwerking aanzienlijk worden. Om deze overhead tot een minimum te houden, gebruikt geoptimaliseerde vergrendeling een heuristiekmechanisme om herhaalde verwerking bij te houden. Met dit mechanisme wordt LAQ voor de database uitgeschakeld als de overhead een drempelwaarde overschrijdt.

Voor het heuristische mechanisme wordt het werk dat door een opdracht wordt uitgevoerd gemeten op basis van het aantal verwerkte pagina's (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 wordt afgebroken en opnieuw wordt gestart. Het systeem houdt het totale potentieel verspilde werk bij en het totale werk dat door alle instructies in de database wordt uitgevoerd.

LAQ is uitgeschakeld voor de database als het percentage van het potentieel verspilde werk een drempelwaarde overschrijdt. LAQ is ook uitgeschakeld als het aantal opnieuw gestarte opdrachten een drempel overschrijdt.

Als het verspilde werk en het aantal opnieuw gestarte instructies onder de respectieve drempelwaarden vallen, wordt LAQ opnieuw ingeschakeld voor de database.

LAQ-beperkingen

Vergrendelen na kwalificatie kan mogelijk niet worden 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

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

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 wordt afgebroken en opnieuw wordt gestart vanwege een conflict met een andere transactie. Voor meer informatie, zie Lock after qualification (LAQ).
  • In SQL Server 2025 (17.x) Preview en Azure SQL Managed Instance wordt de locking_stats gebeurtenis elke paar minuten geactiveerd voor elke database en worden statistische vergrendelingsstatistieken voor het tijdsinterval geboden, 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.

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. Als dit nog niet is ingeschakeld, schakelt u RCSI in door verbinding te maken met de master-database en de volgende instructie uit te voeren:

ALTER DATABASE [database-name-placeholder] SET READ_COMMITTED_SNAPSHOT ON;

In Azure SQL Database is RCSI standaard ingeschakeld en is READ COMMITTED 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.

Naast verminderde blokkering wordt het vereiste vergrendelingsgeheugen verminderd. Dit komt doordat lezers geen vergrendelingen nemen en schrijvers slechts korte duurvergrendelingen nemen, in plaats van vergrendelingen die tot het einde van de transactie worden bewaard. Wanneer u strengere isolatieniveaus zoals REPEATABLE READ of SERIALIZABLEgebruikt, bevat de database-engine rij- en paginavergrendelingen tot het einde van de transactie, zelfs als geoptimaliseerde vergrendeling is ingeschakeld, voor zowel lezers als schrijvers, wat resulteert in een toegenomen blokkering en vergrendeling van het geheugengebruik.

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?

In Azure SQL Database, Azure SQL Managed Instance^AUTD en SQL Database in Microsoft Fabric Preview, ja. In SQL Server 2025 (17.x) Preview is geoptimaliseerde vergrendeling 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.

Verwante inhoud

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