Práce se sledováním změn (SQL Server)

platí pro:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceSQL databáze v Microsoft Fabric

Aplikace, které používají sledování změn, musí mít možnost získat sledované změny, použít tyto změny do jiného úložiště dat a aktualizovat zdrojovou databázi. Tento článek popisuje, jak tyto úlohy provést, a také jakou roli hraje sledování změn, když dojde k převzetí služeb při selhání a databáze se musí obnovit ze zálohy.

Získání změn pomocí funkcí sledování změn

Popisuje, jak pomocí funkcí sledování změn získat změny a informace o změnách provedených v databázi.

Informace o funkcích sledování změn

Aplikace můžou použít následující funkce k získání změn provedených v databázi a informací o těchto změnách:

• CHANGETABLE(CHANGES ...) funkce

  Tato funkce sady řádků slouží k dotazování na informace o změnách. Funkce se dotazuje na data uložená v interních tabulkách sledování změn. Funkce vrátí sadu výsledků obsahující primární klíče řádků, které se změnily společně s dalšími informacemi o změnách, jako jsou operace, sloupce aktualizované a verze řádku.

  CHANGETABLE(CHANGES ...) přebírá poslední synchronizační verzi jako argument. Poslední synchronizační verze se získá pomocí proměnné @last_synchronization_version. Sémantika poslední synchronizační verze je následující:

• Volající klient získal změny a ví o všech změnách včetně poslední synchronizační verze.

• CHANGETABLE(CHANGES ...) proto vrátí všechny změny, ke kterým došlo po poslední verzi synchronizace.

Následující obrázek ukazuje, jak CHANGETABLE(CHANGES ...) se používají k získání změn.

V tomto příkladu se klient A naposledy synchronizoval v 9:30, zatímco klient B naposledy synchronizoval v 10:30. V 10:00 a znovu v 11:00 došlo k několika změnám dat. Tyto sledované změny jsou shrnuty v následujícím příkladu.

CHANGETABLE(CHANGES...) Výstup – 11:30

Klient A se naposledy synchronizoval v 9:30 dopoledne.

Product ID	Operace	Sloupce
139	Aktualizace	Název, Cena
140	Vymazat	-
141	Vložit	-

Klient B se naposledy synchronizoval v 10:30.

Product ID	Operace	Sloupce
139	Aktualizace	Cena
140	Vymazat	-
141	Aktualizace	Cena

• CHANGE_TRACKING_CURRENT_VERSION() funkce

  Používá se k získání aktuální verze, která se použije při příštím dotazování změn. Tato verze představuje verzi poslední potvrzené transakce.

• CHANGE_TRACKING_MIN_VALID_VERSION() funkce

  Používá se k získání minimální platné verze, kterou klient může mít a stále získat platné výsledky z CHANGETABLE(). Klient by měl zkontrolovat poslední synchronizační verzi s hodnotou vrácenou touto funkcí. Pokud je poslední synchronizační verze menší než verze vrácená touto funkcí, klient nebude moct získat platné výsledky CHANGETABLE() a bude muset znovu inicializovat.

Získání počátečních dat

Aby aplikace poprvé získala změny, musí aplikace odeslat dotaz, aby získala počáteční data a verzi synchronizace. Aplikace musí získat příslušná data přímo z tabulky a pak použít CHANGE_TRACKING_CURRENT_VERSION() k získání počáteční verze. Tato verze bude předána CHANGETABLE(CHANGES ...) při prvním získání změn.

Následující příklad ukazuje, jak získat počáteční synchronizační verzi a počáteční sadu dat.

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;

Použijte funkce sledování změn, aby se zjistily změny

Chcete-li získat změněné řádky tabulky a informace o změnách, použijte CHANGETABLE(CHANGES...). Například následující dotaz získává změny v tabulce SalesLT.Product.

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;

Klient obvykle bude chtít získat nejnovější data pro řádek místo pouze primárních klíčů pro řádek. Aplikace by proto spojila výsledky z CHANGETABLE(CHANGES ...) s daty v tabulce uživatelů. Například následující dotaz spojí s tabulkou SalesLT.Product, aby získal hodnoty pro Name a ListPrice sloupce. Všimněte si použití OUTER JOIN. To je nutné, aby se zajistilo, že se informace o změnách vrátí pro řádky, které byly odstraněny z tabulky uživatelů.

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;

Pokud chcete získat verzi pro použití v dalším výčtu změn, použijte CHANGE_TRACKING_CURRENT_VERSION(), jak je znázorněno v následujícím příkladu.

SET @synchronization_version = CHANGE_TRACKING_CURRENT_VERSION();

Když aplikace získá změny, musí použít jak CHANGETABLE(CHANGES...), tak CHANGE_TRACKING_CURRENT_VERSION(), jak je znázorněno v následujícím příkladu.

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

Čísla verzí

Databáze s povoleným sledováním změn má čítač verze, který se zvyšuje při změnách sledovaných tabulek. Každý změněný řádek má číslo verze, které je k němu přidružené. Když se do aplikace odešle požadavek na dotaz na změny, volá se funkce, která poskytuje číslo verze. Funkce vrátí informace o všech změnách, které byly provedeny od této verze. Verze sledování změn je v některých ohledech podobná verzi rowversion datového typu.

Ověření poslední synchronizované verze

Informace o změnách se uchovávají po omezenou dobu. Délka času je řízena parametrem CHANGE_RETENTION , který lze zadat jako součást ALTER DATABASE.

Čas určený pro CHANGE_RETENTION určuje, jak často musí všechny aplikace požadovat změny z databáze. Pokud má aplikace hodnotu starší last_synchronization_version než minimální platná synchronizační verze tabulky, nemůže tato aplikace provádět platný výčet změn. Důvodem je to, že některé informace o změnách mohly být vyčištěny. Před tím, než aplikace získá změny prostřednictvím CHANGETABLE(CHANGES ...), musí aplikace ověřit hodnotu last_synchronization_version, kterou plánuje předat do CHANGETABLE(CHANGES ...). Pokud hodnota last_synchronization_version není platná, musí tato aplikace znovu inicializovat všechna data.

Následující příklad ukazuje, jak ověřit platnost hodnoty last_synchronization_version pro každou tabulku.

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

Jak ukazuje následující příklad, platnost hodnoty last_synchronization_version lze zkontrolovat u všech tabulek v databázi.

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

Použijte sledování sloupců

Sledování sloupců umožňuje aplikacím získat data pouze pro sloupce, které se změnily místo celého řádku. Představte si například scénář, ve kterém má tabulka jeden nebo více sloupců, které jsou velké, ale zřídka se mění; a obsahuje i další sloupce, které se často mění. Bez sledování sloupců může aplikace určit, že se řádek změnil a bude muset synchronizovat všechna data, která obsahují velká data sloupce. Pomocí sledování sloupců ale může aplikace určit, jestli se velká data ve sloupci změnila, a synchronizovat je pouze v případě, že se změnila.

Informace o sledování sloupců se zobrazí ve sloupci SYS_CHANGE_COLUMNS, kterou vrátí funkce CHANGETABLE(CHANGES ...).

Sledování sloupců se dá použít, aby se NULL vrátil pro sloupec, který se nezměnil. Pokud je možné sloupec změnit na NULL, musí se vrátit samostatný sloupec, aby bylo možné určit, jestli se sloupec změnil.

V následujícím příkladu bude sloupec CT_ThumbnailPhotoNULL, pokud se tento sloupec nezměnil. Tento sloupec může být NULL také proto, že byl změněn na NULL. Aplikace může pomocí CT_ThumbNailPhoto_Changed sloupce určit, jestli se sloupec změnil.

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';

Získání konzistentních a správných výsledků

Získání změněná data pro tabulku vyžaduje několik kroků. Nekonzistentní nebo nesprávné výsledky můžou být vráceny, pokud nejsou některé problémy zohledněny a řešeny.

Pokud chcete například získat změny provedené v tabulce Sales a SalesOrders tabulce, aplikace provede následující kroky:

1. Ověřte poslední synchronizovanou verzi pomocí .CHANGE_TRACKING_MIN_VALID_VERSION()

2. Získejte verzi, kterou lze použít k získání změny při příštím použití CHANGE_TRACKING_CURRENT_VERSION().

3. Získejte změny pro tabulku Sales pomocí CHANGETABLE(CHANGES ...).

4. Získejte změny pro tabulku SalesOrders pomocí CHANGETABLE(CHANGES ...).

V databázi se vyskytují dva procesy, které můžou ovlivnit výsledky vrácené předchozími kroky:

• Proces čištění běží na pozadí a odebere informace o sledování změn, které jsou starší než zadaná doba uchovávání.

  Proces čištění je samostatný proces na pozadí, který používá dobu uchovávání, která je zadaná při konfiguraci sledování změn pro databázi. Problém spočívá v tom, že proces čištění může nastat v době mezi ověřením poslední synchronizační verze a provedením volání CHANGETABLE(CHANGES...). Poslední platná verze synchronizace už nemusí být platná v době, kdy se změny načtou. Proto mohou být vráceny nesprávné výsledky.

• Probíhající operace DML probíhají v tabulkách Sales a SalesOrders, jako jsou například následující operace:

  • Změny v tabulkách lze provést po získání verze pro příští použití pomocí CHANGE_TRACKING_CURRENT_VERSION(). Proto je možné vrátit více změn, než se očekávalo.

  • Transakce se může potvrdit v době mezi voláním pro načtení změn z tabulky Sales a voláním pro načtení změn z tabulky SalesOrders. Proto výsledky tabulky SalesOrder mohou mít hodnotu cizího klíče, která v tabulce Sales neexistuje.

Pokud chcete překonat dříve uvedené výzvy, doporučujeme použít izolaci snímků. To vám pomůže zajistit konzistenci informací o změnách a vyhnout se podmínkám soutěže, které souvisejí s úlohou čištění na pozadí. Pokud nepoužíváte transakce snímků, může vývoj aplikace, která používá sledování změn, vyžadovat výrazně větší úsilí.

Použijte izolaci snímků

Sledování změn bylo navrženo tak, aby dobře fungovalo s izolací snímků. Izolace snímků musí být pro databázi povolená. Všechny kroky potřebné k získání změn musí být zahrnuty do transakce snímku. Tím zajistíte, že všechny změny provedené v datech při získávání změn nebudou viditelné pro dotazy uvnitř transakce snímku.

Pokud chcete získat data uvnitř transakce snímku, proveďte následující kroky:

1. Nastavte úroveň izolace transakce na snímek a spusťte transakci.

2. Ověřte poslední synchronizační verzi pomocí .CHANGE_TRACKING_MIN_VALID_VERSION()

3. Získejte verzi, která se použije příště pomocí CHANGE_TRACKING_CURRENT_VERSION().

4. Získání změn tabulky Sales pomocí CHANGETABLE(CHANGES ...)

5. Získání změn tabulky SalesOrders pomocí CHANGETABLE(CHANGES ...)

6. Potvrďte transakci.

Některé body, které je potřeba pamatovat, protože všechny kroky k získání změn jsou uvnitř transakce snímku:

• Pokud dojde k vyčištění po ověření poslední synchronizační verze, výsledky z CHANGETABLE(CHANGES ...) budou stále platné, protože operace odstranění prováděné vyčištěním nebudou viditelné uvnitř transakce.

• Jakékoli změny provedené v tabulce Sales nebo tabulce SalesOrders po získání další verze synchronizace nebudou viditelné a volání na CHANGETABLE(CHANGES ...) nikdy nevrátí změny s verzí novější, než je ta, kterou vrátí CHANGE_TRACKING_CURRENT_VERSION(). Bude zachována také konzistence mezi Sales tabulkou a SalesOrders tabulkou, protože transakce, které byly potvrzeny v době mezi voláními CHANGETABLE(CHANGES ...) , nebudou viditelné.

Následující příklad ukazuje, jak je pro databázi povolená izolace snímků.

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

Transakce snímku se používá takto:

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

Další informace o transakcích snímků najdete v části SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

Izolace vyčištění a snímání snímků

Povolení izolace snímků i sledování změn buď ve stejné databázi, nebo ve dvou různých databázích ve stejné instanci může vést k tomu, že proces čištění zanechá vypršené řádky v sys.syscommittab, když je v databázi otevřená transakce s aktivovanou izolací snímků. K tomu může dojít, protože proces čištění sledování změn bere v úvahu „nízkou vodní značku“ na úrovni celé instance (což je bezpečná verze pro čištění) při provádění čištění. Tím zajistíte, že proces automatického čištění sledování změn neodebere žádné řádky, které by mohla vyžadovat otevřená transakce v databázi s povolenou izolací snímků. Udržujte potvrzenou izolaci snímků a transakce izolace snímků co nejkratší, aby se zajistilo, že řádky s vypršenou platností z sys.syscommittab se včas vyčistí.

Alternativy k izolaci snímků

Existují alternativy k použití izolace snímků, ale vyžadují více práce, aby se zajistily splnění všech požadavků aplikace. Pokud chcete zajistit, aby last_synchronization_version byl platný a data nebyla před získáním změn odstraněna procesem čištění, postupujte takto:

1. Zkontrolujte last_synchronization_version po voláních na CHANGETABLE().

2. V rámci každého dotazu zkontrolujte last_synchronization_version , jestli chcete získat změny pomocí CHANGETABLE().

Změny mohou nastat po získání synchronizační verze pro další výčet. Existují dva způsoby, jak tuto situaci zvládnout. Použitá možnost závisí na aplikaci a na tom, jak dokáže zvládnout vedlejší účinky jednotlivých přístupů:

• Ignorujte změny, které mají verzi větší než nová synchronizační verze.

  Tento přístup má vedlejší účinek, že se nový nebo aktualizovaný řádek přeskočí, pokud byl vytvořen nebo aktualizován před novou verzí synchronizace, ale potom se aktualizoval. Pokud existuje nový řádek, může dojít k problému s referenční integritou, pokud byl řádek v jiné tabulce, která odkazovala na vynechaný řádek. Pokud existuje aktualizovaný existující řádek, řádek se přeskočí a nesynchronizuje se až do dalšího okamžiku.

• Zahrňte všechny změny, i ty, které mají verzi větší než nová synchronizační verze.

  Řádky, které mají verzi větší než nová synchronizační verze, se znovu získají při další synchronizaci. To musí aplikace očekávat a zpracovat.

Kromě předchozích dvou možností můžete navrhnout přístup, který kombinuje obě možnosti v závislosti na operaci. Můžete například chtít aplikaci, pro kterou je nejlepší ignorovat změny novější než příští synchronizační verze, ve které byl řádek vytvořen nebo odstraněn, ale aktualizace se neignorují.

Poznámka

Volba přístupu, který bude pro aplikaci fungovat při používání sledování změn (nebo jakéhokoli vlastního mechanismu sledování), vyžaduje významnou analýzu. Proto je mnohem jednodušší používat izolaci snímků.

Jak sledování změn zpracovává změny v databázi

Některé aplikace, které používají sledování změn, provádějí obousměrnou synchronizaci s jiným úložištěm dat. To znamená, že změny provedené v databázi SQL Serveru se aktualizují v jiném úložišti dat a změny provedené v druhém úložišti se aktualizují v databázi SQL Serveru.

Když aplikace aktualizuje místní databázi změnami z jiného úložiště dat, musí aplikace provádět následující operace:

• Zkontrolujte konflikty.

  Ke konfliktu dochází, když se stejná data změní ve stejnou dobu v obou úložištích dat. Aplikace musí být schopná zkontrolovat konflikt a získat dostatek informací, aby bylo možné konflikt vyřešit.

• Uložte informace o kontextu aplikace.

  Aplikace ukládá data, která mají informace o sledování změn. Tyto informace by byly k dispozici společně s dalšími informacemi o sledování změn při získání změn z místní databáze. Běžným příkladem těchto kontextových informací je identifikátor úložiště dat, který byl zdrojem změny.

K provedení předchozích operací může synchronizační aplikace používat následující funkce:

• CHANGETABLE(VERSION...)

  Když aplikace provádí změny, může pomocí této funkce zkontrolovat konflikty. Funkce získá nejnovější informace o sledování změn pro zadaný řádek ve sledované tabulce změn. Informace o sledování změn zahrnují verzi řádku, který byl naposledy změněn. Tyto informace umožňují aplikaci určit, jestli se řádek po poslední synchronizaci aplikace změnil.

• WITH CHANGE_TRACKING_CONTEXT

  Aplikace může tuto klauzuli použít k ukládání kontextových dat.

Kontrola konfliktů

V obousměrné situaci synchronizace musí klientská aplikace určit, jestli se od posledního získání změn neaktualizoval řádek.

Následující příklad ukazuje, jak pomocí CHANGETABLE(VERSION ...) funkce zkontrolovat konflikty nejúčinnějším způsobem bez samostatného dotazu. V příkladu určuje CHANGETABLE(VERSION ...)SYS_CHANGE_VERSION pro řádek specifikovaný @product id. CHANGETABLE(CHANGES ...) může získat stejné informace, ale to by bylo méně efektivní. Pokud je hodnota SYS_CHANGE_VERSION řádku větší než hodnota @last_sync_version, dojde ke konfliktu. Pokud dojde ke konfliktu, řádek se neaktualizuje. Vyžaduje se kontrola ISNULL(), protože pro řádek nemusí být k dispozici žádné informace o změnách. Neexistují žádné informace o změnách, pokud se řádek neaktualizoval od povolení sledování změn nebo od vyčištění informací o změnách.

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

Následující kód může zkontrolovat aktualizovaný počet řádků a identifikovat další informace o konfliktu.

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

Nastavení informací o kontextu

WITH CHANGE_TRACKING_CONTEXT Pomocí klauzule může aplikace ukládat informace o kontextu společně s informacemi o změnách. Tyto informace lze pak získat ze sloupce SYS_CHANGE_CONTEXT, který vrátí CHANGETABLE(CHANGES ...).

Kontextové informace se obvykle používají k identifikaci zdroje změn. Pokud je možné identifikovat zdroj změny, mohou být informace používány úložištěm dat, aby se zabránilo získání změn při opětovné synchronizaci.

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

Zajištění konzistentních a správných výsledků

Aplikace musí při ověřování hodnoty @last_sync_versionzvážit proces čištění . Důvodem je to, že data mohla být po CHANGE_TRACKING_MIN_VALID_VERSION() zavolání odebrána, ale před provedením aktualizace.

Měli byste použít izolaci na úrovni snímků a provést změny v rámci transakce probíhající ve snímku.

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

Poznámka

Je možné, že řádek, který se aktualizuje v rámci transakce snímku, mohl být aktualizován v jiné transakci po zahájení transakce snímku. V tomto případě dojde ke konfliktu aktualizace izolace snímků, což povede k ukončení transakce. Pokud k tomu dojde, zkuste aktualizaci zopakovat. To pak povede ke zjištění konfliktu sledování změn a k žádné změně řádků nedojde.

Sledování změn a obnovení dat

Aplikace, které vyžadují synchronizaci, musí zvážit případ, kdy se databáze s povoleným sledováním změn vrátí ke starší verzi dat. K tomu může dojít po obnovení databáze ze zálohy, při přepnutí na asynchronní zrcadlení databáze, nebo když nastane selhání při přenášení protokolu. Tento problém ilustruje následující scénář:

1. Tabulka T1 je sledována a minimální platná verze tabulky T1 je 50.

2. Klientská aplikace synchronizuje data ve verzi 100 a získá informace o všech změnách mezi verzemi 50 a 100.

3. Další změny tabulky T1 se provádějí po verzi 100.

4. Ve verzi 120 došlo k chybě a správce databáze databázi obnoví se ztrátou dat. Po operaci obnovení tabulka obsahuje data až do verze 70 a minimální synchronizovaná verze je stále 50.

   To znamená, že synchronizované úložiště dat obsahuje data, která již v primárním úložišti dat neexistují.

5. T1 se mnohokrát aktualizuje. To aktualizuje aktuální verzi na 130.

6. Klientská aplikace se znovu synchronizuje a dodává poslední synchronizovanou verzi 100. Klient ověří toto číslo úspěšně, protože 100 je větší než 50.

   Klient získá změny mezi verzí 100 a 130. V tomto okamžiku klient neví, že změny mezi 70 a 100 nejsou stejné jako předtím. Data na klientovi a serveru se nesynchronují.

Pokud byla databáze obnovena do bodu po verzi 100, nedošlo by k žádným problémům se synchronizací. Klient a server by správně synchronizovali data během dalšího intervalu synchronizace.

Sledování změn neposkytuje podporu pro zotavení po ztrátě dat. Existují však dvě možnosti detekce těchto typů problémů se synchronizací:

• Uložte ID verze databáze na serveru a aktualizujte tuto hodnotu vždy, když se databáze obnoví nebo jinak ztratí data. Každá klientská aplikace uloží ID a každý klient bude muset toto ID ověřit při synchronizaci dat. Pokud dojde ke ztrátě dat, ID se nebudou shodovat a tak by klienti znovu inicializovali. Jednou nevýhodou je, že pokud ztráta dat nepřekračovala poslední synchronizovanou hranici, může klient provádět zbytečnou opětovnou inicializaci.

• Když se klient dotáže na změny, poznamenejte si číslo poslední synchronizační verze pro každého klienta na serveru. Pokud dojde k potížím s daty, poslední synchronizovaná čísla verzí by se neshodovala. To znamená, že je vyžadována opětovná inicializace.

Související obsah

• Sledování změn dat (SQL Server)
• O sledování změn (SQL Server)
• Správa řešení Change Tracking (SQL Server)
• Povolení a zakázání řešení Change Tracking (SQL Server)
• ZMĚNITELNÁ TABULKA (Transact-SQL)
• MINIMÁLNÍ_PLATNÁ_VERZE_CHANGE_TRACKING (Transact-SQL)
• CHANGE_TRACKING_CURRENT_VERSION (Transact-SQL)
• S KONTEXTEM_SLEDOVÁNÍ_ZMĚN (Transact-SQL)