Változáskövetés használata (SQL Server)

A következőkre vonatkozik:SQL Server Azure SQL Database Felügyelt Azure SQL-példány SQL-adatbázis a Microsoft Fabricben

A változáskövetést használó alkalmazásoknak képesnek kell lenniük a korrektúrák lekérésére, a módosítások egy másik adattárban való alkalmazására és a forrásadatbázis frissítésére. Ez a cikk bemutatja, hogyan hajthatók végre ezek a feladatok, valamint ismerteti a szerepek megváltoztatásának nyomon követését, amikor feladatátvétel történik, és egy adatbázist vissza kell állítani egy biztonsági másolatból.

Változások lekérése változáskövetési függvények használatával

Ez a cikk azt ismerteti, hogyan szerezhet be módosításokat és információkat az adatbázison végrehajtott módosításokról a változáskövetési függvények használatával.

A változáskövetési függvények ismertetése

Az alkalmazások az alábbi függvényekkel szerezhetik be az adatbázisban végrehajtott módosításokat és a módosításokkal kapcsolatos információkat:

CHANGETABLE(CHANGES ...) funkció

Ez a sorhalmazfüggvény a módosítási információk lekérdezésére szolgál. A függvény lekérdezi a belső változáskövetési táblákban tárolt adatokat. A függvény egy eredményhalmazt ad vissza, amely tartalmazza a módosított sorok elsődleges kulcsait más változási információkkal, például a művelettel, a frissített oszlopokkal és a sor verziójával együtt.

CHANGETABLE(CHANGES ...) argumentumként egy utolsó szinkronizálási verziót használ. Az utolsó szinkronizálási verzió a @last_synchronization_version változóval lesz lekért. Az utolsó szinkronizálási verzió szemantikája a következő:
A hívó ügyfél megkapta a módosításokat, és ismeri az összes módosítást, beleértve az utolsó szinkronizálási verziót is.
CHANGETABLE(CHANGES ...) ezért a legutóbbi szinkronizálási verzió után történt összes módosítást visszaadja.

Az alábbi ábra bemutatja, hogyan CHANGETABLE(CHANGES ...) történik a módosítások beszerzése.

Ebben a példában az A ügyfél utoljára 9:30-kor szinkronizált, míg a B ügyfél utoljára 10:30-kor szinkronizált. 10:00-kor és ismét 11:00-kor több módosítás történt az adatokon. Az alábbi példában összefoglaljuk a követett változásokat.

CHANGETABLE(CHANGES...) Kimenet – 11:30

A ügyfél utolsó szinkronizálása 9:30-kor.

`Product ID`	Művelet	Oszlopok
139	Frissít	Név, ár
140	Töröl	-
141	Beilleszt	-

Client B utoljára 10:30-kor szinkronizált.

`Product ID`	Művelet	Oszlopok
139	Frissít	Ár
140	Töröl	-
141	Frissít	Ár

CHANGE_TRACKING_CURRENT_VERSION() funkció

A módosítások lekérdezésekor a következő alkalommal használt aktuális verzió beszerzésére szolgál. Ez a verzió az utolsó véglegesített tranzakció verzióját jelöli.
CHANGE_TRACKING_MIN_VALID_VERSION() funkció

A minimális érvényes verzió beszerzésére szolgál, amelyből az ügyfél rendelkezhet, és továbbra is érvényes eredményeket szerezhet be.CHANGETABLE() Az ügyfélnek ellenőriznie kell az utolsó szinkronizálási verziót a függvény által visszaadott értéken. Ha az utolsó szinkronizálási verzió kisebb, mint a függvény által visszaadott verzió, az ügyfél nem tud érvényes eredményeket beszerezni, CHANGETABLE() és újra kell majd inicializálnia.

Kezdeti adatok beszerzése

Ahhoz, hogy egy alkalmazás első alkalommal be tudja szerezni a módosításokat, az alkalmazásnak egy lekérdezést kell küldenie a kezdeti adatok és a szinkronizálási verzió beszerzéséhez. Az alkalmazásnak közvetlenül a táblából kell beszereznie a megfelelő adatokat, majd CHANGE_TRACKING_CURRENT_VERSION() segítségével kell megszereznie a kezdeti verziót. A verziót akkor továbbítja, amikor a módosításokat először kapják meg CHANGETABLE(CHANGES ...).

Az alábbi példa bemutatja, hogyan szerezheti be a kezdeti szinkronizálási verziót és a kezdeti adatkészletet.

declare @synchronization_version bigint;

-- Obtain the current synchronization version. This will be used next time that changes are obtained.
SET @synchronization_version = CHANGE_TRACKING_CURRENT_VERSION();

-- Obtain initial data set.
SELECT
    P.ProductID, P.Name, P.ListPrice
FROM
   SalesLT.Product AS P;

Változások lekérése a változáskövetési függvényekkel

Ha be szeretné szerezni egy tábla módosított sorait és a módosításokkal kapcsolatos információkat, használja a következőt CHANGETABLE(CHANGES...): . Például az alábbi lekérdezés a SalesLT.Product táblázat módosításait szerzi meg.

declare @last_synchronization_version bigint;

SELECT
    CT.ProductID, CT.SYS_CHANGE_OPERATION,
    CT.SYS_CHANGE_COLUMNS, CT.SYS_CHANGE_CONTEXT
FROM
    CHANGETABLE(CHANGES SalesLT.Product, @last_synchronization_version) AS CT;

Az ügyfél általában a sor elsődleges kulcsai helyett a sor legfrissebb adatait szeretné megszerezni. Ezért egy alkalmazás összekapcsolja az eredményeket CHANGETABLE(CHANGES ...) a felhasználói táblában lévő adatokkal. Az alábbi lekérdezés például a SalesLT.Product táblával csatlakozik a Name és ListPrice oszlopok értékeinek lekéréséhez. Figyelje meg a OUTER JOINhasználatát. Erre azért van szükség, hogy a rendszer visszaadja a módosítási információkat a felhasználói táblából törölt sorokra vonatkozóan.

SELECT
    CT.ProductID, P.Name, P.ListPrice,
    CT.SYS_CHANGE_OPERATION, CT.SYS_CHANGE_COLUMNS,
    CT.SYS_CHANGE_CONTEXT
FROM
    SalesLT.Product AS P
RIGHT OUTER JOIN
    CHANGETABLE(CHANGES SalesLT.Product, @last_synchronization_version) AS CT
ON
    P.ProductID = CT.ProductID;

A következő módosítási számbavételhez használandó verzió beszerzéséhez használja a CHANGE_TRACKING_CURRENT_VERSION() elemet az alábbi példában látható módon.

SET @synchronization_version = CHANGE_TRACKING_CURRENT_VERSION();

Amikor egy alkalmazás beszerzi a módosításokat, a CHANGETABLE(CHANGES...) és a CHANGE_TRACKING_CURRENT_VERSION() függvényt is használnia kell az alábbi példában látható módon.

-- Obtain the current synchronization version. This will be used the next time CHANGETABLE(CHANGES...) is called.
SET @synchronization_version = CHANGE_TRACKING_CURRENT_VERSION();

-- Obtain incremental changes by using the synchronization version obtained the last time the data was synchronized.
SELECT
    CT.ProductID, P.Name, P.ListPrice,
    CT.SYS_CHANGE_OPERATION, CT.SYS_CHANGE_COLUMNS,
    CT.SYS_CHANGE_CONTEXT
FROM
    SalesLT.Product AS P
RIGHT OUTER JOIN
    CHANGETABLE(CHANGES SalesLT.Product, @last_synchronization_version) AS CT
ON
    P.ProductID = CT.ProductID;

Verziószámok

A változáskövetést engedélyező adatbázis egy verziószámlálóval rendelkezik, amely a változáskövetett táblák módosításakor növekszik. Minden módosított sorhoz tartozik egy verziószám. Amikor a rendszer kérést küld egy alkalmazásnak a módosítások lekérdezésére, a rendszer egy olyan függvényt hív meg, amely egy verziószámot ad meg. A függvény az adott verzió óta végrehajtott összes módosítással kapcsolatos információkat adja vissza. Bizonyos módokon a változáskövetési verzió a rowversion adattípushoz hasonló.

Az utolsó szinkronizált verzió ellenőrzése

A módosításokkal kapcsolatos információk korlátozott ideig megmaradnak. Az időtartamot a CHANGE_RETENTION paraméter szabályozza, amely a ALTER DATABASE részeként adható meg.

A megadott CHANGE_RETENTION idő határozza meg, hogy az összes alkalmazásnak milyen gyakran kell módosításokat kérnie az adatbázisból. Ha egy alkalmazás olyan értékkel last_synchronization_version rendelkezik, amely régebbi, mint egy tábla minimális érvényes szinkronizálási verziója, akkor az alkalmazás nem tud érvényes módosítási enumerálást végrehajtani. Ennek az az oka, hogy egyes módosítási információk törölve lettek. Mielőtt egy alkalmazás módosításokat szerez be a használatával CHANGETABLE(CHANGES ...), az alkalmazásnak ellenőriznie kell annak az értéknek last_synchronization_version az értékét, amelyet át szeretne adni CHANGETABLE(CHANGES ...). Ha az érték last_synchronization_version nem érvényes, az alkalmazásnak újra kell újrainicializálnia az összes adatot.

Az alábbi példa bemutatja, hogyan ellenőrizheti az egyes táblák last_synchronization_version értékének érvényességét.

-- Check individual table.
IF (@last_synchronization_version < CHANGE_TRACKING_MIN_VALID_VERSION(
                                   OBJECT_ID('SalesLT.Product')))
BEGIN
  -- Handle invalid version and do not enumerate changes.
  -- Client must be reinitialized.
END;

Ahogy az alábbi példa is mutatja, a last_synchronization_version értékének érvényességét az adatbázis összes táblájában ellenőrizheti.

-- Check all tables with change tracking enabled
IF EXISTS (
  SELECT 1 FROM sys.change_tracking_tables
  WHERE min_valid_version > @last_synchronization_version )
BEGIN
  -- Handle invalid version & do not enumerate changes
  -- Client must be reinitialized
END;

Oszlopkövetés használata

Az oszlopkövetés lehetővé teszi, hogy az alkalmazások csak a teljes sor helyett csak a módosított oszlopok adatait szerezze be. Vegyük például azt a forgatókönyvet, amelyben egy tábla egy vagy több oszlopot tartalmaz, amelyek nagyok, de ritkán változnak; és más, gyakran változó oszlopokkal is rendelkezik. Oszlopkövetés nélkül az alkalmazás csak azt tudja megállapítani, hogy egy sor megváltozott, és szinkronizálnia kell a nagy oszlopadatokat tartalmazó összes adatot. Az oszlopkövetés használatával azonban az alkalmazás meghatározhatja, hogy a nagy oszlopadatok megváltoztak-e, és csak akkor szinkronizálják az adatokat, ha módosultak.

Az oszlopkövetési információk a SYS_CHANGE_COLUMNS függvény által visszaadott CHANGETABLE(CHANGES ...) oszlopban jelennek meg.

Az oszlopkövetés használható úgy, hogy NULL a rendszer visszaadja a nem módosított oszlopokat. Ha az oszlopot NULL-re lehet módosítani, egy külön oszlopot kell visszaadni annak jelzésére, hogy az oszlop megváltozott-e.

Az alábbi példában a CT_ThumbnailPhoto oszlop NULL lesz, ha az oszlop nem változott. Ez az oszlop lehetNULL, mert át lett állítva NULL. Az alkalmazás az CT_ThumbNailPhoto_Changed oszlop használatával meghatározhatja, hogy az oszlop módosult-e.

DECLARE @PhotoColumnId int = COLUMNPROPERTY(
    OBJECT_ID('SalesLT.Product'),'ThumbNailPhoto', 'ColumnId');

SELECT
    CT.ProductID, P.Name, P.ListPrice, -- Always obtain values.
    CASE
           WHEN CHANGE_TRACKING_IS_COLUMN_IN_MASK(
                     @PhotoColumnId, CT.SYS_CHANGE_COLUMNS) = 1
            THEN ThumbNailPhoto
            ELSE NULL
      END AS CT_ThumbNailPhoto,
      CHANGE_TRACKING_IS_COLUMN_IN_MASK(
                     @PhotoColumnId, CT.SYS_CHANGE_COLUMNS) AS
                                   CT_ThumbNailPhoto_Changed,
     CT.SYS_CHANGE_OPERATION, CT.SYS_CHANGE_COLUMNS,
     CT.SYS_CHANGE_CONTEXT
FROM
     SalesLT.Product AS P
INNER JOIN
     CHANGETABLE(CHANGES SalesLT.Product, @last_synchronization_version) AS CT
ON
     P.ProductID = CT.ProductID AND
     CT.SYS_CHANGE_OPERATION = 'U';

Konzisztens és helyes eredmények beszerzése

Egy tábla módosított adatainak lekéréséhez több lépésre van szükség. Inkonzisztens vagy helytelen eredményeket adhat vissza, ha bizonyos problémákat nem mérlegelnek és kezelnek.

Ha például be szeretné szerezni egy Sales táblán és SalesOrders táblán végrehajtott módosításokat, az alkalmazás a következő lépéseket hajtja végre:

Ellenőrizze az utolsó szinkronizált verziót a következő használatával CHANGE_TRACKING_MIN_VALID_VERSION(): .
Szerezze be azt a verziót, amelyet a következő módosításkor használhat a CHANGE_TRACKING_CURRENT_VERSION() használatával.
A Sales táblázat módosításainak lekérése a CHANGETABLE(CHANGES ...) használatával.
A SalesOrders táblázat módosításainak lekérése a CHANGETABLE(CHANGES ...) használatával.

Az adatbázisban két folyamat zajlik, amelyek befolyásolhatják az előző lépések által visszaadott eredményeket:

A törlési folyamat a háttérben fut, és eltávolítja a megadott megőrzési időszaknál régebbi változáskövetési információkat.

A törlési folyamat egy különálló háttérfolyamat, amely az adatbázis változáskövetésének konfigurálásakor megadott megőrzési időt használja. A probléma az, hogy a törlési folyamat az utolsó szinkronizálási verzió ellenőrzése és a CHANGETABLE(CHANGES...) hívása között lehet. Előfordulhat, hogy az utolsó érvényes szinkronizálási verzió már nem érvényes a módosítások lekérésének időpontjáig. Ezért előfordulhat, hogy helytelen eredményeket ad vissza.
Folyamatban lévő DML-műveletek történnek a Sales és SalesOrders táblákban, például a következő műveletekben:
- A táblák CHANGE_TRACKING_CURRENT_VERSION() használatával módosíthatók, miután a következő alkalomra szánt verzió elérhetővé vált. Ezért a vártnál több módosítás adható vissza.
- A tranzakció a Sales tábla módosításainak beolvasására irányuló hívás és a SalesOrders tábla módosításainak beolvasására irányuló hívás közötti időszakban véglegesíthet. Ezért a SalesOrder tábla eredményei olyan idegenkulcs-értékkel rendelkezhetnek, amely nem szerepel a Sales táblában.

A korábban felsorolt kihívások leküzdése érdekében javasoljuk, hogy használjon pillanatkép-elkülönítést. Ez segít a változási információk konzisztenciájának biztosításában, és elkerüli a háttérkarbantartási feladathoz kapcsolódó versenyfeltételeket. Ha nem használ pillanatkép-tranzakciókat, a változáskövetést használó alkalmazás fejlesztése jelentősen több erőfeszítést igényelhet.

Pillanatkép-elkülönítés használata

A változáskövetés úgy lett kialakítva, hogy jól működjön a pillanatképek elkülönítésével. Az adatbázis pillanatkép-elkülönítését engedélyezni kell. A módosítások beszerzéséhez szükséges összes lépést bele kell foglalni egy pillanatkép-tranzakcióba. Ez biztosítja, hogy a módosítások beszerzésekor az adatokon végrehajtott összes módosítás ne legyen látható a pillanatkép-tranzakció lekérdezései számára.

A pillanatkép-tranzakción belüli adatok lekéréséhez hajtsa végre a következő lépéseket:

Állítsa a tranzakcióelkülönítési szintet pillanatképre, és indítsa el a tranzakciót.
Ellenőrizze az utolsó szinkronizálási verziót a CHANGE_TRACKING_MIN_VALID_VERSION() használatával.
Szerezze be a következő alkalommal használni kívánt verziót az CHANGE_TRACKING_CURRENT_VERSION() segítségével.
Szerezze meg a Sales táblázat módosításait a CHANGETABLE(CHANGES ...) használatával.
Szerezze meg a SalesOrders táblázat módosításait a CHANGETABLE(CHANGES ...) használatával.
Véglegesítse a tranzakciót.

Néhány megjegyzés, mivel a módosítások beszerzésének minden lépése egy pillanatkép-tranzakción belül van:

Ha a törlés az utolsó szinkronizálási verzió ellenőrzése után történik, az eredmények CHANGETABLE(CHANGES ...) továbbra is érvényesek lesznek, mivel a törléssel végrehajtott törlési műveletek nem lesznek láthatók a tranzakcióban.
Miután a következő szinkronizálási verziót beszerezték, a Sales vagy a SalesOrders táblában végrehajtott módosítások nem lesznek láthatók, és a CHANGETABLE(CHANGES ...) hívások soha nem fognak a CHANGE_TRACKING_CURRENT_VERSION() által visszaadott verziónál későbbi változásokat visszaadni. A Sales tábla és a SalesOrders tábla közötti konzisztencia is megmarad, mert a CHANGETABLE(CHANGES ...) hívások közötti időszakban véglegesített tranzakciók nem lesznek láthatók.

Az alábbi példa bemutatja, hogyan engedélyezve van a pillanatképek elkülönítése egy adatbázisban.

-- The database must be configured to enable snapshot isolation.
ALTER DATABASE AdventureWorksLT
    SET ALLOW_SNAPSHOT_ISOLATION ON;

Pillanatkép-tranzakciót a következőképpen használják:

SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRAN
  -- Verify that version of the previous synchronization is valid.
  -- Obtain the version to use next time.
  -- Obtain changes.
COMMIT TRAN

A pillanatkép-tranzakciókról további információt a SET TRANSACTION ISOLATION LEVEL (Transact-SQL)című cikkben talál.

Tisztítás és pillanatkép izolálás

Ha a pillanatkép-elkülönítést és a változáskövetést ugyanazon adatbázison, vagy két különböző adatbázison ugyanazon a példányon belül engedélyezi, a törlési folyamat lejárt sorokat hagyhat a sys.syscommittab-ban, ha az adatbázisban van egy nyitott tranzakció pillanatkép-elkülönítéssel. Ez akkor fordulhat elő, ha a változáskövetési tisztítási folyamat az egész példányra vonatkozó minimális küszöböt (ami a biztonságos tisztítási verzió) veszi figyelembe a tisztítás során. Ezzel biztosítható, hogy a változáskövetési automatikus törlési folyamat ne távolítson el olyan sorokat, amelyekre a pillanatkép-elkülönítést engedélyező adatbázis nyitott tranzakciója szükség lehet. Az olvasási, elkötelezett pillanatkép-izolációt és a pillanatkép-izolációs tranzakciókat tartsa a lehető legrövidebb ideig annak biztosítása érdekében, hogy a lejárt sorok a sys.syscommittab-ból időben törlődjenek.

A pillanatképek elkülönítésének alternatívái

Léteznek alternatív megoldások a pillanatkép-elkülönítés használatára, de több munkát igényelnek az összes alkalmazáskövetelmények teljesülése érdekében. Ha meg szeretné győződni arról, hogy az last_synchronization_version érvényes, és a törlési folyamat nem távolítja el az adatokat a módosítások beszerzése előtt, kövesse az alábbi lépéseket:

Ellenőrizze last_synchronization_version a hívások CHANGETABLE() utáni állapotát.
Ellenőrizze last_synchronization_version az egyes lekérdezések részeként, hogy megkapja a módosításokat CHANGETABLE() használatával.

A módosítások a következő számbavétel szinkronizálási verziójának beszerzése után is előfordulhatnak. Ezt a helyzetet kétféleképpen lehet kezelni. A használt beállítás az alkalmazástól és az egyes megközelítések mellékhatásainak kezelésétől függ:

Hagyja figyelmen kívül az új szinkronizálási verziónál nagyobb verziójú módosításokat.

Ennek a megközelítésnek az a mellékhatása, hogy egy új vagy frissített sor kihagyható, ha az új szinkronizálási verzió előtt lett létrehozva vagy frissítve, majd később frissült. Ha új sor van, hivatkozási integritási probléma léphet fel, ha egy másik, a kihagyott sorra hivatkozó táblában egy sor lett létrehozva. Ha van frissített meglévő sor, a program kihagyja a sort, és csak a következő alkalommal szinkronizálja.
Az összes változtatást belefoglalja, még azokat is, amelyek verziószáma nagyobb, mint az új szinkronizációs verzió.

Az új szinkronizálási verziónál nagyobb verziójú sorok a következő szinkronizáláskor lesznek ismét lekértek. Ezt az alkalmazásnak kell elvárnia és kezelnie.

Az előző két lehetőség mellett olyan megközelítést is létrehozhat, amely a művelettől függően egyesíti a két lehetőséget. Előfordulhat például, hogy olyan alkalmazást szeretne, amelynek a módosításait érdemes figyelmen kívül hagyni, mint a következő szinkronizálási verzió, amelyben a sort létrehozták vagy törölték, de a frissítéseket nem hagyja figyelmen kívül.

Jegyzet

A változáskövetés (vagy bármely egyéni nyomkövetési mechanizmus) használatakor az alkalmazáshoz használható megközelítés kiválasztása jelentős elemzést igényel. Ezért sokkal egyszerűbb a pillanatkép-elkülönítés használata.

Hogyan kezeli a változáskövetés az adatbázis módosításait?

Egyes változáskövetést használó alkalmazások kétirányú szinkronizálást végeznek egy másik adattárral. Vagyis az SQL Server-adatbázisban végrehajtott módosítások a másik adattárban frissülnek, a másik tárolóban végrehajtott módosítások pedig az SQL Server-adatbázisban lesznek frissítve.

Amikor egy alkalmazás frissíti a helyi adatbázist egy másik adattár módosításaival, az alkalmazásnak a következő műveleteket kell végrehajtania:

Ellenőrizze az ütközéseket.

Ütközés akkor fordul elő, ha ugyanazok az adatok egyszerre változnak mindkét adattárban. Az alkalmazásnak képesnek kell lennie arra, hogy ellenőrizze az ütközést, és elegendő információt szerezzen be az ütközés feloldásához.
Az alkalmazáskörnyezet adatainak tárolása.

Az alkalmazás a változáskövetési információkat tartalmazó adatokat tárolja. Ezek az információk más változáskövetési információkkal együtt is elérhetők lesznek, amikor a módosításokat a helyi adatbázisból szerezték be. Erre a környezeti információra gyakori példa a változás forrásaként szolgáló adattár azonosítója.

Az előző műveletek végrehajtásához a szinkronizálási alkalmazás a következő függvényeket használhatja:

CHANGETABLE(VERSION...)

Ha egy alkalmazás módosításokat végez, ezzel a függvénnyel ellenőrizheti az ütközéseket. A függvény lekérte a változáskövetési tábla egy adott sorának legújabb változáskövetési adatait. A változáskövetési információk tartalmazzák az utoljára módosított sor verzióját. Ez az információ lehetővé teszi az alkalmazás számára annak megállapítását, hogy a sor az alkalmazás legutóbbi szinkronizálása után módosult-e.
WITH CHANGE_TRACKING_CONTEXT

Az alkalmazások ezt a záradékot használhatják a környezeti adatok tárolására.

Ellenőrizze az ütközéseket

Kétirányú szinkronizálási forgatókönyv esetén az ügyfélalkalmazásnak meg kell határoznia, hogy egy sor nem lett-e frissítve, mióta az alkalmazás legutóbb megkapta a módosításokat.

Az alábbi példa bemutatja, hogyan használható a függvény az CHANGETABLE(VERSION ...) ütközések leghatékonyabb ellenőrzésére külön lekérdezés nélkül. A példában a CHANGETABLE(VERSION ...)által megadott sor SYS_CHANGE_VERSION-ét a @product id határozza meg. CHANGETABLE(CHANGES ...) ugyanazokat az információkat szerezheti be, de ez kevésbé lenne hatékony. Ha a sor SYS_CHANGE_VERSION értéke nagyobb, mint a @last_sync_versionértéke, ütközés történik. Ütközés esetén a sor nem frissül. A ISNULL() ellenőrzésre azért van szükség, mert előfordulhat, hogy a sorhoz nem állnak rendelkezésre változási információk. Nem léteznek változásinformációk, ha a sor nem frissült a változáskövetés engedélyezése vagy a változásadatok törlése óta.

-- Assumption: @last_sync_version has been validated.
UPDATE SalesLT.Product
SET ListPrice = @new_listprice
FROM SalesLT.Product AS P
WHERE ProductID = @product_id
    AND @last_sync_version >= ISNULL((
            SELECT CT.SYS_CHANGE_VERSION
            FROM CHANGETABLE(VERSION SalesLT.Product, (ProductID), (P.ProductID)) AS CT
            ), 0);

Az alábbi kód ellenőrizheti a frissített sorok számát, és további információkat tud azonosítani az ütközésről.

-- If the change cannot be made, find out more information.
IF (@@ROWCOUNT = 0)
BEGIN
    -- Obtain the complete change information for the row.
    SELECT
        CT.SYS_CHANGE_VERSION, CT.SYS_CHANGE_CREATION_VERSION,
        CT.SYS_CHANGE_OPERATION, CT.SYS_CHANGE_COLUMNS
    FROM
        CHANGETABLE(CHANGES SalesLT.Product, @last_sync_version) AS CT
    WHERE
        CT.ProductID = @product_id;

    -- Check CT.SYS_CHANGE_VERSION to verify that it really was a conflict.
    -- Check CT.SYS_CHANGE_OPERATION to determine the type of conflict:
    -- update-update or update-delete.
    -- The row that is specified by @product_id might no longer exist 
    -- if it has been deleted.
END

Környezeti adatok beállítása

A záradék használatával az WITH CHANGE_TRACKING_CONTEXT alkalmazás a környezeti információkat a módosítási információkkal együtt tárolhatja. Ez az információ ezután a SYS_CHANGE_CONTEXT által visszaadott CHANGETABLE(CHANGES ...) oszlopból szerezhető be.

A környezeti információk általában a módosítások forrásának azonosítására szolgálnak. Ha a módosítás forrása azonosítható, az adattár felhasználhatja ezeket az információkat, hogy elkerülje a módosítások beolvasását, amikor újra szinkronizálja.

-- Try to update the row and check for a conflict.
WITH CHANGE_TRACKING_CONTEXT (@source_id)
UPDATE
  SalesLT.Product
SET
  ListPrice = @new_listprice
FROM
  SalesLT.Product AS P
WHERE
  ProductID = @product_id AND
    @last_sync_version >= ISNULL (
    (SELECT CT.SYS_CHANGE_VERSION FROM CHANGETABLE(VERSION SalesLT.Product,
    (ProductID), (P.ProductID)) AS CT),
       0);

Konzisztens és helyes eredmények biztosítása

Az alkalmazásnak figyelembe kell vennie a törlési folyamatot, amikor ellenőrzi a @last_sync_versionértékét. Ennek az az oka, hogy az adatok eltávolításra kerülhettek a CHANGE_TRACKING_MIN_VALID_VERSION() hívása után, de még a frissítés előtt.

Használja a pillanatkép-elkülönítést, és végezze el a módosításokat egy pillanatkép-tranzakción belül.

-- Prerequisite is to ensure ALLOW_SNAPSHOT_ISOLATION is ON for the database.

SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRAN
    -- Verify that last_sync_version is valid.
    IF (@last_sync_version <
CHANGE_TRACKING_MIN_VALID_VERSION(OBJECT_ID('SalesLT.Product')))
    BEGIN
       RAISERROR (N'Last_sync_version too old', 16, -1);
    END
    ELSE
    BEGIN
        -- Try to update the row.
        -- Check @@ROWCOUNT and check for a conflict.
    END;
COMMIT TRAN;

Jegyzet

Előfordulhat, hogy a pillanatkép-tranzakción belül frissített sor egy másik tranzakcióban is frissülhetett volna a pillanatkép-tranzakció elindítása után. Ebben az esetben pillanatkép-elkülönítési frissítési ütközés lép fel, amely a tranzakció leállításához vezet. Ha ez történik, próbálkozzon újra a frissítés használatával. Ez azt eredményezi, hogy a rendszer változáskövetési ütközést észlel, és nem módosítja a sorokat.

Változáskövetés és adat-visszaállítás

A szinkronizálást igénylő alkalmazásoknak figyelembe kell venniük azt az esetet, amikor egy változáskövetést engedélyező adatbázis visszaállítja az adatok egy korábbi verzióját. Ez akkor fordulhat elő, ha egy adatbázis visszaállítása biztonsági másolatból történik, amikor átkapcsolás történik egy aszinkron adatbázistükörre, vagy ha hiba történik a naplóátvitel használatakor. A következő forgatókönyv a problémát szemlélteti:

A T1 tábla változáskövetésű, a tábla minimális érvényes verziója pedig 50.
Az ügyfélalkalmazás szinkronizálja az adatokat a 100-as verzióban, és információt szerez be az 50-es és a 100-as verzió közötti összes változásról.
A 100-es verzió után további módosítások történnek a T1 táblában.
A 120-es verziónál hiba történt, és az adatbázis-rendszergazda adatvesztéssel állítja vissza az adatbázist. A visszaállítási művelet után a tábla a 70-es verzióig tartalmaz adatokat, és a minimális szinkronizált verzió még mindig 50.

Ez azt jelenti, hogy a szinkronizált adattár olyan adatokkal rendelkezik, amelyek már nem léteznek az elsődleges adattárban.
A T1 többször frissül. Ez a jelenlegi verziót 130-ra emeli.
Az ügyfélalkalmazás ismét szinkronizál, és a 100 utolsó szinkronizált verzióját biztosítja. Az ügyfél sikeresen ellenőrzi ezt a számot, mert a 100 nagyobb, mint 50.

Az ügyfél a 100-130-es verzió közötti módosításokat szerzi be. Jelenleg az ügyfél nem tudja, hogy a 70 és 100 közötti változások nem ugyanazok, mint korábban. Az ügyfél és a kiszolgáló adatai nincsenek szinkronizálva.

Ha az adatbázis a 100-es verzió után egy pontra lett helyreállítva, a szinkronizálással nem lenne probléma. Az ügyfél és a kiszolgáló a következő szinkronizálási időköz során megfelelően szinkronizálja az adatokat.

A változáskövetés nem támogatja az adatvesztés utáni helyreállítást. Az ilyen típusú szinkronizálási problémák észlelésére azonban két lehetőség áll rendelkezésre:

Tárolja az adatbázis verzióazonosítóját a kiszolgálón, és frissítse ezt az értéket, amikor egy adatbázis helyreáll, vagy más módon elveszíti az adatokat. Minden ügyfélalkalmazás tárolja az azonosítót, és minden ügyfélnek ellenőriznie kell ezt az azonosítót az adatok szinkronizálásakor. Adatvesztés esetén az azonosítók nem egyeznek, és az ügyfelek újrainicializálják azokat. Az egyik hátránya, hogy ha az adatvesztés nem lépi át az utolsó szinkronizált határt, előfordulhat, hogy az ügyfél szükségtelen újraincializálást végez.
Amikor egy ügyfél lekérdezi a módosításokat, jegyezze fel a kiszolgálón lévő összes ügyfél legutóbbi szinkronizálási verziószámát. Ha probléma van az adatokkal, az utolsó szinkronizált verziószámok nem egyeznek. Ez azt jelzi, hogy újraincializálásra van szükség.

Visszacsatolás

Hasznos volt ez az oldal?

Last updated on 2025-11-18