Sdílet prostřednictvím

Transakční protokol

  • Článek

platí pro:SQL Server

Každá databáze SQL Serveru má transakční protokol, který zaznamenává všechny transakce a změny databáze provedené každou transakcí.

Transakční protokol je důležitou součástí databáze. Pokud dojde k selhání systému, potřebujete tento záznam k tomu, aby se vaše databáze vrátila do konzistentního stavu.

Varování

Tento protokol nikdy neodstraňovat ani nepřesouvat, pokud plně nerozumíte důsledkům.

Informace o architektuře a vnitřní struktuře transakčních protokolů najdete v průvodci správou a architekturou transakčního protokolu SQL Serveru .

Spropitné

Známé dobré body, ze kterých lze začít používat transakční protokoly během obnovení databáze, jsou vytvořeny kontrolními body. Další informace najdete v tématu Kontrolní body databáze (SQL Server).

Operace podporované transakčním protokolem

Transakční protokol podporuje následující operace:

  • Obnovení jednotlivých transakcí.
  • Obnovení všech neúplných transakcí při spuštění SQL Serveru
  • Postupné přetočení obnovené databáze, souboru, skupiny souborů nebo stránky do bodu selhání.
  • Podpora transakční replikace
  • Podpora řešení vysoké dostupnosti a zotavení po havárii: Skupiny dostupnosti AlwaysOn, zrcadlení databáze a přesouvání protokolů.

Obnovení jednotlivých transakcí

Pokud aplikace vydá příkaz ROLLBACK nebo pokud databázový stroj zjistí chybu, jako je ztráta komunikace s klientem, záznamy protokolu se použijí k vrácení změn provedených neúplnou transakcí.

Obnovení všech neúplných transakcí při spuštění SQL Serveru

Pokud server selže, mohou být databáze ponechány ve stavu, kdy se některé úpravy nikdy nezapisovaly z mezipaměti vyrovnávací paměti do datových souborů a v datových souborech můžou být některé úpravy neúplných transakcí. Když se spustí instance SQL Serveru, spustí obnovení každé databáze. Všechny změny zaznamenané v protokolu, které nemusí být zapsány do datových souborů, se přepošle. Všechny neúplné transakce nalezené v transakčním protokolu se pak vrátí zpět, aby se zajistilo zachování integrity databáze. Další informace naleznete v tématu Přehled obnovení a obnovy (SQL Server).

Posunutí obnovené databáze, souboru, skupiny souborů nebo stránky vpřed do bodu selhání

Po ztrátě hardwaru nebo selhání disku, které ovlivňuje databázové soubory, můžete databázi obnovit do bodu selhání. Nejprve obnovíte poslední úplnou zálohu databáze a poslední rozdílové zálohování databáze a potom obnovíte následnou sekvenci záloh transakčního protokolu do bodu selhání.

Při obnovování každé zálohy protokolu databázový stroj znovu obnoví všechny změny zaznamenané v protokolu, aby se všechny transakce předaly. Po obnovení poslední zálohy protokolu pak databázový stroj použije informace protokolu k vrácení všech transakcí, které nebyly v tomto okamžiku dokončeny. Další informace naleznete v tématu Přehled obnovení a zotavení (SQL Server).

Podpora transakční 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. Další informace naleznete v tématu Jak funguje transakční replikace.

Podpora řešení pro zajištění vysoké dostupnosti a zotavení po havárii

Pohotovostní serverová řešení, skupiny dostupnosti AlwaysOn, zrcadlení databáze a přesouvání protokolů, se do značné míry spoléhají na transakční protokol.

Ve scénáři skupin dostupnosti AlwaysOn se každá aktualizace databáze na primární replice okamžitě reprodukuje v samostatných kopiích databáze na všech sekundárních replikách. Primární replika odesílá každý záznam protokolu okamžitě do sekundárních replik, které aplikují příchozí záznamy protokolu na databáze s vysokou dostupností a průběžně posouvají protokol. Další informace najdete v tématu Always On instance clusteru s podporou převzetí služeb při selhání (SQL Server).

V scénáři přesouvání protokolůprimární server odesílá zálohy transakčních protokolů primární databáze do jednoho nebo více cílů. Každý sekundární server obnoví zálohy protokolů do místní sekundární databáze. Další informace naleznete v tématu o log shippingu (SQL Server).

Ve scénáři zrcadlení databáze je každá aktualizace hlavní databáze okamžitě reprodukována v samostatné úplné kopii databáze, tedy v zrcadlové databázi. Instance hlavního serveru odešle každý záznam protokolu okamžitě do instance zrcadlového serveru, který aplikuje příchozí záznamy protokolu na zrcadlenou databázi, a průběžně ho postupně postupně předává dál. Další informace viz Zrcadlení databáze (SQL Server).

Charakteristiky transakčního protokolu

Charakteristiky transakčního protokolu databázového stroje SQL Serveru:

  • Transakční protokol se implementuje jako samostatný soubor nebo sada souborů v databázi. Mezipaměť protokolových souborů se spravuje odděleně od mezipaměti pro datové stránky, což vede k jednoduchému, rychlému a robustnímu kódu v databázovém stroji SQL Serveru. Další informace naleznete v části fyzická architektura transakčního protokolu .

  • Formát záznamů protokolu a stránek není omezen tak, aby dodržoval formát datových stránek.

  • Transakční protokol lze implementovat v několika souborech. Soubory lze definovat tak, aby se automaticky rozšířily nastavením hodnoty FILEGROWTH pro záznam. Tím se snižuje potenciál výpadku místa v transakčním protokolu a zároveň snižuje režijní náklady na správu. Další informace naleznete v tématu ALTER DATABASE (Transact-SQL) možnosti souborů a skupin souborů.

  • Mechanismus opětovného použití místa v souborech protokolu je rychlý a má minimální vliv na propustnost transakcí.

Pro informace o architektuře transakčního protokolu a vnitřních aspektech najdete v příručce o architektuře a řízení transakčního protokolu SQL Serveru .

Zkrácení transakčního protokolu

Zkrácení protokolu uvolní místo v souboru protokolu pro opakované použití v transakčním protokolu. Musíte pravidelně zkrátit transakční protokol, aby se zabránilo vyplnění přiděleného prostoru. Několik faktorů může zpozdit zkrácení protokolu, takže je důležité sledovat jeho velikost. Některé operace je možné protokolovat minimálně, aby se snížil jejich dopad na velikost transakčního protokolu.

Zkrácení protokolu odstraní neaktivní soubory virtuálních protokolů (VLF) 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í, nakonec vyplní veškeré místo na disku přidělené fyzickým souborům protokolu.

Pokud se z nějakého důvodu nezpozdí zkrácení protokolu, dojde k zkrácení automaticky po následujících událostech:

  • Pod jednoduchým modelem obnovení, po kontrolním bodě.

  • Pokud v rámci úplného modelu obnovení nebo modelu hromadného protokolování obnovení došlo k kontrolnímu bodu od předchozí zálohy, dojde ke zkrácení po zálohování protokolu (pokud se nejedná o zálohu protokolu jen pro kopírování).

  • Při prvním vytvoření databáze pomocí úplného modelu obnovení se transakční protokol použije podle potřeby (podobně jako databáze pomocí jednoduchého modelu obnovení), až do doby, kdy vytvoříte úplnou zálohu databáze.

Další informace naleznete v tématu Faktory, které mohou zpozdit zkrácení protokolu, dále v tomto článku.

Zkrácení protokolu nezmenšuje velikost fyzického souboru protokolu. Chcete-li zmenšit fyzickou velikost souboru fyzického protokolu, musíte zmenšit soubor protokolu. Informace o zmenšení velikosti fyzického souboru protokolu naleznete v tématu Správa velikosti souboru transakčního protokolu. Mějte však na paměti faktory, které mohou zpozdit trunkaci protokolu. Pokud se po zmenšení protokolu znovu vyžaduje prostor úložiště, transakční protokol se znovu zvětší a tím se zvýší režijní náklady na výkon během operací zvětšování protokolů.

Faktory, které můžou zpozdit zkrácení protokolu

Pokud záznamy protokolu zůstávají aktivní po dlouhou dobu, je zkrácení transakčního protokolu zpožděné a transakční protokol se může zaplnit, jak jsme již zmínili dříve v tomto článku.

Důležitý

Informace o tom, jak reagovat na úplný transakční protokol, naleznete v tématu Řešení potíží s úplným transakčním protokolem (CHYBA SYSTÉMU SQL Server 9002).

Zkrácení protokolu může být zpožděno z různých důvodů. Chcete-li zjistit, co brání zkrácení protokolu, zadejte dotaz na sloupce log_reuse_wait a log_reuse_wait_desc zobrazení katalogu sys.databases. Následující tabulka popisuje hodnoty těchto sloupců.

hodnota log_reuse_wait hodnota log_reuse_wait_desc Popis
0 NOTHING V současné době existuje jeden nebo více opakovaně použitelných virtuálních protokolových souborů (VLFs).
1 CHECKPOINT Od posledního zkrácení protokolu nedošlo k žádnému kontrolnímu bodu nebo se hlavička protokolu ještě neposunula za soubor virtuálního protokolu (VLF) (všechny modely obnovení).

Toto je běžný důvod pro zpoždění trunkování protokolu. Pro více informací se podívejte na Kontrolní body databáze (SQL Server).
2 LOG_BACKUP Před tím, než může být transakční protokol zkrácen, je nutné vytvořit jeho zálohu. (Pouze úplné nebo hromadně protokolované modely obnovení)

Po dokončení dalšího zálohování protokolů může dojít k opakovanému použití některého místa v protokolu.
3 ACTIVE_BACKUP_OR_RESTORE Probíhá zálohování dat nebo obnovení (všechny modely obnovení).

Pokud zálohování dat brání zkrácení protokolu, může zrušení operace zálohování pomoct okamžitému problému.
4 ACTIVE_TRANSACTION Transakce je aktivní (všechny modely obnovení):

Na začátku zálohování protokolů může existovat dlouhotrvající transakce. V takovém případě může uvolnění místa vyžadovat další zálohování protokolů. Dlouhotrvající transakce brání zkrácení protokolu ve všech modelech obnovení, včetně jednoduchého modelu obnovení, pod kterým je transakční protokol obecně zkrácen na každém automatickém kontrolním bodu.

Transakce je odložena. odložené transakce je v podstatě aktivní transakce, jejíž vrácení zpět je blokováno z důvodu některého nedostupného prostředku. Informace o příčinách odložených transakcí a o tom, jak je přesunout mimo odložený stav, naleznete v tématu Deferred Transactions (SQL Server).

Dlouhotrvající transakce mohou také vyplnit tempdbtransakční protokol. tempdb se implicitně používá uživatelskými transakcemi pro interní objekty, jako jsou pracovní tabulky pro řazení, pracovní soubory pro hashování, kurzor pracovních tabulek a správa verzí řádků. I když transakce uživatele zahrnuje pouze čtení dat (SELECT dotazy), mohou být vytvořeny a použity interní objekty v rámci uživatelských transakcí. Pak lze vyplnit tempdb transakční protokol.
5 DATABASE_MIRRORING Zrcadlení databáze je pozastaveno nebo v režimu vysokého výkonu je zrcadlová databáze výrazně za hlavní databází. (Pouze úplný model obnovení).

Další informace naleznete v tématu Zrcadlení databáze (SQL Server).
6 REPLICATION Během transakční replikace se transakce relevantní pro publikace stále nedoručují do distribuční databáze. (Pouze model úplného obnovení)

Informace o transakční replikaci naleznete v tématu SQL Server Replication.
7 DATABASE_SNAPSHOT_CREATION Vytváří se snímek databáze (všechny modely obnovení).

Jedná se o běžnou záležitost a obvykle krátkodobou příčinu opožděného zkrácení logu protokolu.
8 LOG_SCAN Probíhá kontrola protokolu (všechny modely obnovení).

Jedná se o běžnou a obvykle krátkodobou příčinu opožděného zkracování protokolu.
9 AVAILABILITY_REPLICA Sekundární replika skupiny dostupnosti aplikuje transakční logy této databáze na příslušnou sekundární databázi. (Pouze úplný model obnovení).

Další informace najdete v tématu Co je skupina dostupnosti AlwaysOn?.
10 - Pouze pro interní použití
11 - Pouze pro interní použití
12 - Pouze pro interní použití
13 OLDEST_PAGE Pokud je databáze nakonfigurovaná tak, aby používala nepřímé kontrolní body, může být nejstarší stránka databáze starší než kontrolní bod pořadové číslo protokolu (LSN). V tomto případě může nejstarší stránka zpozdit zkrácení protokolu (všechny modely obnovení).

Informace o nepřímých kontrolních bodech naleznete v tématu databázové kontrolní body (SQL Server).
14 OTHER_TRANSIENT Tato hodnota se aktuálně nepoužívá.
16 XTP_CHECKPOINT Je potřeba provést kontrolní bod OLTP In-Memory. U tabulek optimalizovaných pro paměť se provede automatický kontrolní bod, když se soubor protokolu transakcí od posledního kontrolního bodu zvětší než 1,5 GB (zahrnuje tabulky optimalizované pro disk i paměť).

Další informace najdete v tématu Operace kontrolního bodu pro tabulky Memory-Optimized a proces protokolování a kontrolního procesu pro tabulky In-Memory optimalizované.

Operace, které se dají protokolovat minimálně

Minimální protokolování zahrnuje protokolování pouze informací potřebných k obnovení transakce bez podpory obnovení k určitému bodu v čase. Tento článek identifikuje operace, které jsou minimálně protokolovány v rámci hromadně protokolovaného modelu obnovení (stejně jako v rámci jednoduchého modelu obnovení, s výjimkou případů, kdy je spuštěné zálohování).

Minimální protokolování není podporováno pro tabulky optimalizované pro paměť.

V rámci celého modelu obnovení jsou všechny hromadné operace plně protokolovány. Můžete minimalizovat protokolování pro sadu hromadných operací tím, že dočasně přepnete databázi na model s hromadným protokolováním pro hromadné operace. Minimální protokolování je efektivnější než úplné protokolování a snižuje možnost rozsáhlé hromadné operace vyplňování dostupného prostoru transakčního protokolu během hromadné transakce. Pokud je však databáze poškozena nebo ztracena při minimálním protokolování, nemůžete databázi obnovit v okamžiku selhání.

Následující operace, které jsou plně protokolovány v rámci úplného modelu obnovení, jsou minimálně zaznamenány do jednoduchého a hromadně protokolovaného modelu obnovení:

  • Operace hromadného importu (bcp, BULK INSERTa INSERT). Další informace o tom, kdy se hromadný import do tabulky zaprotokoluje minimálně, najdete v tématu Požadavky pro minimální protokolování v hromadném importu.

    Pokud je povolena transakční replikace, operace BULK INSERT jsou plně protokolovány i v případě modelu obnovení s hromadným protokolováním.

  • SELECT – operace klauzule INTO.

    Pokud je povolena transakční replikace, SELECT INTO operace jsou plně protokolovány i v rámci modelu hromadného protokolování obnovení.

  • Částečné aktualizace datových typů s velkou hodnotou pomocí klauzule .WRITE v příkazu UPDATE při vkládání nebo připojování nových dat. Při aktualizaci existujících hodnot se nepoužívá minimální protokolování. Další informace o datových typech velkých hodnot naleznete v tématu Datové typy.

  • WRITETEXT příkazy a UPDATETEXT příkazy při vkládání nebo připojování nových dat do text, ntexta image datových typů sloupců. Při aktualizaci existujících hodnot se nepoužívá minimální protokolování.

    Varování

    Příkazy WRITETEXT a UPDATETEXT jsou zastaralé; nepoužívejte je v nových aplikacích.

  • Pokud je databáze nastavená na jednoduchý nebo hromadně protokolovaný model obnovení, některé operace DDL indexu se protokolují minimálně bez ohledu na to, jestli je operace spuštěna offline nebo online. Minimální protokolované indexové operace jsou následující:

    • operace CREATE INDEX (včetně indexovaných zobrazení).

    • Pro operaci ALTER INDEX REBUILD nebo DBCC DBREINDEX.

      Operace sestavení indexu používají minimální protokolování, ale může se zpozdit, když probíhá souběžné zálohování. Toto zpoždění je způsobeno požadavky na synchronizaci minimálně protokolovaných stránek fondu vyrovnávací paměti při použití jednoduchého nebo hromadně protokolovaného modelu obnovení.

      Varování

      Příkaz DBCC DBREINDEX je zastaralý, nepoužívejte ho v nových aplikacích.

    • DROP INDEX nové sestavení úložiště (pokud je to relevantní). Uvolnění stránky indexu během operace DROP INDEX je vždy plně protokolované.

Úkol Článek
Správa transakčního protokolu - Spravovat velikost souboru transakčního protokolu

- řešení potíží s úplným transakčním protokolem (chyba SQL Serveru 9002)
Zálohování transakčního protokolu (pouze úplný model obnovení) - Zazálohujte transakční protokol

- zálohování transakčního protokolu při poškození databáze (SQL Server)
Obnovení transakčního protokolu (pouze úplný model obnovení) - obnovení zálohy transakčního protokolu (SQL Server)

Související obsah