Tranzakciók memóriaoptimalizált táblákkal

A következőkre vonatkozik:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Ez a cikk a memóriaoptimalizált táblákra és natívan lefordított tárolt eljárásokra jellemző tranzakciók összes aspektusát ismerteti.

Az SQL Server tranzakcióelkülönítési szintjei eltérően vonatkoznak a memóriaoptimalizált táblákra és a lemezalapú táblákra, és az alapul szolgáló mechanizmusok eltérőek. A különbségek megértése segít a programozónak egy magas átviteli sebességű rendszer kialakításában. A tranzakciós integritás célja minden esetben meg van osztva.

A memóriaoptimalizált táblák tranzakcióira vonatkozó hibafeltételekért tekintse meg az Ütközésészlelés és újrapróbálkozási logika szakaszt .

Általános információkért lásd: SET TRANSACTION ISOLATION LEVEL.

Pesszimista és optimista

A memóriaoptimalizált táblák és a lemezalapú táblák közötti funkcionális különbségek a tranzakciós integritás pesszimista és optimista megközelítéséből erednek. A memóriaoptimalizált táblák az optimista megközelítést használják:

• A pesszimista megközelítés zárolásokkal blokkolja a lehetséges ütközéseket, mielőtt bekövetkeznének. A zárolások az utasítás végrehajtásakor történnek, és a tranzakció véglegesítésekor szabadulnak fel.

• Az optimista megközelítés észleli az ütközéseket, és érvényesítési ellenőrzéseket végez a véglegesítéskor.

  • Az 1205-ös hiba, amely holtpont, nem fordulhat elő memóriaoptimalizált táblák esetében.

Az optimista megközelítés kevesebb többletterheléssel jár, és általában hatékonyabb, részben azért, mert a tranzakciós ütközések a legtöbb alkalmazásban nem gyakoriak. A pesszimista és optimista megközelítések közötti fő funkcionális különbség az, hogy ütközés esetén a pesszimista megközelítésben várni kell, míg az optimista megközelítésben az egyik tranzakció meghiúsul, és az ügyfélnek újra kell próbálkoznia. A funkcionális különbségek nagyobbak, amikor az REPEATABLE READ elkülönítési szint érvényben van, és a legnagyobbak a SERIALIZABLE szintnél.

Tranzakcióindítási módok

Az SQL Server a következő módokon kezdeményezi a tranzakciókat:

• Autocommit. Egy egyszerű lekérdezés vagy DML-utasítás implicit módon megnyitja a tranzakciót az elején, és az utasítás vége implicit módon véglegesíti a tranzakciót. Automatikus mentés az alapértelmezett.

  Automatikus feladatátvételi módban általában nem kell táblázatos tippet kódolnia a záradék memóriaoptimalizált táblájának FROM tranzakcióelkülönítési szintjéről.

• Explicit. A Transact-SQL tartalmazza a BEGIN TRANSACTION kódot, valamint egy esetleges COMMIT TRANSACTION. Két vagy több utasítást is összevonhat ugyanabba a tranzakcióba.

  Explicit módban vagy az adatbázis-beállítást MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT kell használnia, vagy a memóriaoptimalizált táblára vonatkozó jelzőt a tranzakcióelkülönítési szintről a FROM záradékban kell használja.

• Implicit. Amikor SET IMPLICIT_TRANSACTION ON érvényben van, beindul a folyamat. Ez a beállítás implicit módon végrehajtja az explicit BEGIN TRANSACTION megfelelőjét az egyes UPDATE utasítások előtt, ha @@TRANCOUNT0 van. Ezért a T-SQL-kódon múlik, hogy végül kibocsátson egy explicit COMMIT TRANSACTION.

• ATOMIC-blokk. A blokkokban lévő ATOMIC összes utasítás mindig egyetlen tranzakció részeként fut. Vagy az atomblokk egészének műveletei sikeresek, vagy az összes művelet vissza lesz állítva meghibásodás esetén. Minden natívan lefordított tárolt eljáráshoz szükséges egy ATOMIC blokk.

Példa az explicit módú kódra

A következő Transact-SQL szkriptet értelmezi és használja:

• Kifejezett tranzakció.
• Egy memóriaoptimalizált tábla, neve dbo.Order_mo.
• A READ COMMITTED tranzakcióelkülönítési szint környezete.

Ezért a memóriaoptimalizált táblához táblázatos tippet kell hozzáadnia. A tippnek a SNAPSHOT szintre vagy egy még inkább elválasztó szintre kell vonatkoznia. A példakód esetében a tipp a következő WITH (SNAPSHOT): . Ha eltávolítja ezt a tippet, a szkript 41368-os hibát tapasztal, amelyhez nem megfelelő az automatikus újrapróbálkozás:

41368-os hiba

A memóriaoptimalizált táblák elkülönítési READ COMMITTED szinttel való elérése csak az automatikus feladatátvételi tranzakciók esetében támogatott. Explicit vagy implicit tranzakciók esetén nem támogatott. Adjon meg egy támogatott elkülönítési szintet a memóriaoptimalizált táblához egy táblázatos tipp használatával, például WITH (SNAPSHOT).

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

BEGIN TRANSACTION; -- Explicit transaction.

-- Order_mo is a memory-optimized table.
SELECT *
FROM dbo.Order_mo AS o WITH (SNAPSHOT) -- Table hint.
     INNER JOIN dbo.Customer AS c
         ON c.CustomerId = o.CustomerId;

COMMIT TRANSACTION;

Az WITH (SNAPSHOT) útmutatás szükségességét elkerülheti az MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT adatbázis opció használatával. Ha ezt a beállítást ON állítja be, a memóriaoptimalizált táblázathoz való hozzáférés egy alacsonyabb elkülönítési szintről automatikusan SNAPSHOT elkülönítési szintre emelkedik.

ALTER DATABASE CURRENT
    SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;

Sor verziószámozása

A memóriaoptimalizált táblák rendkívül kifinomult sorverziós rendszert használnak, amely még a legszigorúbb elkülönítési SERIALIZABLEszinten is hatékonyan teszi hatékonyabbá az optimista megközelítést. További információkért lásd: Bevezetés a memóriaoptimalizált táblák használatába.

A lemezalapú táblák közvetetten sorverziós rendszerrel rendelkeznek, amikor READ_COMMITTED_SNAPSHOT vagy az elkülönítési SNAPSHOT szint érvényben van. Ez a rendszer tempdb alapú, miközben a memóriaoptimalizált adatstruktúrákba beépített a sorverziózás a maximális hatékonyság érdekében.

Elkülönítési szintek

Az alábbi táblázat felsorolja a tranzakcióelkülönítés lehetséges szintjeinek sorrendjét a legkisebb elkülönítéstől a legtöbbig. Az esetleges ütközésekről és az ütközések kezeléséhez újrapróbálkozási logikáról további információt az Ütközésészlelés és újrapróbálkozási logika című témakörben talál.

Elkülönítési szint	Description
READ UNCOMMITTED	Nem érhető el: nem férhet hozzá a memóriaoptimalizált táblákhoz az El nem kötelezett olvasási szigeteltségi szint mellett. A memóriaoptimalizált táblákat továbbra is elérheti SNAPSHOT izoláció alatt, ha a munkamenet szintű beállítást TRANSACTION ISOLATION LEVEL-ról READ UNCOMMITTED-re állítja, a WITH (SNAPSHOT) táblamutató használatával vagy az adatbázis beállítását MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT-ről ON-re állítva.
READ COMMITTED	A memóriaoptimalizált táblák csak akkor támogatottak, ha az automatikus kiírási mód érvényben van. A memóriaoptimalizált táblákat továbbra is elérheti SNAPSHOT izoláció alatt, ha a munkamenet szintű beállítást TRANSACTION ISOLATION LEVEL-ról READ COMMITTED-re állítja, a WITH (SNAPSHOT) táblamutató használatával vagy az adatbázis beállítását MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT-ről ON-re állítva. Ha az adatbázis-beállítást READ_COMMITTED_SNAPSHOT úgy állítja be, hogy ON, akkor nem férhet hozzá a memóriaoptimalizált és a lemezalapú táblákhoz egyaránt READ COMMITTED elkülönítés alatt ugyanabban az utasításban.
SNAPSHOT	Memóriaoptimalizált táblák esetén támogatott. Belsőleg SNAPSHOT a legkevésbé igényes tranzakcióelkülönítési szint a memóriaoptimalizált táblák esetében. SNAPSHOTkevesebb rendszererőforrást használ, mint a .REPEATABLE READSERIALIZABLE
REPEATABLE READ	Memóriaoptimalizált táblák esetén támogatott. Az elkülönítés által REPEATABLE READ biztosított garancia az, hogy véglegesítéskor egyetlen egyidejű tranzakció sem frissítette a tranzakció által beolvasott sorokat. Az optimista modell miatt az egyidejű tranzakciók nem akadályozják meg a tranzakció által beolvasott sorok frissítését. Ehelyett a véglegesítéskor ez a tranzakció igazolta, hogy REPEATABLE READ az elkülönítés nem sérült. Ha igen, a tranzakció vissza lesz állítva, és újra kell próbálkozni.
SERIALIZABLE	Memóriaoptimalizált táblák esetén támogatott. Neve szerializálható, mert az elkülönítés annyira szigorú, hogy szinte olyan, mintha a tranzakciók sorosan futnának, nem egyidejűleg.

Tranzakciós fázisok és élettartam

Memóriaoptimalizált tábla esetén a tranzakció élettartama az alábbi képen látható fázisokon megy keresztül:

A fázisok leírásai a következők.

3. fázis: Rendszeres feldolgozás

• Ez a fázis végrehajtja a lekérdezés összes lekérdezését és DML-utasítását.

• Ebben a fázisban az utasítások a memóriaoptimalizált táblák verzióját látják a tranzakció logikai kezdő időpontjától kezdve.

3. fázis: Ellenőrzés

• Az érvényesítési fázis a befejezési idő hozzárendelésével kezdődik, amely logikailag befejezettként jelöli meg a tranzakciót. Ez a befejezés láthatóvá teszi a tranzakció minden módosítását más tranzakciók számára, amelyek függnek ettől a tranzakciótól. A függő tranzakciók nem fejeződhetnek be, amíg ez a tranzakció sikeresen le nem zárul. Emellett az ilyen függőségeket tartalmazó tranzakciók nem tudnak eredményhalmazokat visszaadni az ügyfélnek, hogy az ügyfél csak az adatbázishoz sikeresen lekötött adatokat láthassa.

• Ez a fázis az ismételhető olvasható és szerializálható ellenőrzésből áll. Ismétlődő olvasási ellenőrzés esetén ellenőrzi, hogy a tranzakció frissítette-e az általa beolvasott sorokat. Szerializálható érvényesítés esetén ellenőrzi, hogy a tranzakció beszúrt-e egy sort a beolvasott adattartományba. Az elkülönítési szintek és ütközések táblája szerint az ismétlődő olvasás és a szerializálható ellenőrzés a pillanatkép-elkülönítés használatakor is előfordulhat az egyedi és idegen kulcsok konzisztenciájának ellenőrzése érdekében.

3. fázis a 3-ból: Feldolgozás véglegesítése

• A véglegesítési fázisban a folyamat a tartós táblák módosításait a naplóba írja, a folyamat pedig lemezre írja a naplót. Ezután a folyamat visszaadja az irányítást az ügyfélnek.

• A véglegesítési feldolgozás befejezése után a folyamat értesíti az összes függő tranzakciót, amelyet véglegesíteni tud.

Mindig tartsa a tranzakciós egységeket olyan minimálisnak és rövidnek, amennyire az az adatigényeihez érvényes.

Ütközésészlelés és újrapróbálkozási logika

A tranzakcióval kapcsolatos hibafeltételek két típusa okozhatja a tranzakció meghiúsulását és visszaállítását. A legtöbb esetben újra meg kell próbálkoznia a tranzakcióval egy ilyen hiba után, hasonlóan a holtponthoz.

• Ütközések az egyidejű tranzakciók között. Ezek az ütközések, beleértve a frissítési ütközéseket és az érvényesítési hibákat, tranzakcióelkülönítési szint megsértése vagy kényszer megsértése miatt fordulhatnak elő.

• Függőségi hibák. Ezek a hibák abból adódnak, hogy a tranzakciók nem zárulnak sikeresen, vagy mert a függőségek száma túl nagyra nőtt.

Az alábbi hibafeltételek a memóriaoptimalizált táblák elérésekor a tranzakciók meghiúsulását okozhatják.

Hibakód	Description	Oka
41302	Megpróbált frissíteni egy sort, amelyet egy másik tranzakció frissített a jelen tranzakció kezdetétől számítva.	Ez a hibafeltétel akkor fordul elő, ha két egyidejű tranzakció egyszerre próbálja frissíteni vagy törölni ugyanazt a sort. A két tranzakció egyike megkapja ezt a hibaüzenetet, és újra kell próbálkoznia.
41305	Ismételhető olvasási érvényesítési hiba. Egy memóriaoptimalizált táblából olvasott sora ennek a tranzakciónak már frissítve lett egy másik tranzakció által, amely a jelenlegi tranzakció véglegesítése előtt zárult le.	Ez a hiba akkor fordulhat elő, ha REPEATABLE READ vagy SERIALIZABLE elkülönítést használunk, és akkor is, ha egy egyidejű tranzakció műveletei megsértik a FOREIGN KEY megszorítást. Az idegenkulcs-korlátozások ilyen egyidejű megsértése ritkán fordul elő, és általában az alkalmazáslogikával vagy az adatbevitellel kapcsolatos problémát jelez. A hiba azonban akkor is előfordulhat, ha nincs index a korlátozással FOREIGN KEY érintett oszlopokon. Ezért mindig hozzon létre egy indexet egy memóriaoptimalizált tábla idegen kulcsoszlopaihoz. Az idegen kulcs megsértése által okozott érvényesítési hibák megfontolásaiért tekintse meg az SQL Server ügyféltanácsadó csapatának 41305-ös és 41325-ös, memóriaoptimalizált táblák idegen kulcsos érvényesítési hibáiról szóló szempontjait.
41325	Szerializálható érvényesítési hiba. A rendszer egy új sort szúrt be egy olyan tartományba, amelyet a jelenlegi tranzakció korábban vizsgált. Ezt fantomsornak hívjuk.	Ez a hiba akkor fordulhat elő, amikor SERIALIZABLE elkülönítést használnak, és akkor is, ha egy egyidejű tranzakció egy PRIMARY KEY, UNIQUE vagy FOREIGN KEY kényszert sért. Az ilyen egyidejű korlátozásmegsértés ritkán fordul elő, és általában az alkalmazáslogikával vagy adatbevitellel kapcsolatos problémát jelez. Az ismételhető olvasási érvényesítési hibákhoz hasonlóan ez a hiba akkor is előfordulhat, ha index nélküli korlátozás van FOREIGN KEY az érintett oszlopokon.
41301	Függőségi hiba: egy tranzakció függőséget vett fel egy másik tranzakcióra, amelyet később nem sikerült véglegesíteni.	Ez a tranzakció (Tx1) függőséget vett fel egy másik tranzakciótól (Tx2), amíg a tranzakció (Tx2) az érvényesítési vagy véglegesítési feldolgozási fázisban volt, az általa írt Tx2adatok beolvasásával. Tx2 ezután nem sikerült véglegesíteni. A Tx2 véglegesítésének sikertelenségének leggyakoribb okai az ismételhető olvasás (41305) és a szerializálható olvasás (41325) érvényesítési hibái. Ritkább ok a napló I/O meghibásodása.
41823 és 41840	Elérte a memóriaoptimalizált táblákban és táblaváltozókban lévő felhasználói adatokra vonatkozó kvótát.	A 41823-ás hiba az SQL Server Express, Web és Standard kiadásokra, valamint az Azure SQL Database-ben található önálló adatbázisokra vonatkozik. A 41840-s hiba az Azure SQL Database rugalmas készleteiben érvényes. A legtöbb esetben ezek a hibák azt jelzik, hogy elérte a felhasználói adatok maximális méretét. A hiba megoldásához törölje az adatokat a memóriaoptimalizált táblákból. Ritkán azonban előfordulnak olyan esetek, amikor ez a hiba átmeneti. Próbálkozzon újra, amikor először tapasztalja ezeket a hibákat. A listában szereplő többi hibához hasonlóan a 41823- és a 41840-s hibák is megszakítják az aktív tranzakciót.
41839	A tranzakció túllépte a véglegesítési függőségek maximális számát.	Azon tranzakciók számát, melyeken egy adott tranzakció (Tx1) alapulhat, bármi is korlátozhatja. Ezek a tranzakciók a kimenő függőségek. Emellett az adott tranzakciótól (Tx1) függő tranzakciók száma is korlátozott. Ezek a tranzakciók a bejövő függőségek. A korlát mindkettőre 8. A hiba leggyakoribb esete, hogy nagy számú olvasási tranzakció fér hozzá egyetlen írási tranzakció által írt adatokhoz. A feltétel elérésének valószínűsége nő, ha az olvasási tranzakciók mindegyike nagy mennyiségű vizsgálatot végez ugyanazon adatokon, és ha az írási tranzakció érvényesítése vagy véglegesítése hosszú ideig tart. Például az írási tranzakciók szerializálható izoláció alatt hajtanak végre nagy vizsgálatokat (ami növeli az érvényesítési fázis hosszát), vagy a tranzakciónaplót egy lassú napló IO-eszközre helyezik (ami növeli az eljárás feldolgozásának hosszát). Ha az olvasási tranzakciók nagy vizsgálatokat végeznek, és várhatóan csak néhány sorhoz férnek hozzá, előfordulhat, hogy hiányzik egy index. Hasonlóképpen, ha az írási tranzakció szerializálható elkülönítést használ, és nagy vizsgálatokat végez, de várhatóan csak néhány sort fog elérni, ez a feltétel egy hiányzó indexet is jelez. A véglegesítési függőségek számának korlátozását a nyomkövetési jelző 9926használatával oldhatja fel. Ezt a nyomkövetési jelzőt csak akkor használja, ha a hibaállapot akkor is fennáll, ha meggyőződik arról, hogy nincsenek hiányzó indexek, mivel elfedheti ezeket a problémákat a fent említett esetekben. Egy másik óvatosság, hogy az összetett függőségi gráfok, ahol minden tranzakció nagy számú bejövő és kimenő függőségtel rendelkezik, és az egyes tranzakciók számos függőségi réteget tartalmazhatnak, a rendszerben nem hatékonyak lehetnek. A következőkre vonatkozik: SQL Server 2016 (13.x). Az SQL Server és az Azure SQL Database későbbi verziói nem korlátozzák a véglegesítési függőségek számát.

Újrapróbálkozás logikája

Ha egy tranzakció a korábban említett feltételek bármelyike miatt meghiúsul, próbálkozzon újra a tranzakcióval.

Az újrapróbálkozás logikáját az ügyfél vagy a kiszolgáló oldalán implementálhatja. Az újrapróbálkozás logikájának implementálása az ügyféloldalon a jobb hatékonyság érdekében. Ezzel a módszerrel a tranzakció által visszaadott eredményhalmazokat is kezelheti a hiba bekövetkezése előtt.

T-SQL-kód újrapróbálkozása – példa

A kiszolgálóoldali újrapróbálkozás logikáját csak olyan tranzakciókhoz használja, amelyek nem adnak eredményhalmazokat az ügyfélnek. Ellenkező esetben az újrapróbálkozások extra eredményhalmazokat adhatnak vissza az ügyfélnek.

Az alábbi értelmezett T-SQL-szkript bemutatja, hogy az újrapróbálkozás logikája milyen lehet a memóriaoptimalizált táblákat érintő tranzakcióütközésekhez kapcsolódó hibák esetén.

-- Retry logic, in Transact-SQL.
DROP PROCEDURE If Exists usp_update_salesorder_dates;
GO

CREATE PROCEDURE usp_update_salesorder_dates
AS
BEGIN
    DECLARE @retry AS INT = 10;

    WHILE (@retry > 0)
    BEGIN

        BEGIN TRY
            BEGIN TRANSACTION;

            UPDATE dbo.SalesOrder_mo WITH (SNAPSHOT)
            SET OrderDate = GETUTCDATE()
            WHERE CustomerId = 42;

            UPDATE dbo.SalesOrder_mo WITH (SNAPSHOT)
            SET OrderDate = GETUTCDATE()
            WHERE CustomerId = 43;

            COMMIT TRANSACTION;

            SET @retry = 0; -- Stops the loop.
        END TRY

        BEGIN CATCH
            SET @retry - = 1;

            IF (@retry > 0
                AND ERROR_NUMBER() IN (41302, 41305, 41325, 41301, 41823, 41840, 41839, 1205))
                BEGIN
                    IF XACT_STATE() = -1
                        ROLLBACK TRANSACTION;

                    WAITFOR DELAY '00:00:00.001';
                END
            ELSE
                BEGIN
                    PRINT 'Suffered an error for which Retry is inappropriate.';
                    THROW;
                END
        END CATCH

    END -- While loop
END
GO

-- EXECUTE usp_update_salesorder_dates;

Tárolók közötti tranzakció

A tranzakció tárolók közötti tranzakció, ha:

• Egy memóriaoptimalizált táblához fér hozzá az értelmezett Transact-SQL-ből.
• Natív eljárás végrehajtása, amikor egy tranzakció már nyitva van (XACT_STATE() = 1).

A "tárolók közötti" kifejezés abból a tényből ered, hogy a tranzakció két tranzakciókezelési tárolón fut. Az egyik tároló lemezalapú táblákat, a másik pedig a memóriaoptimalizált táblákat kezeli.

Egyetlen tárolóközi tranzakción belül különböző elkülönítési szinteket használhat a lemezalapú és a memóriaoptimalizált táblák eléréséhez. Ezt a különbséget explicit táblatippekkel, például WITH (SERIALIZABLE) vagy az adatbázis opció MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT fejezheti ki. Ez a beállítás implicit módon emeli a memóriaoptimalizált tábla elkülönítési szintjét pillanatfelvételre, ha a TRANSACTION ISOLATION LEVELREAD COMMITTED vagy READ UNCOMMITTED értékre van konfigurálva.

A következő Transact-SQL példakódban:

• A lemezalapú tábla Table_D1az elkülönítési READ COMMITTED szinttel érhető el.
• A memóriaoptimalizált tábla Table_MO7 az elkülönítési SERIALIZABLE szinttel érhető el. Table_MO6 nem rendelkezik meghatározott elkülönítési szinttel, mivel a beszúrások mindig konzisztensek, és lényegében szerializálható elkülönítés alatt vannak végrehajtva.

-- Different isolation levels for
-- disk-based tables versus memory-optimized tables,
-- within one explicit transaction.
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
GO

BEGIN TRANSACTION;

-- Table_D1 is a traditional disk-based table, accessed using READ COMMITTED isolation.
SELECT *
FROM Table_D1;

-- Table_MO6 and Table_MO7 are memory-optimized tables.
-- Table_MO7 is accessed using SERIALIZABLE isolation,
-- while Table_MO6 does not have a specific isolation level.

INSERT INTO Table_MO6
SELECT *
FROM Table_MO7 WITH (SERIALIZABLE);

COMMIT TRANSACTION;

Korlátozások

• Az adatbázisközi tranzakciók nem támogatottak a memóriaoptimalizált táblák esetében. Ha egy tranzakció egy memóriaoptimalizált táblához fér hozzá, a tranzakció nem fér hozzá más adatbázishoz, kivéve a következőket:

  • tempdb Adatbázis.
  • Írásvédett hozzáférés az master adatbázishoz.

• Az elosztott tranzakciók nem támogatottak: Ha használja BEGIN DISTRIBUTED TRANSACTION, a tranzakció nem fér hozzá a memóriaoptimalizált táblához.

Natív módon lefordított tárolt eljárások

• Natív procben a ATOMIC blokknak deklarálnia kell a teljes blokk tranzakcióelkülönítési szintjét, például:

  ... BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, ...) ...

• A natív tárolt eljárás törzsébe nem lehet explicit tranzakcióvezérlési utasításokat belefoglalni. Az BEGIN TRANSACTION és ROLLBACK TRANSACTION utasítások nem engedélyezettek.

• A blokkokkal történő ATOMIC tranzakcióvezérlésről további információt az atomblokkok natív eljárásokban című témakörben talál.

Kapcsolódó tartalom

• SET IMPLICIT_TRANSACTIONS (Transact-SQL)
• sys.sp_getapplock (Transact-SQL)
• Sorverzió-alapú elkülönítési szintek az adatbázismotorban
• Tranzakció tartósságának szabályozása