Optimalizált zárolás

A következőkre vonatkozik: SQL Server 2025 (17.x) Azure SQL Database Azure SQL Managed Instance SQL Database a Microsoft Fabricben

Az optimalizált zárolás olyan továbbfejlesztett tranzakciózárolási mechanizmust kínál, amely csökkenti az egyidejű tranzakciók zárolásának blokkolását és a memóriafoglalást.

Mi az optimalizált zárolás?

Az optimalizált zárolás segít csökkenteni a zárolási memóriát, mivel nagyon kevés zárolást tartanak még nagy tranzakciók esetén is. Az optimalizált zárolás emellett elkerüli a zárolások eszkalációit, és elkerülheti a holtpontok bizonyos típusait. Ez több egyidejű hozzáférést tesz lehetővé a táblához.

Az optimalizált zárolás két elsődleges összetevőből áll: tranzakcióazonosító (TID) zárolás és zárolás minősítés után (LAQ).

A tranzakcióazonosító (TID) egy tranzakció egyedi azonosítója. Minden sor az azt módosító utolsó TID-vel van megjelölve. A kulcs- vagy sorazonosítók esetleges zárolása helyett a rendszer egyetlen zárolást használ a TID-n az összes módosított sor védelmére. További információért lásd: tranzakcióazonosító (TID) zárolása.
A minősítés utáni zárolás (LAQ) egy olyan optimalizálás, amely a sor legújabb véglegesített verziójával értékeli ki a lekérdezési predikátumokat zárolás beszerzése nélkül, ezáltal javítva az egyidejűséget. A LAQ olvasási véglegesített pillanatkép-elkülönítést (RCSI) igényel. További információ: Minősítés utáni zárolás (LAQ).

Például:

Optimalizált zárolás nélkül a tábla 1000 sorának frissítése 1000 kizárólagos (X) sorzárolást igényelhet a tranzakció végéig.
Az optimalizált zárolás esetén egy tábla 1000 sorának frissítése 1000 X sorzárolást igényelhet, de az egyes zárolások az egyes sorok frissítésekor azonnal felszabadulnak, és a tranzakció végéig csak egy X TID-zárolás van tárolva. Mivel a zárolások gyorsan szabadulnak fel, a zárolási memória kihasználtsága csökken, és zárolás eszkalálási sokkal kisebb valószínűséggel fordul elő, ami növeli a számítási feladatok egyidejűségét.

Note

Az optimalizált zárolás engedélyezése csökkenti vagy megszünteti az adatmódosítási nyelv (DML) utasításai által beszerzett sor- és oldalzárolásokat, például INSERT, UPDATE, DELETE, MERGE. Nincs hatással más típusú adatbázis- és objektumzárolásokra, például sémazárolásokra.

Availability

Az alábbi táblázat az SQL-platformokon végzett optimalizált zárolás rendelkezésre állását és engedélyezett állapotát foglalja össze.

Platform	Available	Alapértelmezés szerint engedélyezve
Azure SQL Database	Yes	Igen (mindig engedélyezve)
SQL-adatbázis a Microsoft Fabricben	Yes	Igen (mindig engedélyezve)
Azure SQL Kezelt Példány^AUTD	Yes	Igen (mindig engedélyezve)
Azure SQL Kezelt Példány²⁰²⁵	Yes	Igen (mindig engedélyezve)
Azure SQL Megfelügyelt Példány²⁰²²	No	N/A
SQL Server 2025 (17.x)	Yes	Nem (adatbázisonként engedélyezhető)
SQL Server 2022 (16.x) és régebbi verziók	No	N/A

Engedélyezés és letiltás

Az SQL Server-adatbázisok optimalizált zárolásának engedélyezéséhez vagy letiltásához használja a ALTER DATABASE ... SET OPTIMIZED_LOCKING = ON | OFF parancsot. További információ: ALTER DATABASE SET beállításai.

Az optimalizált zárolási rendszerek más adatbázis-funkciókra épülnek.

Az optimalizált zárolás engedélyezése előtt egy adatbázison engedélyeznie kell a gyorsított adatbázis-helyreállítást (ADR). Ezzel szemben az ADR letiltásához először le kell tiltania az optimalizált zárolást, ha engedélyezve van.
Az optimalizált zárolás legnagyobb előnye érdekében az olvasott véglegesített pillanatkép-elkülönítést (RCSI) engedélyezni kell az adatbázishoz. Az optimalizált zárolás LAQ összetevője csak akkor van érvényben, ha az RCSI engedélyezve van.

Az ADR mindig engedélyezve van az Azure SQL Database-ben, az Azure SQL Managed Instance-ben és a Microsoft Fabric SQL-adatbázisban. Az RCSI alapértelmezés szerint engedélyezve van az Azure SQL Database-ben és az SQL Database-ben a Microsoft Fabricben.

Ha ellenőrizni szeretné, hogy ezek a beállítások engedélyezve vannak-e az aktuális adatbázishoz, csatlakozzon az adatbázishoz, és futtassa a következő T-SQL-lekérdezést:

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

Engedélyezve van az optimalizált zárolás?

Az optimalizált zárolás adatbázisonként engedélyezve van. Csatlakozzon az adatbázishoz, majd az alábbi lekérdezés használatával ellenőrizze, hogy engedélyezve van-e az optimalizált zárolás:

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

Result	Description
`0`	Az optimalizált zárolás le van tiltva.
`1`	Az optimalizált zárolás engedélyezve van.
`NULL`	Az optimalizált zárolás nem érhető el.

A sys.databases katalógusnézetet is használhatja. Ha például azt szeretné, hogy az optimalizált zárolás engedélyezve legyen-e az összes adatbázishoz, hajtsa végre a következő lekérdezést:

SELECT database_id,
       name,
       is_optimized_locking_on
FROM sys.databases;

Zárolás áttekintése

Ez a viselkedés rövid összefoglalása, ha az optimalizált zárolás nincs engedélyezve. További információkért tekintse át a tranzakciózárolási és sorverziózás útmutatót.

Az adatbázismotorban a zárolás olyan mechanizmus, amely megakadályozza, hogy több tranzakció egyszerre frissítse ugyanazokat az adatokat annak érdekében, hogy garantálja a tranzakciók ACID tulajdonságait.

Amikor egy tranzakciónak módosítania kell az adatokat, zárolást kér az adatokon. A zárolás akkor adható meg, ha az adatokon nincs más ütköző zárolás, és a tranzakció folytathatja a módosítást. Ha az adatokon egy másik ütköző zárolás van tárolva, a tranzakciónak meg kell várnia a zárolás feloldását, mielőtt továbbléphet.

Ha több tranzakció egyszerre próbál hozzáférni ugyanahhoz az adathoz, az adatbázismotornak meg kell oldania az egyidejű olvasásokkal és írásokkal járó esetlegesen összetett ütközéseket. A zárolás az egyik olyan mechanizmus, amellyel az adatbázismotor biztosítani tudja az ANSI SQL-tranzakció szemantikáját az elkülönítési szinteknél . Bár az adatbázisok zárolása alapvető fontosságú, a csökkentett egyidejűség, a holtpontok, az összetettség és a zárolási többletterhelés hatással lehet a teljesítményre és a méretezhetőségre.

Tranzakcióazonosító (TID) zárolása

Ha sorverziós alapú elkülönítési szintek használatban vannak, vagy ha az ADR engedélyezve van, az adatbázis minden sora tartalmaz egy tranzakcióazonosítót (TID). A TID tárolódik a sorral. Minden sort módosító tranzakció a sor TID azonosítójával bélyegzi.

A TID zárolása esetén a sor kulcsának zárolása helyett a sor TID-jén történik a zárolás. A módosító tranzakció X zárolást tartalmaz a TID-n. Más tranzakciók S zárolást kapnak a TID-n, amíg az első tranzakció befejeződik. A TID zárolásával az oldal- és sorzárolások továbbra is módosításra kerülnek, de az egyes sorok módosítása után minden egyes oldal- és sorzárolás feloldva lesz. A tranzakció végéig az egyetlen fenntartott zárolás a TID-erőforrás egyetlen X zárolása, amely több oldal- és sorzár helyett van alkalmazva.

Tekintse meg az alábbi példát, amely az aktuális munkamenet zárolásait mutatja be, miközben egy írási tranzakció aktív:

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

Ha az optimalizált zárolás engedélyezve van, a kérelem csak egyetlen X zárolást tárol a XACT (tranzakciós) erőforráson.

Ha az optimalizált zárolás nincs engedélyezve, ugyanaz a kérés négy zárolást tartalmaz: egy IX (kizárólagos szándék) zárolást a sorokat tartalmazó oldalon, és három X kulcszárolást minden sorban:

A sys.dm_tran_locks dinamikus felügyeleti nézet (DMV) hasznos a zárolási problémák vizsgálatához vagy hibaelhárításához. Itt az optimalizált zárolás működés közbeni megfigyelésére szolgál.

Minősítés utáni zárolás (LAQ)

A TID-infrastruktúrára építve az optimalizált zárolás LAQ-összetevője módosítja a DML-utasítások, például INSERT, UPDATE, és DELETE, a zárolás megszerzésének módját.

Optimalizált zárolás nélkül a lekérdezési predikátumok sorról sorra vannak bejelölve a vizsgálat során, és először egy frissítési (U) sorzárolást végeznek. Ha a predikátum teljesül, a sor frissítése előtt egy kizárólagos (X) sorzárolás történik, amely a tranzakció végéig tart.

Az optimalizált zárolással és a READ COMMITTED pillanatkép-elkülönítési szint (RCSI) engedélyezése esetén a predikátumok optimista módon ellenőrizhetők a sor legújabb véglegesített verzióján zárolás nélkül. Ha a predikátum nem felel meg az elvárásoknak, a lekérdezés az átolvasás következő sorára lép. Ha a predikátum megfelel, a sor frissítéséhez X sorzárolás történik.

Más szóval a zárolás a sor minősítése után történik meg módosítás céljából. A X sorzár a sorfrissítés befejeződése után, a tranzakció vége előtt szabadul fel.

Mivel a predikátum kiértékelése zárolások beszerzése nélkül történik, a különböző sorokat módosító egyidejű lekérdezések nem blokkolják egymást.

Például:

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

1. munkamenet	2. munkamenet
`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;`

Optimalizált zárolás nélkül a 2. munkamenet le van blokkolva, mert az 1. munkamenet U zárolással tartja a sort, amelyre a 2. munkamenetnek szüksége van a frissítéshez. Optimalizált zárolás esetén azonban a 2. munkamenet nem lesz letiltva, mert U zárolások nincsenek meg, és mivel az 1. sor legújabb véglegesített verziójában a a oszlop értéke 1, ami nem felel meg a 2. munkamenet predikátumának.

Az LAQ optimista módon történik azon feltételezés alapján, hogy a sor nem módosul a predikátum ellenőrzése után. Ha a predikátum feltétele teljesül, és a predikátum ellenőrzése után a sor nem módosult, akkor az aktuális tranzakció módosítja a sort.

Mivel a U zárolások nincsenek megadva, egy párhuzamos tranzakció módosíthatja a sort a predikátum kiértékelése után. Ha egy aktív tranzakció TID-zárolást X tartalmaz a sorban, az adatbázismotor megvárja, amíg befejeződik. Ha a sor a predikátum korábbi kiértékelése után módosult, az adatbázismotor a sor módosítása előtt újraértékeli (újra minősíti) a predikátumot. Ha a predikátum továbbra is teljesül, a sor módosul.

A predikátum-újraminősítést a lekérdezési motor operátorainak egy részhalmaza támogatja. Ha predikátum-újraértékelésre van szükség, de a lekérdezési terv olyan operátort használ, amely nem támogatja a predikátumok újraminősítését, az adatbázismotor belsőleg megszakítja az utasítások feldolgozását, és laq nélkül újraindítja azt. Ilyen megszakítás esetén a lock_after_qual_stmt_abort kiterjesztett esemény aktiválódik.

Egyes utasítások, például UPDATE a változó hozzárendeléssel rendelkező utasítások és az OUTPUT záradékkal rendelkező utasítások nem szakíthatók meg és nem indíthatók újra a szemantikák módosítása nélkül. Ilyen nyilatkozatok esetén a LAQ nem használatos.

A következő példában a predikátum újra lesz értékelve, mert egy másik tranzakció módosította a sort:

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

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

1. munkamenet	2. munkamenet
`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;`

Indexzárak kihagyása (SIL)

A TID zárolásával a sorok módosításához rövid időtartamú kizárólagos (X) sorzárolások és szándék-kizárólagos (IX) oldalzárolások használhatók. RCSI és LAQ használata esetén ezek a zárolások csak akkor szükségesek, ha más lekérdezések is hozzáférnek a sorhoz, és azt várják, hogy stabil legyen. Ilyen lekérdezések például azok, amelyek az REPEATABLE READ vagy SERIALIZABLE elkülönítési szintek alatt futnak, vagy a megfelelő zárolási tippeket használják. Az ilyen lekérdezéseket sorzárolási lekérdezésnek (RLQ) nevezzük.

Ha nem férnek hozzá RLQ-lekérdezések egy sorhoz, az adatbázismotor kihagyhatja a sor- és oldalzárolásokat a sor módosításakor, és csak kizárólagos oldalzárolást használhat. Ez az optimalizálás csökkenti a zárolási többletterhelést, miközben megőrzi az ACID-tranzakciók szemantikáját. A sor- és oldalzárolások kihagyása különösen előnyös a sok sort módosító tranzakcióknak.

Jelenleg a SIL optimalizálás csak a következő esetekben használt:

INSERT a halomra vonatkozó utasítások.
- IX a rendszer kihagyja a lapzárolásokat.
UPDATE fürtözött indexekre, nem fürtözött indexekre és halmokra vonatkozó utasítások.
- IX A rendszer kihagyja az oldalzárakat és X a sorzárakat.

A SIL optimalizálást jelenleg nem használják a következő esetekben:

DELETE Nyilatkozatok.
UPDATE utasítások a halmokkal kapcsolatban, ha a sor meglévő továbbítási mutatókat tartalmaz, vagy ha a frissítés új továbbítási mutatókat ad hozzá.
Ha a módosított sor olyan oszlopokkal rendelkezik, amelyek a LOB adattípusokat használják, például varchar(max): , nvarchar(max)varbinary(max)és json.
Az ugyanazon tranzakcióban felosztott lapok sorai esetében.

LAQ heurisztika

A Minősítés utáni zárolás (LAQ) című cikkben leírtak szerint a LAQ használata esetén a predikátum-újraminősítést nem támogató lekérdezési operátorokat használó utasítások belsőleg újraindulhatnak és feldolgozhatók LAQ nélkül. Ha ez gyakran történik, az újrafeldolgozás többletterhelése jelentős lehet. A többletterhelés minimalizálása érdekében az optimalizált zárolás heurisztikus alapú visszajelzési mechanizmust használ, amely letiltja a LAQ-t, ha a többletterhelés meghaladja a küszöbértékeket.

A visszajelzési mechanizmus alkalmazásában az utasítás által végzett munkát a logikai olvasások számában mérik. Ha az adatbázismotor módosít egy sort, amelyet egy másik tranzakció módosított az utasítás feldolgozása után, akkor az utasítás által végzett munka valószínűleg elvesztek, mert előfordulhat, hogy az utasítást újra fel kell dolgozni.

Az utasítások végrehajtása során az adatbázismotor a laQ-visszajelzési adatokat kezeli, amelyek nyomon követik a potenciálisan elpazarolt munkát, az utasítás-újrafeldolgozás előfordulását és az újra feldolgozható utasítások által végzett teljes munkát.

A LAQ le van tiltva, ha a potenciálisan elpazarolt munka és a teljes munka aránya, vagy az újrafeldolgozott utasítások számának és az utasítások teljes számának aránya meghaladja a vonatkozó küszöbértékeket. Ha mindkét arány a küszöbértékek alá esik, a LAQ újra engedélyezve van.

A LAQ visszajelzési adatainak nyomon követése két szinten történik:

Lekérdezéstervhez.
- Az adatbázismotor megkezdi az LAQ-visszajelzések nyomon követését egy tervre vonatkozóan az utasítás újrafeldolgozásának első előfordulásától kezdve.
- Ha egy lekérdezést a Lekérdezéstárban rögzít, a LAQ-visszajelzések a Lekérdezéstárban is rögzítve lesznek. Az adatbázismotor ezt a visszajelzést felhasználva engedélyezi vagy letiltja a LAQ funkciót a tervben, amikor az adatbázis újraindul.
- A rögzített LAQ-visszajelzéssel rendelkező lekérdezési terveknek van egy egyező plan_id értékkel rendelkező sora a sys.query_store_plan_feedback katalógusnézetben. feature_id és feature_desc oszlopokat 4-re és LAQ Feedback-re állítjuk be.
Egy adatbázishoz.
- A rendszer összesíti a visszajelzést az összes olyan utasításhoz, amely nem rendelkezik lekérdezéstervszintű visszajelzéssel, például ha a lekérdezést nem rögzítik a Lekérdezéstárban.
- A visszajelzések az adatbázis indítása óta nyomon követhetők, és az egyes indítások után újra létre lesznek hozva.

Amikor eldönti, hogy a LAQ-t használja-e egy utasításhoz, a rendszer a lekérdezésterv visszajelzését használja, ha van ilyen. Ellenkező esetben az adatbázisszintű visszajelzést használja. Ez azt jelenti, hogy egyes utasítások a LAQ-val, mások pedig a LAQ nélkül is végrehajthatók. Előfordulhat például, hogy a LAQ le van tiltva egy lekérdezési terv esetében, de engedélyezve van az adatbázisban, és fordítva.

LAQ-korlátozások

A minősítés utáni zárolás nem használható a következő esetekben:

Amikor a LAQ heurisztikát letiltják.
Ütköző zárolási tippek, például UPDLOCK, READCOMMITTEDLOCK, XLOCKvagy HOLDLOCK használatban vannak.
Ha a tranzakcióelkülönítési szint nem az READ COMMITTED, vagy ha az READ_COMMITTED_SNAPSHOT adatbázis-beállítás le van tiltva.
Amikor a módosítandó tábla oszlopalapú indexet tartalmaz.
Ha a DML-utasítás változó-hozzárendelést tartalmaz.
Ha a DML-utasítás rendelkezik záradékkal OUTPUT .
Ha a DML-utasítás egynél több indexkeresési vagy vizsgálati operátort használ a módosítandó sorok beolvasásához.
A MERGE utasításokban.

A lekérdezés viselkedésének változásai optimalizált zárolással és RCSI-vel

Az olvasható véglegesített pillanatkép-izoláció (RCSI) alatt futó, a tranzakciók szigorú végrehajtási sorrendjére támaszkodó egyidejű munkafolyamatok eltérő lekérdezési viselkedést tapasztalhatnak, ha engedélyezve van az optimalizált zárolás.

Tekintse meg az alábbi példát, amelyben a T2 tranzakció a T1 tranzakció során frissített t4 oszlop alapján frissíti a táblát b.

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

INSERT INTO t4
VALUES (1,1);
GO

1. munkamenet	2. munkamenet
`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;`

Értékeljük ki az előző forgatókönyv eredményét a minősítés után zárolással és zárolás nélkül (LAQ).

LAQ nélkül

LAQ nélkül a T2 tranzakció UPDATE utasítása blokkolva van, és a T1 tranzakció befejezésére vár. A T1 befejezése után a T2 frissíti a sor beállítási oszlopát b-ról 3-re, mert a predikátuma teljesül.

Mindkét tranzakció véglegesítése után a t4 tábla a következő sorokat tartalmazza:

 a | b
 1 | 3

LAQ-val

A LAQ esetén a T2 tranzakció azt a sor legfrissebb véglegesített verzióját használja, ahol az b oszlop egyenlő 1 értékkel a predikátum kiértékeléséhez (b = 2). A sor nem megfelelő; így kihagyásra kerül, és a művelet befejeződik anélkül, hogy a T1 tranzakció blokkolta volna. Ebben a példában a LAQ eltávolítja a blokkolást, de eltérő eredményekhez vezet.

Mindkét tranzakció véglegesítése után a t4 tábla a következő sorokat tartalmazza:

 a | b
 1 | 2

Important

A LAQ nélkül sem szabad feltételezni, hogy az adatbázismotor szigorú rendezést garantál zárolási tippek használata nélkül, amikor sorverzió-alapú elkülönítési szinteket használ. Általános javaslatunk az RCSI-ben egyidejű számítási feladatokat futtató ügyfelek számára, amelyek a tranzakciók szigorú végrehajtási sorrendjére támaszkodnak (ahogyan az előző példában is látható), szigorúbb elkülönítési szinteket, például REPEATABLE READ és SERIALIZABLE.

Diagnosztikai kiegészítések optimalizált zároláshoz

Az alábbi fejlesztések segítségével figyelheti és elháríthatja a blokkolást és a holtpontokat, ha engedélyezve van az optimalizált zárolás:

Várakozástípusok az optimalizált zároláshoz
- XACT várakozási típusok a S TID zárolásához, valamint az erőforrás-leírások a sys.dm_os_wait_stats rendszerben:
  - LCK_M_S_XACT_READ – Akkor fordul elő, ha egy tevékenység megosztott zárra vár egy XACTwait_resource típus esetén, olvasási céllal.
  - LCK_M_S_XACT_MODIFY – Akkor fordul elő, ha egy tevékenység egy XACTwait_resource típus megosztott zárolására vár módosítási szándékkal.
  - LCK_M_S_XACT – Akkor fordul elő, ha egy feladat megosztott zárolásra vár egy XACTwait_resource típuson, ahol a szándék nem értelmezhető. Ez a forgatókönyv nem gyakori.
Erőforrások láthatóságának zárolása
- XACT erőforrások zárolása. További információért lásd resource_description a sys.dm_tran_locks alatt.
Várakozási erőforrás láthatósága
- XACT várakozó erőforrások. További információért lásd wait_resource a sys.dm_exec_requests részben.
Holtpont gráf
- A holtpont jelentés <resource-list>minden egyes erőforrásánál minden <xactlock> elem jelentést ad az adott erőforrásokról és a holtpont egyes tagjainak zárolására vonatkozó specifikus információkat. További információ és példa: Optimalizált zárolás és holtpontok.
Bővített események
- Az lock_after_qual_stmt_abort esemény akkor aktiválódik, ha egy utasítás belső feldolgozása egy másik tranzakcióval való ütközés miatt történik. További információ: Minősítés utáni zárolás (LAQ).
- Az locking_stats esemény néhány percenként aktiválódik minden adatbázis esetében, és összesített zárolási statisztikákat biztosít az időintervallumra vonatkozóan, például a zárolás eszkalációinak számát, azt, hogy engedélyezve van-e a TID-zárolás és az optimalizált zárolás LAQ-összetevői, valamint azoknak a lekérdezéseknek a száma, amelyeknél a LAQ-t nem használták különböző okokból. Ez az esemény akkor is aktiválódik, ha az optimalizált zárolás le van tiltva.
- Az SQL Serverben és a felügyelt Azure SQL-példányban az locking_stats2 esemény néhány percenként aktiválódik minden adatbázis esetében, és megadja az időintervallum kihagyott indexzárait és LAQ heurisztikai statisztikáit.

Ajánlott eljárások optimalizált zárolással

Olvasható elkötelezett pillanatkép-elkülönítés engedélyezése (RCSI)

Az optimalizált zárolás előnyeinek maximalizálása érdekében ajánlott engedélyezni az olvasási véglegesített pillanatkép-elkülönítést (RCSI) az adatbázisban, és az elkülönítést használni READ COMMITTED alapértelmezett elkülönítési szintként.

A Microsoft Fabricben az Azure SQL Database és az SQL Database alapértelmezés szerint az RCSI engedélyezve van, és READ COMMITTED az alapértelmezett elkülönítési szint. Ha az RCSI engedélyezve van, és READ COMMITTED elkülönítési szintet használ, az olvasók az utasítás elején készített pillanatképből olvassák be a sor egy verzióját. A LAQ használatával a szerzők a predikátum alapján minősítik a sorokat, figyelembe véve a legfrissebb véglegesített verziót, és mindezt anélkül, hogy U zárolásokat szereznének be. LAQ esetén a lekérdezés csak akkor várakozik, ha a sor megfelel a feltételeknek, és aktív írási tranzakció van a soron. A legújabb véglegesített verzió alapján történő minősítés és a csak a minősített sorok zárolása csökkenti a blokkolást és növeli az egyidejűséget.

Kerüld a zárolási tippeket

Bár tábla- és lekérdezési tippek, például UPDLOCK, READCOMMITTEDLOCK, XLOCK, HOLDLOCKstb. teljesülnek az optimalizált zárolás engedélyezésekor, csökkentik az optimalizált zárolás előnyeit. A zárolási tippek arra kényszerítik az adatbázismotort, hogy sor- vagy oldalzárolást hajtson ki, és tartsa őket a tranzakció végéig, hogy betartsa a zárolási tippek szándékát. Egyes alkalmazások olyan logikával rendelkeznek, ahol zárolási megjegyzésekre van szükség, például amikor egy sor UPDLOCK megjegyzéssel történő olvasása után azt később frissítik. Azt javasoljuk, hogy csak akkor használjunk zárolási tippeket, ha szükséges.

Az optimalizált zárolás esetén nincs korlátozás a meglévő lekérdezésekre, és a lekérdezéseket nem kell újraírni. A nem tippeket használó lekérdezések leginkább az optimalizált zárolást használják.

A lekérdezések egyik táblájára vonatkozó táblázatos tipp nem tiltja le az optimalizált zárolást az ugyanazon lekérdezésben lévő többi táblához. Az optimalizált zárolás emellett csak a DML-utasítással frissített táblák zárolási viselkedését befolyásolja, például INSERT, UPDATE, DELETEvagy MERGE. Például:

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;

Az előző lekérdezési példában csak a t6 táblázatot érinti a zárolási tipp, míg t5 továbbra is kihasználhatja az optimalizált zárolás előnyeit.

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

Az előző lekérdezési példában csak a t5 tábla használja a REPEATABLE READ elkülönítési szintet, és a tranzakció végéig tartja a zárolásokat. A t5 egyéb frissítései továbbra is kihasználhatják az optimalizált zárolás előnyeit. Ugyanez vonatkozik a HOLDLOCK tippre is.

Gyakori kérdések (GYIK)

Az optimalizált zárolás alapértelmezés szerint be van kapcsolva az új és a meglévő adatbázisokban is?

Az Azure SQL Database-ben, az Azure SQL Managed Instance^AUTD-ben és az SQL Database-ben a Microsoft Fabricben igen. Az SQL Server 2025 -ben (17.x) az optimalizált zárolás alapértelmezés szerint le van tiltva, de bármely olyan felhasználói adatbázisban engedélyezhető, amely engedélyezte az adatbázis gyorsított helyreállítását.

Hogyan észlelhetem, hogy engedélyezve van-e az optimalizált zárolás?

Lásd : Engedélyezve van az optimalizált zárolás?

Mi a teendő, ha az optimalizált zárolás ellenére blokkolni szeretném a lekérdezéseket?

Ha az RCSI engedélyezve van, a READCOMMITTEDLOCK táblamutatóval kényszerítse a két lekérdezés közötti blokkolást, ha engedélyezve van az optimalizált zárolás.

Az optimalizált zárolás írásvédett másodlagos replikákon használatos?

Nem, mert a DML-utasítások nem futtathatók írásvédett replikákon, és a megfelelő sor- és oldalzárolások nincsenek érvényben.