The Transaction Log (SQL Server) (Čeština)

  • 10/23/2019
  • 11 minutes to read
    • M
    • D
    • f
    • M
    • s
    • +8

Applies to: SQL Server (all supported versions)

Every SQL Server database has a transaction log that records all transactions and the database modifications made by each transaction.,

protokol transakcí je kritickou součástí databáze. Pokud dojde k selhání systému, budete potřebovat tento protokol, abyste vrátili databázi zpět do konzistentního stavu.

informace o architektuře protokolu transakcí a interních souborech naleznete v příručce architektura a správa protokolu transakcí serveru SQL Server.

varování

Tento protokol nikdy neodstraňujte ani nepohybujte, pokud plně nerozumíte důsledkům tohoto postupu.

Tip

Známé dobré body, od kterého se začíná uplatňovat protokoly transakcí během obnovy databáze jsou vytvářeny kontrolní body., Další informace naleznete v databázových kontrolních bodech (SQL Server).

Operace podporované z protokolu transakcí

transakci protokolu podporuje následující operace:

  • Jednotlivé transakce, zotavení.
  • obnovení všech neúplných transakcí při spuštění SQL Serveru.
  • Rolling obnovenou databázi, soubor, filegroup, nebo stránku vpřed do bodu selhání.
  • podpora transakční replikace.
  • podpora vysoké dostupnosti a řešení pro obnovu po havárii: vždy na skupinách dostupnosti, zrcadlení databáze a odeslání protokolu.,

Jednotlivé transakce, zotavení

Pokud problémy s aplikací ROLLBACK prohlášení, nebo pokud Database Engine detekuje chybu jako ztráta komunikace s klientem, log záznamy jsou použity k vrátit zpět změny provedené neúplné transakce.,

Obnovení všechny neúplné transakce při SQL Server je spuštěna

Pokud server selže, databáze mohou být ponechány ve stavu, kdy některé změny nebyly nikdy zapsány z vyrovnávací paměti vyrovnávací paměti do datových souborů, a tam může být některé změny z neúplné transakce v datové soubory. Když je spuštěna instance SQL Serveru, spustí obnovu každé databáze. Každá změna zaznamenaná v protokolu, která nemusí být zapsána do datových souborů, je vrácena dopředu., Každá neúplná transakce nalezená v protokolu transakcí je poté vrácena zpět, aby se zajistilo zachování integrity databáze. Další informace naleznete v přehledu obnovení a obnovení (SQL Server).

Rolling obnovené databáze, soubor, skupina souborů nebo stránka vpřed až k bodu selhání

Po ztrátě hardwaru nebo selhání disku ovlivňuje soubory databáze, můžete obnovit databázi až k bodu selhání., Nejprve obnovíte Poslední úplnou zálohu databáze a poslední zálohu databáze diferenciálu a poté obnovíte následnou sekvenci záloh protokolu transakcí do bodu selhání.

při obnovení každé zálohy protokolu databázový stroj znovu provede všechny úpravy zaznamenané v protokolu, aby předal všechny transakce. Když poslední zálohy protokolu obnovení Databáze Motor, pak používá informace z protokolu chcete-li vrátit všechny transakce, které nebyly úplné. Další informace naleznete v přehledu 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 zkopíruje transakce označené pro replikaci z protokolu transakcí do distribuční databáze. Pro více informací se podívejte, jak funguje transakční replikace.

Podpora vysoké dostupnosti a disaster recovery řešení

pohotovostní režim-server řešení, a to Vždy Na skupiny dostupnosti, zrcadlení databáze a protokolu dopravy, spoléhají na protokolu transakce.,

ve scénáři always On availability groups je každá aktualizace databáze, primární replika, okamžitě reprodukována v samostatných, plných kopiích databáze, sekundárních replikách. Primární replika okamžitě odešle každý záznam záznamu do sekundárních replik, které aplikují záznamy příchozích záznamů do databází skupiny dostupnosti a neustále je posouvají dopředu. Další informace naleznete vždy v instancích clusteru Failover

ve scénáři odeslání protokolu, primární server odešle aktivní protokol transakcí primární databáze do jednoho nebo více destinací., Každý sekundární server obnoví protokol do místní sekundární databáze. Pro více informací, viz O Log lodní.

ve scénáři zrcadlení databáze je každá aktualizace databáze, hlavní databáze, okamžitě reprodukována v samostatné plné kopii databáze, zrcadlové databáze. Instance hlavního serveru odešle každý záznam protokolu okamžitě na instanci mirror server, který aplikuje záznamy příchozího protokolu do databáze mirror a neustále je posouvá dopředu. Pro více informací viz zrcadlení databáze.,

protokolu Transakcí vlastnosti

Vlastnosti Databázového stroje SQL Server transaction log:

  • protokol transakce je realizována jako samostatný soubor nebo sadu souborů v databázi. Mezipaměť protokolu je spravována odděleně od vyrovnávací paměti pro datové stránky, což má za následek jednoduchý, rychlý a robustní kód v databázovém systému SQL Server. Další informace naleznete ve fyzické architektuře protokolu transakcí.

  • formát záznamů a stránek protokolu není omezen na Formát datových stránek.,

  • protokol transakcí lze implementovat do několika souborů. Soubory lze definovat pro automatické rozbalení nastavením hodnotyFILEGROWTH pro protokol. To snižuje potenciál vyčerpání místa v protokolu transakcí a současně snižuje administrativní režii. Pro více informací, viz ALTER DATABASE (Transact-SQL) soubor a možnosti Filegroup.

  • mechanismus pro opětovné použití prostoru v souborech protokolu je rychlý a má minimální vliv na propustnost transakcí.,

informace o architektuře protokolu transakcí a interních stránkách naleznete v příručce architektura a správa protokolu transakcí serveru SQL Server.

zkrácení protokolu transakcí

zkrácení protokolu uvolní místo v souboru protokolu pro opětovné použití protokolem transakcí. Musíte pravidelně zkrátit protokol transakcí, aby nedošlo k vyplnění přiděleného prostoru. Několik faktorů může oddálit zkrácení protokolu, takže je důležité sledovat velikost protokolu. Některé operace mohou být minimálně zaznamenány, aby se snížil jejich dopad na velikost protokolu transakcí.,

zkrácení protokolu odstraní neaktivní soubory virtuálního protokolu (VLFs) z logického transakčního protokolu databáze serveru SQL a uvolní místo v logickém protokolu pro opětovné použití fyzickým protokolem transakcí. Pokud protokol transakcí není nikdy zkrácen, nakonec vyplní veškeré místo na disku přidělené fyzickým souborům protokolu.

aby nedošlo k vyčerpání místa, pokud z nějakého důvodu není zkrácení protokolu zpožděno, dochází ke zkrácení automaticky po následujících událostech:

  • pod jednoduchým modelem obnovy po kontrolním stanovišti.,
  • v rámci modelu úplné obnovy nebo hromadně zaznamenaného modelu obnovy, pokud 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 pouze pro kopírování).

Další informace naleznete v faktorech, které mohou oddálit zkrácení protokolu, později v tomto tématu.

Poznámka

zkrácení protokolu nesnižuje velikost fyzického souboru protokolu. Chcete-li snížit fyzickou velikost fyzického souboru protokolu, musíte soubor protokolu zmenšit. Informace o zmenšení velikosti souboru fyzického protokolu naleznete v části Správa velikosti souboru protokolu transakcí.,
Mějte však na paměti faktory, které mohou oddálit zkrácení protokolu. Pokud je úložný prostor vyžadován znovu po zmenšení protokolu, protokol transakcí znovu poroste a tím zavedete výkonovou režii během operací růstu protokolu.

faktory, které mohou oddálit zkrácení protokolu

Když záznamy protokolu zůstávají aktivní po dlouhou dobu, zkrácení protokolu transakcí je zpožděno a protokol transakcí se může naplnit, jak jsme již zmínili v tomto dlouhém tématu.,

důležité

informace o tom, jak reagovat na úplný protokol transakcí, viz řešení problémů s úplným protokolem transakcí (chyba serveru SQL 9002).

opravdu, zkrácení protokolu může být zpožděno z různých důvodů. Zjistěte, co, pokud něco, brání zkrácení protokolu dotazem na sloupce log_reuse_wait a log_reuse_wait_desc systému sys.zobrazení katalogu databází. Následující tabulka popisuje hodnoty těchto sloupců.,

11

12

td>

log_reuse_wait hodnota log_reuse_wait_desc hodnota Popis
0 nic v současné době existuje jeden nebo více opakovaně použitelných souborů virtuálního protokolu (vlfs).
1 PPC Žádné kontrolní bod došlo od posledního přihlášení zkrácení, nebo vedoucí protokolu dosud pohyboval mimo virtuální soubor protokolu (VLF). (Všechny modely obnovy)
Toto je rutinní důvod pro zpoždění zkrácení protokolu., Další informace naleznete v databázových kontrolních bodech (SQL Server).
2 LOG_BACKUP před zkrácením protokolu transakcí je nutná záloha protokolu. (Pouze plné nebo hromadně zaznamenané modely obnovy)
po dokončení další zálohy protokolu může být některé místo protokolu znovu použitelné.
3 ACTIVE_BACKUP_OR_RESTORE probíhá zálohování dat nebo obnovení (všechny modely obnovy).
Pokud zálohování dat brání zkrácení protokolu, zrušení operace zálohování může pomoci okamžitému problému.,
4 ACTIVE_TRANSACTION transakce je aktivní (všechny modely obnovy):
long-running transaction může existovat na začátku protokolu zálohování. V takovém případě může uvolnění místa vyžadovat další zálohu protokolu. Všimněte si, že dlouhodobé transakce zabraňují zkrácení protokolu u všech modelů obnovy, včetně jednoduchého modelu obnovy, podle kterého je protokol transakcí obecně zkrácen na každém automatickém kontrolním stanovišti.
transakce je odložena., Odložená transakce je účinně aktivní transakce, jejíž vrácení je zablokováno kvůli nějakému nedostupnému zdroji. Informace o příčinách odložených transakcí a o tom, jak je přesunout z odloženého stavu, naleznete v části odložené transakce (SQL Server).
dlouhodobé transakce mohou také zaplnit protokol transakcí tempdb. Tempdb se implicitně používá uživatelskými transakcemi pro interní objekty, jako jsou pracovní tabulky pro třídění, pracovní soubory pro hashování, pracovní tabulky kurzoru a verzování řádků., I když uživatelská transakce zahrnuje pouze čtení dat (SELECT dotazy), interní objekty mohou být vytvořeny a použity v rámci uživatelských transakcí. Poté lze vyplnit protokol transakcí tempdb.
5 DATABASE_MIRRORING zrcadlení databáze je pozastaveno nebo v režimu s vysokým výkonem je zrcadlová databáze výrazně za hlavní databází. (Pouze model úplné obnovy)
Další informace naleznete v zrcadlení databáze (SQL Server).,
6 REPLIKACE Během transakční replikace, transakce relevantní publikace jsou stále nedoručené do distribuční databáze. (Pouze model úplné obnovy)
informace o transakční replikaci viz replikace serveru SQL.
7 DATABASE_SNAPSHOT_CREATION vytváří se databázový snímek. (Všechny modely obnovy)
jedná se o rutinní a obvykle stručnou příčinu opožděného zkrácení protokolu.
8 LOG_SCAN dochází ke skenování protokolu., (Všechny modely obnovy)
jedná se o rutinní a obvykle stručnou příčinu opožděného zkrácení protokolu.
9 DOSTUPNOST_REPLICA sekundární replika skupiny dostupnosti aplikuje záznamy o transakcích této databáze na odpovídající sekundární databázi. (Full recovery model)
Další informace naleznete v přehledu vždy o skupinách dostupnosti (SQL Server).,
10 pouze pro interní použití
pouze pro interní použití
pro interní použití pouze
13 oldest_page pokud je databáze nakonfigurována pro použití nepřímých kontrolních bodů, nejstarší stránka v databázi může být starší než číslo sekvence kontrolních bodů (LSN). V tomto případě může nejstarší stránka oddálit zkrácení protokolu. (Všechny modely obnovy)
informace o nepřímých kontrolních bodech viz kontrolní body databáze (SQL Server).,
14 OTHER_TRANSIENT tato hodnota se v současné době nepoužívá.
16 XTP_CHECKPOINT je třeba provést kontrolní bod OLTP v paměti.U tabulek optimalizovaných pro paměť se provede automatický kontrolní bod, když se soubor protokolu transakcí zvětší než 1.,5 GB od posledního kontrolního bodu (zahrnuje jak tabulky založené na disku, tak tabulky optimalizované pro paměť)
Pro více informací viz kontrolní bod operace pro tabulky optimalizované pro paměť a (https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/)

operace, které lze minimálně zaznamenávat

minimální protokolování zahrnuje protokolování pouze informací, které jsou potřebné k obnovení transakce bez podpory obnovení bodu v čase., Toto téma identifikuje operace, které jsou minimálně přihlášeny pod modelem obnovy s hromadným přihlášením (stejně jako pod jednoduchým modelem obnovy, s výjimkou případů, kdy je spuštěna záloha).

Poznámka

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

Poznámka

pod modelem úplné obnovy jsou všechny hromadné operace plně zaznamenány. Můžete však minimalizovat protokolování pro sadu hromadných operací přechodem databáze na volně ložený model obnovení dočasně pro hromadné operace.,Minimální protokolování je efektivnější než úplné protokolování a snižuje možnost velkého rozsahu, hromadné operace plnění k dispozici protokolu transakcí prostor při hromadné transakce. Pokud je však databáze poškozena nebo ztracena, když je v platnosti minimální protokolování, nemůžete databázi obnovit do bodu selhání.

následující operace, které jsou plně zaznamenány pod modelem úplné obnovy, jsou minimálně zaznamenány pod jednoduchým a volně loženým modelem obnovy:

  • hromadné importní operace (bcp, BULK INSERT a INSERT… VYBRAT)., Pro více informací o tom, kdy je hromadný import do tabulky minimálně přihlášen, viz předpoklady pro minimální přihlášení hromadného importu.

Když transakční replikace je povolena, BULK INSERT operace jsou plně zaznamenány i pod Zaznamenána Hromadné model obnovení.

  • SELECT INTO operations.

je-li povolena transakční replikace,SELECT INTO operace jsou plně zaznamenány i pod hromadně zaznamenaným modelem obnovy.,

  • částečné aktualizace datových typů s velkou hodnotou pomocí klauzule .WRITE v prohlášení o aktualizaci při vkládání nebo připojování nových dat. Všimněte si, že při aktualizaci stávajících hodnot se nepoužívá minimální protokolování. Pro více informací o velkých datových typů hodnot, viz datové typy (Transact-SQL).

  • WRITETEXT a UPDATETEXT při vložení nebo přidání nových dat do text, ntext a image typ dat sloupce. Všimněte si, že při aktualizaci stávajících hodnot se nepoužívá minimální protokolování.,

    varování

    WRITETEXT aUPDATETEXT příkazy jsou zastaralé; nepoužívejte je v nových aplikacích.

  • Pokud je databáze nastavena na jednoduchý nebo volně ložený model obnovení, jsou některé operace index DDL minimálně zaznamenány, zda je operace provedena offline nebo online. Minimálně zaznamenané indexové operace jsou následující:

    • vytvořit indexové operace (včetně indexovaných zobrazení).

    • alter index REBUILD nebo DBCC DBREINDEX operace.,

      varování

      příkazDBCC DBREINDEX je zastaralý; nepoužívejte jej v nových aplikacích.

      Poznámka

      operace sestavení indexu používají minimální protokolování, ale mohou být zpožděny při souběžném provádění zálohy. Toto zpoždění je způsobeno požadavky na synchronizaci minimálně přihlášených stránek fondu vyrovnávací paměti při použití jednoduchého nebo hromadně zaznamenaného modelu obnovení.

    • DROP INDEX New heap rebuild (pokud je to možné). Dealokace indexové stránky během operace DROP INDEX je vždy plně zaznamenána.,n databáze je poškozena (SQL Server)

    obnovení protokolu transakcí (Model úplné obnovy)

    • obnovení zálohy protokolu transakcí (SQL Server)

    Viz také

    SQL Server Transaction Log Architecture and Management Guide
    control Transaction trvanlivost
    předpoklady pro minimální protokolování hromadného importu
    zálohování a obnovení databází SQL Server
    obnovení a obnovení přehledu (SQL Server)
    databázové kontrolní body (SQL Server)
    zobrazit nebo změnit vlastnosti databáze
    recovery models (SQL Server)
    Transaction Log backups (SQL Server)
    sys.,dm_db_log_info (Transact-SQL)
    sys. dm_db_log_space_usage (Transact-SQL)

Leave a Comment