Sdílet prostřednictvím

Transakční protokol

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 protokol, aby se 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 fyzické a logické architektuře transakčního protokolu najdete v průvodci správou a architekturou transakčního protokolu SQL Serveru.

Spropitné

Kontrolní body vytvářejí známé dobré body, ze kterých se mají začít používat transakční protokoly během obnovení databáze. 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 obnovení (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 obnovení (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 naleznete v tématu 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ěť protokolů se spravuje odděleně od mezipaměti vyrovnávací paměti pro datové stránky. Toto oddělení vede k jednoduchému, rychlému a robustnímu kódu v databázovém stroji SQL Serveru. Další informace naleznete v tématu 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 můžete nakonfigurovat tak, aby se automaticky rozbalily nastavením FILEGROWTH hodnoty protokolu. Tato konfigurace snižuje potenciál pro nedostatek místa v transakčním protokolu současně, což snižuje administrativní režii. Další informace naleznete v tématu ALTER DATABASE (Transact-SQL) soubor a možnosti skupiny souborů.

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

Informace o fyzické a logické architektuře transakčního protokolu najdete v průvodci správou a architekturou 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é zaprotokolovat minimálně, aby se snížil jejich vliv 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, která používá úplný model 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 ale na paměti faktory, které můžou zpozdit zkrácení 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 během operací zvětšování protokolů zvýší režijní náklady na výkon.

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

Pokud záznamy protokolu zůstávají aktivní po dlouhou dobu, zkrácení transakčního protokolu je zpožděné a transakční protokol se může vyplnit, jak je popsáno výše 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 souborů virtuálních protokolů (VLFs).
1 CHECKPOINT Od posledního zkrácení protokolu nedošlo k žádnému kontrolnímu bodu nebo se hlavička protokolu ještě nepřesunula za soubor virtuálního protokolu (VLF). (Všechny modely obnovení.)

Tento scénář je běžný důvod zpoždění zkrácení protokolu. Další informace najdete v tématu 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, najdete v tématu Odložené transakce (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 úplný model obnovení.)

Informace o transakční replikaci najdete v tématu Replikace SYSTÉMU SQL Server.
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á prohledávání protokolu. (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.
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 takovém 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 automatický kontrolní bod použije, když se soubor transakčního protokolu od posledního kontrolního bodu zvětší 1,5 GB. (Zahrnuje tabulky optimalizované pro disk i paměť.)

Další informace najdete v tématu Operace kontrolního bodu pro tabulky optimalizované pro paměť a protokolování a proces kontrolního bodu pro tabulky optimalizované pro paměť.

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 modelu hromadného protokolování obnovení (a také v rámci jednoduchého modelu obnovení, s výjimkou případů, kdy je spuštěná záloha).

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, BULK INSERT operace jsou plně protokolovány i v rámci modelu hromadného protokolování obnovení.

  • 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 příkazy 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 jsou minimálně protokolovány, ať už je operace spuštěna offline nebo online. Minimální protokolované indexové operace jsou:

    • 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ůžou být zpožděné, pokud 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í). Přidělení stránky indexu DROP INDEX během operace je vždy plně zaprotokolováno.

Úkol Článek
Správa transakčního protokolu Správa velikosti 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í) Zálohování transakčního protokolu

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

  • Last updated on