Sdílet prostřednictvím

Průvodce správou a architekturou transakčních protokolů SQL Serveru

platí pro:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)databáze SQL v Microsoft Fabric

Každá databáze SQL Serveru má transakční protokol, který zaznamenává všechny transakce a změny databáze provedené jednotlivými transakcemi. Transakční protokol je důležitou součástí databáze a pokud dojde k selhání systému, může být transakční protokol nutný k tomu, aby se databáze vrátila do konzistentního stavu. Tato příručka obsahuje informace o fyzické a logické architektuře transakčního protokolu. Pochopení architektury může zlepšit efektivitu při správě transakčních protokolů.

Logická architektura transakčního protokolu

Transakční protokol SQL Serveru funguje logicky, jako by transakční protokol je řetězec záznamů protokolu. Každý záznam protokolu je identifikován pořadovým číslem protokolu (LSN). Každý nový záznam protokolu se zapíše na logický konec protokolu s LSN, který je vyšší než LSN záznamu před ním. Záznamy protokolu se ukládají v sériové sekvenci při jejich vytváření, aby pokud je LSN2 větší než LSN1, změna popsaná záznamem protokolu, na který odkazuje LSN2, došlo po změně popsané záznamem protokolu LSN1. Každý záznam protokolu obsahuje ID transakce, do které patří. Pro každou transakci jsou všechny záznamy protokolu přidružené k transakci jednotlivě propojeny v řetězu pomocí zpětných ukazatelů, které urychlují vrácení zpět transakce.

Základní struktura LSN je [VLF ID:Log Block ID:Log Record ID]. Další informace najdete v částech VLF a bloku protokolu.

Tady je příklad LSN: 00000031:00000da0:0001, kde 0x31 je ID VLF, 0xda0 je ID bloku protokolu a 0x1 je prvním záznamem protokolu v tomto bloku protokolu. Příklady LSN najdete ve výstupu zobrazení dynamické správy sys.dm_db_log_info a sloupec vlf_create_lsn si prohlédněte.

Záznamy protokolu pro úpravy dat zaznamenávají buď logickou operaci provedenou, nebo zaznamenávají před a po obrázcích upravených dat. Obrázek před provedením operace představuje kopii dat; image after je kopie dat po provedení operace.

Postup obnovení operace závisí na typu záznamu protokolu:

  • Protokolovaná logická operace

    • Pokud chcete logickou operaci posunout vpřed, operace se provede znovu.
    • Chcete-li vrátit zpět logickou operaci, provede se zpětná logická operace.

  • Obraz před a po zaznamenán

    • Pokud chcete operaci posunout vpřed, použije se následný obraz.
    • Chcete-li vrátit operaci zpět, použije se snímek před změnou.

V transakčním protokolu se zaznamenává mnoho typů operací. Mezi tyto operace patří:

  • Začátek a konec každé transakce.

  • Každá úprava dat (vložení, aktualizace nebo odstranění) Úpravy zahrnují změny uložených systémových procedur nebo příkazů DDL (Data Definition Language) do jakékoli tabulky, včetně systémových tabulek.

  • Každý rozsah a přidělení stránky nebo zrušení přidělení.

  • Vytvoření nebo vyřazení tabulky nebo indexu

Operace vrácení zpět se také protokolují. Každá transakce si v transakčním protokolu rezervuje místo, aby se zajistilo, že existuje dostatek prostoru protokolu pro podporu vrácení zpět, které je způsobeno explicitním příkazem vrácení zpět, nebo pokud dojde k chybě. Množství rezervovaného místa závisí na operacích provedených v transakci, ale obecně se rovná množství místa použitého k protokolování jednotlivých operací. Po dokončení transakce se uvolní toto rezervované místo.

Část souboru protokolu z prvního záznamu protokolu, který musí být k dispozici pro úspěšné vrácení zpět do posledního zapsaného záznamu protokolu, se nazývá aktivní část protokolu, aktivní protokol nebo konec protokolu. Toto je část protokolu, která se vyžaduje k úplnému obnovení databáze. Nikdy nelze zkrátit žádnou část aktivního protokolu. Pořadové číslo protokolu (LSN) tohoto prvního záznamu protokolu se označuje jako minimální obnovovací LSN (MinLSN). Další informace o operacích podporovaných transakčním protokolem naleznete v transakčním protokolu.

Rozdílové a protokolové zálohy posouvají obnovenou databázi na pozdější čas, který odpovídá vyššímu LSN.

Fyzická architektura transakčního protokolu

Transakční log databáze je mapován na jeden nebo více fyzických souborů. Soubor protokolu je koncepčně řetězec záznamů protokolu. Fyzicky je posloupnost záznamů protokolu uložena efektivně v sadě fyzických souborů, které implementují transakční protokol. Pro každou databázi musí existovat alespoň jeden soubor protokolu.

Soubory virtuálních protokolů (VLF)

Databázový systém SQL Server rozdělí každý fyzický soubor protokolu interně na několik virtuálních souborů protokolu (VLF). Soubory virtuálních protokolů nemají pevnou velikost a pro fyzický soubor protokolu neexistuje žádný pevný počet souborů virtuálních protokolů. Databázový stroj dynamicky zvolí velikost virtuálních souborů protokolu při vytváření nebo rozšiřování souborů protokolu. Databázový stroj se snaží udržovat několik virtuálních souborů. Velikost virtuálních souborů po rozšíření souboru protokolu je součet velikosti existujícího souboru protokolu a velikosti přírůstku nového souboru. Velikost nebo počet souborů virtuálních protokolů nelze nakonfigurovat ani nastavit správci.

Vytvoření souboru virtuálního protokolu

Vytvoření souboru virtuálního protokolu (VLF) se řídí touto metodou:

  • Pokud je další růst menší než 1/8 aktuální fyzické velikosti protokolu v SQL Serveru 2014 (12.x) a novějších verzích, vytvořte 1 VLF, který pokrývá velikost růstu.
  • Pokud je další přírůstek větší než 1/8 aktuální velikosti protokolu, použijte metodu z doby před rokem 2014, a to konkrétně:
    • Pokud je růst menší než 64 MB, vytvořte 4 VLF, které pokrývají velikost růstu (například pro růst 1 MB, vytvořte 4 VLF o velikosti 256 kB).
      • Ve službě Azure SQL Database a počínaje SQL Serverem 2022 (16.x) (všechny edice) se logika mírně liší. Pokud je růst menší nebo roven 64 MB, databázový stroj vytvoří pouze jeden VLF pro pokrytí velikosti růstu.
    • Pokud je růst z 64 MB až 1 GB, vytvořte 8 VLF, které pokrývají velikost růstu (například pro růst 512 MB, vytvořte 8 VLF velikosti 64 MB).
    • Pokud je růst větší než 1 GB, vytvořte 16 VLF, které pokrývají velikost růstu, například pro růst 8 GB, vytvořte 16 VLF o velikosti 512 MB).

Pokud se soubory protokolu zvětší do velké velikosti po malých přírůstcích, vedou k mnoha virtuálním souborům protokolu. To může zpomalit spouštění databáze, operace zálohování protokolů a obnovení a způsobit latenci transakční replikace/ CDC a opakování AlwaysOn. Naopak, pokud jsou soubory protokolu nastaveny na velkou velikost s několika nebo jen jedním přírůstkem, obsahují málo velmi velkých virtuálních log souborů. Další informace o správném odhadu požadované velikosti a nastavení automatického zvětšování transakčního protokolu najdete v části Doporučenísprávy velikosti souboru transakčního protokolu.

Doporučujeme vytvořit logovací soubory blízko požadované konečné velikosti, s přírůstky potřebnými k dosažení optimální distribuce VLF, a použít relativně velkou hodnotu growth_increment.

Informace o optimální distribuci protokolu VLF pro aktuální velikost transakčního protokolu najdete v následujících tipech:

  • Hodnota velikosti nastavená argumentem SIZEALTER DATABASE je počáteční velikost souboru protokolu.
  • Hodnota growth_increment (označovaná také jako hodnota automatického zvětšování), kterou FILEGROWTH argument ALTER DATABASE sady obsahuje, je množství místa přidaného do souboru při každém vyžadování nového místa.

Další informace o argumentech FILEGROWTH a SIZE argumentech ALTER DATABASE naleznete v tématu ALTER DATABASE (Transact-SQL) Možnosti souborů a skupin souborů.

Tip

Pokud chcete určit optimální distribuci VLF pro aktuální velikost transakčního protokolu všech databází v dané instanci, a požadovaný růst přírůstků k dosažení požadované velikosti, přečtěte si tento Fixing-VLFs skript na GitHubu.

Co se stane, když máte příliš mnoho VLF?

Během počátečních fází procesu obnovení databáze SQL Server zjistí všechny soubory VLF ve všech souborech transakčních protokolů a vytvoří seznam těchto souborů VLF. Tento proces může trvat dlouho v závislosti na počtu souborů VLF v konkrétní databázi. Čím více souborů VLF, tím déle proces probíhá. Databáze může skončit s velkým počtem VLF při častém automatickém nebo ručním zvětšování transakčního protokolu v malých přírůstcích. Když počet VLF dosáhne rozsahu několika stovek tisíc, můžete zaznamenat některé nebo většinu následujících příznaků:

  • Obnovení jedné nebo více databází trvá velmi dlouho během spouštění SQL Serveru.
  • Obnovení databáze trvá velmi dlouho.
  • Dokončení pokusů o připojení databáze trvá velmi dlouho.
  • Při pokusu o nastavení zrcadlení databáze se zobrazí chybové zprávy 1413, 1443 a 1479 označující časový limit.
  • Při pokusu o obnovení databáze narazíte na chyby související s pamětí, jako je 701.
  • U transakční replikace nebo zachytávání dat změn může docházet k významné latenci.

Když prozkoumáte protokol chyb SQL Serveru, můžete si všimnout, že před fází analýzy procesu obnovení databáze se stráví značné množství času. Například:

2022-05-08 14:42:38.65 spid22s Starting up database 'lot_of_vlfs'.
2022-05-08 14:46:04.76 spid22s Analysis of database 'lot_of_vlfs' (16) is 0% complete (approximately 0 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.

SQL Server navíc může protokolovat chybu MSSQLSERVER_9017 při obnovení databáze s velkým počtem souborů VLF:

Database %ls has more than %d virtual log files which is excessive. Too many virtual log files can cause long startup and backup times. Consider shrinking the log and using a different growth increment to reduce the number of virtual log files.

Další informace najdete v tématu MSSQLSERVER_9017.

Oprava databází s velkým počtem souborů VLF

Pokud chcete zachovat celkový počet souborů VLF v přiměřené výši, například maximálně několik tisíc, můžete obnovit soubor transakčního protokolu tak, aby obsahoval menší počet souborů VLF, a to provedením následujících kroků:

  1. Soubory transakčního protokolu zmenšete ručně.

  2. Pomocí následujícího skriptu T-SQL zvětšte soubory na požadovanou velikost ručně v jednom kroku:

    ALTER DATABASE <database name> MODIFY FILE (NAME='Logical file name of transaction log', SIZE = <required size>);

    Note

    Tento krok je také možný v aplikaci SQL Server Management Studio pomocí stránky vlastností databáze.

Po nastavení nového rozložení souboru transakčního protokolu s menším počtem souborů VLF zkontrolujte a proveďte potřebné změny v nastavení automatického zvětšování transakčního protokolu. Toto nastavení zajistí, že se soubor protokolu v budoucnu nebude setkávat se stejným problémem.

Než provedete některou z těchto operací, ujistěte se, že máte platnou obnovitelnou zálohu v případě, že narazíte na problémy později.

Chcete-li určit optimální distribuci VLF pro aktuální velikost transakčního protokolu všech databází v dané instanci a požadovaný růst přírůstků k dosažení požadované velikosti, můžete k opravě VLFs použít následující skript GitHubu.

Bloky protokolů

Každý protokol VLF obsahuje jeden nebo více bloků protokolu. Každý blok protokolu se skládá ze záznamů protokolu, které jsou zarovnány na hranici 4 bajtů. Blok protokolu je proměnlivý ve velikosti a je vždy celočíselným násobkem 512 bajtů (minimální velikost sektoru, kterou podporuje SQL Server), s maximální velikostí 60 KB. Blok protokolu je základní jednotka vstupně-výstupních operací pro protokolování transakcí.

Blok protokolu je kontejner záznamů protokolu, který se používá jako základní jednotka protokolování transakcí při zápisu záznamů protokolu na disk.

Každý blok protokolu v rámci VLF je jednoznačně vyřešen posunem bloku. První blok má vždy posun bloku, který odkazuje na prvních 8 kB ve VLF.

Obecně platí, že VLF je vždy vyplněn logickými bloky. Je možné, že poslední blok protokolu ve VLF je prázdný (například neobsahuje žádné záznamy protokolu). K tomu dochází, když se záznam protokolu, který se má zapsat, nevejde do aktuálního bloku protokolu a také když prostor vlevo na VLF není dostatečný k uložení tohoto záznamu protokolu. V tomto případě se vytvoří prázdný blok protokolu, který vyplní VLF. Záznam protokolu je vložen do prvního bloku na dalším VLF.

Cyklický charakter transakčního protokolu

Transakční log je cyklický soubor. Představte si například databázi s jedním fyzickým souborem protokolu rozděleným na čtyři soubory VLF. Po vytvoření databáze logický log začíná na začátku fyzického logu. Nové záznamy protokolu se přidávají na konec logického protokolu a rozšíří se směrem ke konci fyzického protokolu. Zkrácení protokolu uvolní všechny virtuální protokoly, jejichž záznamy se zobrazí před minimálním pořadovým číslem protokolu obnovení (MinLSN). MinLSN je pořadové číslo protokolu nejstarším záznamem protokolu, který je nutný pro úspěšné obnovení stavu databáze. Transakční protokol v ukázkové databázi by vypadal podobně jako v následujícím diagramu.

Diagram znázorňující rozdělení fyzického souboru protokolu do virtuálních protokolů

Když konec logického protokolu dosáhne konce fyzického souboru protokolu, nové záznamy protokolu se zabalí na začátek souboru fyzického protokolu.

Diagram znázorňující obtékání logického transakčního protokolu v souboru fyzického protokolu

Tento cyklus se opakuje do nekonečna, pokud konec logického protokolu nikdy nedosáhne jeho začátku. Pokud jsou staré záznamy protokolu zkráceny dostatečně často, aby vždy zanechaly dostatek prostoru pro všechny nové záznamy protokolu vytvořené prostřednictvím dalšího kontrolního bodu, protokol se nikdy úplně nezaplní. Pokud se ale konec logického protokolu dostane na začátek logického protokolu, dojde k jedné ze dvou věcí:

Pokud protokol obsahuje více fyzických souborů protokolu, logický protokol se před vrácením zpět na začátek prvního souboru fyzického protokolu přesune mezi všemi fyzickými soubory protokolu.

Important

Další informace o správě velikostí transakčního protokolu naleznete v tématu Správa velikosti souboru transakčního protokolu.

Zkrácení protokolu

Zkrácení protokolu je nezbytné, aby se zabránilo jeho zaplnění. Zkrácení protokolu odstraní neaktivní soubory virtuálních protokolů z logického transakčního protokolu databáze SQL Serveru a uvolní místo v logickém protokolu pro opakované použití v protokolu fyzických transakcí. Pokud se transakční protokol nikdy nezkrátí, zaplní nakonec veškeré místo na disku, které je přiděleno k souborům fyzického protokolu. Před zkrácením protokolu však musí dojít k operaci kontrolního bodu. Kontrolní bod zapíše aktuální změněné stránky v paměti ( označované jako špinavé stránky) a informace protokolu transakcí z paměti na disk. Při provádění kontrolního bodu se neaktivní část transakčního protokolu označí jako opakovaně použitelná. Poté může trunkování protokolu uvolnit neaktivní část. Další informace o kontrolních bodech naleznete v tématu Kontrolní body databáze (SQL Server).

Následující diagramy znázorňují transakční protokol před a po zkrácení. První diagram znázorňuje transakční protokol, který nebyl nikdy zkrácen. Aktuálně se v logickém protokolu používají čtyři virtuální log soubory. Logický protokol začíná před prvním souborem virtuálního protokolu a končí virtuálním protokolem 4. Záznam MinLSN je ve virtuálním logu 3. Virtuální protokol 1 a virtuální protokol 2 obsahují pouze neaktivní záznamy protokolu. Tyto záznamy lze zkrátit. Virtuální protokol 5 se stále nepoužívá a není součástí aktuálního logického protokolu.

Diagram znázorňující, jak se zobrazí transakční protokol před zkrácením

Druhý diagram znázorňuje, jak se protokol zobrazuje po zkrácení. Virtuální protokol 1 a virtuální protokol 2 byly uvolněny pro opakované použití. Logický protokol teď začíná na začátku virtuálního protokolu 3. Virtuální protokol 5 se stále nepoužívá a není součástí aktuálního logického protokolu.

Diagram znázorňující, jak se transakční protokol zobrazuje po zkrácení

Zkrácení protokolu probíhá automaticky po následujících událostech, s výjimkou zpoždění z nějakého důvodu:

  • Pod jednoduchým modelem obnovení, po kontrolním bodě.
  • V rámci úplného modelu obnovení nebo modelu hromadně protokolovaného obnovení po zálohování protokolu, pokud došlo k kontrolnímu bodu od předchozí zálohy.

Zkrácení protokolu může být zpožděno různými faktory. V případě dlouhého zpoždění zkrácení protokolu se může transakční protokol zaplnit. Informace naleznete v tématu Faktory, které můžou zpozdit zkrácení protokolu , a řešení potíží s úplným transakčním protokolem (chyba SQL Serveru 9002).

Transakční protokol s předběžným zápisem

Tato část popisuje roli protokolu předběžného zápisu transakcí při zaznamenávání modifikací dat na disk. SQL Server používá algoritmus protokolování před zápisem (WAL), který zaručuje, že před zápisem přidruženého záznamu protokolu na disk se na disk nezapisují žádné úpravy dat. Tím se zachová vlastnosti ACID pro transakci.

Další informace o WAL naleznete v tématu ZÁKLADY vstupně-výstupních operací SQL Serveru.

Abyste pochopili, jak funguje protokolování před zápisem ve vztahu k transakčnímu protokolu, je důležité vědět, jak se upravená data zapisuje na disk. SQL Server udržuje mezipaměť (nazývanou také jako vyrovnávací fond), do které čte datové stránky, když je třeba načíst data. Při změně stránky v mezipaměti vyrovnávací paměti není okamžitě zapsána zpět na disk; místo toho se stránka označí jako špinavá. Datová stránka může mít více než jeden logický zápis, než se fyzicky zapisuje na disk. Při každém logickém zápisu se do mezipaměti protokolu vloží záznam transakčního protokolu, který zaznamenává úpravy. Záznamy protokolu musí být zapsány na disk před odebráním přidružené špinavé stránky z vyrovnávací paměti a jejím zapsáním na disk. Proces kontrolního bodu pravidelně prohledává vyrovnávací paměť pro stránky ze zadané databáze a zapisuje všechny upravené stránky na disk. Kontrolní body šetří čas během pozdějšího obnovení vytvořením bodu, ve kterém jsou zaručeny, že všechny špinavé stránky byly zapsány na disk.

Zápis upravené datové stránky z mezipaměti vyrovnávací paměti na disk se nazývá vyprázdnění stránky. SQL Server má logiku, která brání vyprázdnění špinavé stránky před zápisem přidruženého záznamu protokolu. Záznamy protokolu se zapisují na disk při vyprázdnění vyrovnávací paměti protokolu. K tomu dochází vždy, když se transakce potvrdí nebo se zaplní vyrovnávací paměti protokolu.

Zálohy transakčních protokolů

Tato část obsahuje koncepty zálohování a obnovení (použití) transakčních protokolů. V rámci úplných a hromadně protokolovaných modelů obnovení je potřeba rutinní zálohování transakčních protokolů (zálohování protokolů) pro obnovení dat. Protokol můžete zálohovat, i když je spuštěné jakékoli úplné zálohování. Další informace o modelech obnovení najdete v tématu Zálohování a obnovení databází SQL Serveru.

Než budete moct vytvořit první zálohu protokolu, musíte vytvořit úplnou zálohu, například zálohu databáze nebo první v sadě záloh souborů. Obnovení databáze pomocí pouze záloh souborů se může stát složitým. Proto doporučujeme, abyste začali s úplným zálohováním databáze, až budete moct. Následně je nutné pravidelně zálohovat transakční protokol. To nejen minimalizuje vystavení ztráty práce, ale také umožňuje zkrácení transakčního protokolu. Transakční protokol se obvykle zkracuje po každém konvenčním zálohování protokolů.

Pokud chcete omezit počet záloh protokolů, které potřebujete obnovit, je nezbytné pravidelně zálohovat data. Můžete například naplánovat týdenní úplné zálohování databáze a denní rozdílové zálohování databází.

Při implementaci strategie obnovení uvažujte o požadované době obnovení (RTO) a cíli bodu obnovení (RPO) a konkrétně úplném a rozdílovém rytmu zálohování databáze.

Další informace o zálohách transakčních protokolů naleznete v tématu Zálohování transakčních protokolů (SQL Server).

Frekvence zálohování a obchodní požadavky

Měli byste provést dostatek častých záloh protokolů pro podporu vašich obchodních požadavků, konkrétně tolerance pro ztrátu práce, jako je například poškození úložiště protokolů.

Vhodná frekvence pro pořizování záloh protokolů závisí na vaší toleranci vůči expozici ztráty práce vyváženou tím, kolik záloh protokolů můžete ukládat, spravovat a potenciálně obnovit. Při implementaci strategie obnovení se zamyslete nad požadovaným cílem doby obnovení (RTO) a cílem bodu obnovení (RPO) a konkrétně o tempu zálohování protokolů.

Zálohování protokolů každých 15 až 30 minut může stačit. Pokud vaše firma vyžaduje minimalizaci vystavení ztráty práce, zvažte častější zálohování protokolů. Častější zálohování protokolů má tu další výhodu, že zvyšuje frekvenci zkracování protokolu, což vede k menším souborům protokolů.

Řetěz protokolů

Průběžná posloupnost záloh protokolů se nazývá řetěz protokolů. Řetěz protokolů začíná úplným zálohováním databáze. Nový řetěz protokolů se obvykle spouští pouze při prvním zálohování databáze nebo po přepnutí modelu obnovení z jednoduchého obnovení na úplné nebo hromadně protokolované obnovení. Pokud se při vytváření úplné zálohy databáze nerozhodnete přepsat existující sady záloh, stávající řetěz protokolů zůstane nedotčený. Pokud zůstane řetěz protokolů neporušený, můžete obnovit databázi z jakékoli úplné zálohy databáze v sadě médií, následované všemi následnými zálohami protokolů až do bodu obnovení. Bod obnovení může být konec poslední zálohy protokolu nebo konkrétního bodu obnovení v některém ze záloh protokolů. Další informace naleznete v tématu Zálohování transakčních protokolů (SQL Server).

Pokud chcete obnovit databázi až do bodu selhání, musí být řetěz protokolů nedotčený. To znamená, že nepřerušená posloupnost záloh transakčních protokolů musí být rozšířena až do bodu selhání. Kde se musí spustit tato posloupnost protokolů, závisí na typu záloh dat, které obnovujete: databázi, část nebo soubor. V případě databáze nebo částečné zálohy musí posloupnost záloh protokolů probíhat od konce databáze nebo částečné zálohy. U sady záloh souborů musí posloupnost záloh protokolů pocházet od začátku úplné sady záloh souborů. Další informace najdete v tématu Použití záloh transakčních protokolů (SQL Server).

Obnovení záloh protokolů

Obnovení zálohy protokolu vrátí změny, které byly zaznamenány v transakčním protokolu, aby se znovu vytvořil přesný stav databáze v době, kdy byla spuštěna operace zálohování protokolu. Při obnovování databáze budete muset obnovit zálohy protokolů, které byly vytvořeny po úplném zálohování databáze, kterou obnovíte, nebo od začátku první zálohy souborů, kterou obnovíte. Po obnovení nejnovějších dat nebo rozdílového zálohování je obvykle nutné obnovit řadu záloh protokolů, dokud nedosáhnete bodu obnovení. Pak databázi obnovíte. Tím se vrátí zpět všechny transakce, které byly neúplné při spuštění obnovení a přenese databázi do online režimu. Po obnovení databáze nemůžete obnovit žádné další zálohy. Další informace najdete v tématu Použití záloh transakčních protokolů (SQL Server).

Kontrolní body a aktivní část protokolu

Kontrolní body zapisují špinavé datové stránky z mezipaměti současné databáze na disk. Tím se minimalizuje aktivní část protokolu, kterou je potřeba zpracovat během úplného obnovení databáze. Během úplného obnovení se provádějí následující typy akcí:

  • Záznamy protokolů úprav, které nejsou zapsané na disk před tím, než se systém zastaví, se přenesou.
  • Všechny úpravy spojené s neúplnými transakcemi, jako jsou transakce, pro které neexistuje žádný COMMIT záznam nebo ROLLBACK záznam protokolu, se vrátí zpět.

Operace kontrolního bodu

Kontrolní bod provádí v databázi následující procesy:

  • Zapíše záznam do souboru protokolu a označí začátek kontrolního bodu.

  • Ukládá informace zaznamenané pro kontrolní bod v řetězu záznamů protokolu kontrolních bodů.

    Jednou z informací zaznamenaných v kontrolním bodu je pořadové číslo protokolu (LSN) prvního záznamu protokolu, který musí být k dispozici pro úspěšné vrácení do databáze. Tento LSN se nazývá Minimum Recovery LSN (MinLSN). Minimální hodnota minLSN:

    • LSN začátku kontrolního bodu.
    • LSN začátku nejstarší aktivní transakce.
    • LSN počátku nejstarší replikační transakce, která ještě nebyla doručena do distribuční databáze.

    Záznamy kontrolních bodů obsahují také seznam všech aktivních transakcí, které změnily databázi.

  • Pokud databáze používá jednoduchý model obnovení, označí pro opakované použití prostory, které předcházejí MinLSN.

  • Zapíše všechny špinavé protokoly a datové stránky na disk.

  • Zapíše záznam označující konec kontrolního bodu do souboru protokolu.

  • Zapíše LSN začátku tohoto řetězu na spouštěcí stránku databáze.

Aktivity, které způsobují kontrolní bod

Kontrolní body se vyskytují v následujících situacích:

  • Příkaz CHECKPOINT je explicitně proveden. Kontrolní bod se vyskytuje v aktuální databázi připojení.

  • V databázi se provádí minimálně protokolovaná operace; Například operace hromadného kopírování se provádí v databázi, která používá model obnovení Bulk-Logged.

  • Soubory databáze byly přidány nebo odebrány pomocí .ALTER DATABASE

  • Instance SQL Serveru je zastavena SHUTDOWN příkazem nebo zastavením služby SQL Server (MSSQLSERVER). Každá akce způsobí kontrolní bod v každé databázi v instanci SQL Serveru.

  • Instance SQL Serveru pravidelně generuje automatické kontrolní body v každé databázi, aby zkrátila dobu, po kterou by instance trvalo obnovení databáze.

  • Provede se záloha databáze.

  • Provede se aktivita vyžadující vypnutí databáze. K tomu může dojít v případě, AUTO_CLOSE že je ON tato možnost uzavřená a poslední uživatel se připojí k databázi. Dalším příkladem je změna možnosti databáze, která vyžaduje restartování databáze.

Automatické kontrolní body

Databázový stroj SQL Serveru generuje automatické kontrolní body. Interval mezi automatickými kontrolními body vychází z využitého místa protokolu a času uplynulého od posledního kontrolního bodu. Časový interval mezi automatickými kontrolními body může být vysoce proměnlivý a dlouhý, pokud je v databázi provedeno několik změn. K automatickým kontrolním bodům může také docházet často, pokud je změněno velké množství dat.

Pomocí možnosti konfigurace serveru intervalu obnovení můžete vypočítat interval mezi automatickými kontrolními body pro všechny databáze v instanci serveru. Tato možnost určuje maximální dobu, po která by databázový stroj měl použít k obnovení databáze během restartování systému. Databázový stroj odhaduje, kolik záznamů protokolu může zpracovat v intervalu obnovení během operace obnovení.

Interval mezi automatickými kontrolními body závisí také na modelu obnovení:

  • Pokud databáze používá úplný nebo hromadně protokolovaný model obnovení, vygeneruje se automatický kontrolní bod pokaždé, když počet záznamů protokolu dosáhne čísla, které databázový stroj odhadne, může zpracovat během doby zadané v možnosti intervalu obnovení.

  • Pokud databáze používá jednoduchý model obnovení, vygeneruje se automatický kontrolní bod pokaždé, když počet záznamů protokolu dosáhne nižších z těchto dvou hodnot:

    • Protokol je zaplněn na 70 procent.
    • Počet záznamů protokolu dosáhne takového počtu, který databázový engine odhadne, že může zpracovat během doby zadané v možnosti intervalu obnovení.

Informace o nastavení intervalu obnovení najdete v tématu Konfigurace serveru: Interval obnovení (min.).

Tip

Možnost -k rozšířeného nastavení SQL Serveru umožňuje správci databáze omezovat chování vstupně-výstupních operací kontrolních bodů na základě propustnosti subsystému vstupně-výstupních operací u některých typů kontrolních bodů. Možnost -k nastavení se vztahuje na automatické kontrolní body a všechny jinak neregulované kontrolní body.

Automatické kontrolní body zkrátí nepoužívaný oddíl transakčního protokolu, pokud databáze používá jednoduchý model obnovení. Pokud však databáze používá úplné nebo hromadně protokolované modely obnovení, protokol se nezkrátí automatickými kontrolními body. Další informace naleznete v transakčním protokolu.

Příkaz CHECKPOINT teď poskytuje volitelný argument checkpoint_duration, který určuje požadované časové období v sekundách, aby se kontrolní body dokončily. Další informace najdete v tématu CHECKPOINT.

Aktivní protokol

Část souboru protokolu z MinLSN na poslední zapsaný záznam protokolu se nazývá aktivní část protokolu nebo aktivní protokol. Toto je část protokolu, která se vyžaduje k úplnému obnovení databáze. Nikdy nelze zkrátit žádnou část aktivního protokolu. Všechny záznamy protokolu musí být zkráceny z částí protokolu před MinLSN.

Následující diagram znázorňuje zjednodušenou verzi protokolu ukončení transakce se dvěma aktivními transakcemi. Záznamy kontrolních bodů byly komprimovány do jednoho záznamu.

Diagram znázorňující protokol ukončení transakce se dvěma aktivními transakcemi a komprimovaným záznamem kontrolního bodu

LSN 148 je poslední záznam v transakčním protokolu. V době, kdy byl zpracováván zaznamenaný kontrolní bod v LSN 147, byl Tran 1 potvrzen a Tran 2 byla jediná aktivní transakce. Díky tomu je první záznam protokolu pro Tran 2 nejstarší záznam protokolu pro transakci aktivní v době posledního kontrolního bodu. LSN 142, počáteční záznam transakce pro Tran 2, tímto určí MinLSN.

Dlouhotrvající transakce

Aktivní protokol musí obsahovat všechny části všech nepotvrzených transakcí. Aplikace, která spustí transakci a nepotvrdí ji ani nevrátí zpět, zabrání databázovému systému v posunu MinLSN. Tato situace může způsobit dva typy problémů:

  • Pokud je systém vypnutý po provedení transakce s mnoha nepotvrzenými úpravami, fáze obnovení následného restartu může trvat mnohem déle než doba zadaná v možnosti interval obnovy.
  • Protokol může být velmi velký, protože protokol nejde zkrátit za MinLSN. K tomu dochází i v případě, že databáze používá jednoduchý model obnovení, ve kterém je transakční protokol zkrácen na každém automatickém kontrolním bodu.

Obnovení dlouhotrvajících transakcí a problémů popsaných v tomto článku se můžete vyhnout pomocí akcelerovaného obnovení databáze, funkce dostupná od SQL Serveru 2019 (15.x) a ve službě Azure SQL Database.

Transakce replikace

Agent Log Reader monitoruje transakční protokol každé databáze nakonfigurované pro transakční replikaci a kopíruje transakce označené pro replikaci z transakčního protokolu do distribuční databáze. Aktivní protokol musí obsahovat všechny transakce, které jsou označené pro replikaci, ale ještě nebyly doručeny do distribuční databáze. Pokud tyto transakce nejsou replikovány včas, mohou zabránit zkrácení protokolu. Další informace naleznete v tématu Transakční replikace.

Související obsah

  • Last updated on