Zrychlené obnovení databáze

platí pro: SQL Server 2019 (15.x) a novější verze Azure SQL DatabaseAzure SQL Managed InstanceSQL Database v Microsoft Fabric

Zrychlené obnovení databáze (ADR) zlepšuje dostupnost databáze, zejména v případě dlouhotrvajících transakcí, tím, že přepracuje proces obnovení databázového stroje.

ADR byl zaveden v SQL Serveru 2019 (15.x) a vylepšen v SQL Serveru 2022 (16.x). ADR je k dispozici také ve službě Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (pouze vyhrazený fond SQL) a v Databázi SQL v Microsoft Fabric.

Poznámka

Služba ADR je vždy povolena v Azure SQL Database, Azure SQL Managed Instance a v SQL Database v prostředí Fabric.

Tento článek obsahuje přehled ADR. Pokud chcete pracovat s ADR, projděte si Správa zrychleného obnovení databáze.

Další informace o transakčním protokolu a obnovení databáze naleznete v tématu Architektura a správa transakčních protokolů SQL Serveru a Přehled obnovení a obnovy (SQL Server).

Přehled

Hlavními výhodami ADR jsou:

• rychlé a konzistentní obnovení databáze

  Dlouhotrvající transakce nemají vliv na celkovou dobu obnovení, což umožňuje rychlé a konzistentní obnovení databáze bez ohledu na počet aktivních transakcí v systému nebo jejich velikosti.

• okamžité zrušení transakcí

  Vrácení transakce je okamžité bez ohledu na čas, kdy byla transakce aktivní, nebo počet provedených aktualizací.

• agresivní zkrácení protokolu

  Transakční protokol je agresivně zkrácen, a to i v přítomnosti aktivních dlouhotrvajících transakcí, což brání tomu, aby se zvětšoval mimo kontrolu.

Tradiční proces obnovení databáze

Bez ADR se obnovení databáze řídí modelem obnovení ARIES a skládá se ze tří fází, které jsou ilustrovány a podrobněji vysvětleny v následujícím diagramu:

• fáze analýzy

  Databázový stroj provede sekvenční prohledání transakčního protokolu od začátku posledního úspěšného kontrolního bodu (nebo nejstarší číslo sekvence protokolu pro „dirty page“ (LSN)) až do konce, za účelem určení stavu každé transakce v době, kdy se stroj zastavil.

• Opakování fáze

  Databázový stroj provede přesměrovou kontrolu transakčního protokolu od nejstarší nepotvrzené transakce na konec. Tento proces znovu provede všechny před havárií potvrzené operace, aby obnovil databázi do jejího stavu v době pádu systému.

• fáze vrácení zpět

  Pro každou transakci, která byla aktivní v době pádu systému, databázový stroj prochází protokol zpět a vrací operace, které tato transakce provedla.

• Při tradičním procesu obnovení databáze může obnovení po chybovém ukončení trvat dlouhou dobu, pokud byla aktivní dlouhotrvající transakce.

  Doba obnovení databázového stroje z neočekávaného restartování je (zhruba) úměrná velikosti nejdelší aktivní transakce v systému v době chybového ukončení. Obnovení vyžaduje vrácení všech neúplných transakcí zpět. Požadovaná doba je úměrná práci, kterou transakce provedla, a času, kdy byla aktivní.

• Zrušení nebo vrácení zpět velké transakce může trvat dlouhou dobu, protože používá stejnou fázi obnovení zpět, jak je popsáno výše.

• Databázový stroj nemůže zkrátit transakční protokol, pokud existují dlouhotrvající transakce, protože odpovídající záznamy protokolu jsou potřeba pro procesy obnovení a vrácení zpět. V důsledku toho může transakční protokol růst velmi velký a spotřebovávat velké množství úložného prostoru.

Proces zrychleného obnovení databáze

ADR řeší předchozí problémy s tradičním modelem obnovení tím, že zcela přepracuje proces obnovení databázového stroje tak, aby:

• Proveďte konstantu doby obnovení, protože již není nutné prohledávat transakční protokol od začátku nejstarší aktivní transakce. V případě ADR se transakční protokol zpracovává pouze z posledního úspěšného kontrolního bodu (nebo nejstarší špinavé stránky LSN). V důsledku toho není doba obnovení ovlivněná dlouhotrvajícími transakcemi a obvykle je okamžitá.

• Minimalizujte požadovaný prostor transakčního protokolu, protože už není nutné uchovávat protokol pro celou transakci. V důsledku toho může být transakční protokol agresivně zkrácen vzhledem k vytváření kontrolních bodů a provádění záloh.

ADR na vysoké úrovni dosahuje rychlého obnovení databáze tím, že verzionuje všechny fyzické úpravy databáze a vrací zpět pouze neverzní operace, které jsou omezené a lze je vrátit zpět téměř okamžitě. Všechny transakce, které byly aktivní v době chybového ukončení, jsou označeny jako přerušené, a proto všechny verze vygenerované těmito transakcemi mohou být ignorovány souběžnými uživatelskými dotazy.

Proces obnovení ADR má stejné tři fáze jako tradiční proces obnovení. Jak tyto fáze fungují s ADR, je znázorněno v následujícím diagramu:

• fáze analýzy

  Tento proces zůstává stejný jako tradiční model obnovení s přidáním rekonstruování sekundárního logového proudu (SLOG) a kopírováním záznamů protokolu pro neverzované operace.

• Opět fáze

  Rozdělené do dvou subfází

  • Podfáze 1

    Obnovit z protokolu SLOG (nejstarší nepotvrzená transakce až do posledního kontrolního bodu). Opětovné provedení je rychlá operace, protože může být potřeba zpracovat pouze několik záznamů ze SLOG protokolu.

  • Podfáze 2

    Znovu z transakčního protokolu začíná z posledního úspěšného kontrolního bodu (místo nejstarší nepotvrzené transakce).

• fáze vrácení zpět

  Fáze vrácení zpět s ADR se téměř okamžitě dokončí pomocí SLOG k vrácení neverzovaných operací, zatímco pro trvalé úložiště verzí (PVS) se používá logické revrzní k provedení vrácení na úrovni jednotlivých řádků.

Vysvětlení zrychleného obnovení databáze najdete v tomto osmiminutových videu:

Součásti obnovení ADR

Čtyři klíčové komponenty ADR jsou:

• úložiště trvalých verzí (PVS)

  Trvalé úložiště verzí (PVS) je mechanismus databázového stroje pro zachování verzí řádků v samotné databázi místo v tradičním úložišti verzí v databázi tempdb. PVS umožňuje izolaci prostředků a zlepšuje dostupnost čitelných sekundárních souborů.

• Logické vrácení

  Logické vrácení je asynchronní proces zodpovědný za provádění vracení změn na úrovni řádků – poskytuje okamžité vrácení transakcí a zpětné vracení u všech verzovaných operací.

  • Sleduje všechny přerušené transakce.
  • Provádí obnovu pomocí PVS pro všechny uživatelské transakce.
  • Uvolní všechny zámky ihned po přerušení transakce.

• SLOG

  SLOG je sekundární protokolový proud v paměti, který ukládá protokolové záznamy pro neverzované operace (například zneplatnění mezipaměti metadat, získání zámků atd.). SLOG je:

  • Nízký objem a v paměti
  • Trvalé na disku během procesu kontrolního bodu
  • Pravidelné zkracování při potvrzování transakcí
  • Zrychluje předělání a vrácení zpracováním pouze ne verzovaných operací.
  • Umožňuje agresivní zkrácení transakčního protokolu zachováním pouze požadovaných záznamů protokolu.

• Čistič

  Čistič je asynchronní proces, který se pravidelně aktivuje a odstraní zastaralé verze řádků z PVS.

Úlohy, které využívají ADR

ADR je obzvláště přínosné pro úlohy, které mají:

• Dlouhotrvající transakce.
• Aktivní transakce, které způsobují, že se transakční protokol výrazně zvětšuje.
• Dlouhá období nedostupnosti databáze kvůli dlouhotrvajícímu obnovení (například z neočekávaného restartování služby nebo ručního vrácení transakcí zpět).

Osvědčené postupy pro ADR

• Vyhněte se zbytečným dlouhotrvajícím transakcím. I když ADR urychluje obnovení databáze i u dlouhotrvajících transakcí, tyto transakce mohou zpozdit vyčištění verze a zvýšit velikost PVS.

• Vyhněte se velkým transakcím, které zahrnují operace DDL. ADR používá mechanismus sekundárního protokolového proudu (SLOG) ke sledování DDL operací používaných při obnově. Protokol SLOG se používá pouze v době, kdy je transakce aktivní. SLOG je zaznamenán jako kontrolní bod, takže vyhýbání se velkým transakcím, které využívají SLOG, může zlepšit celkový výkon. Tyto scénáře můžou způsobit, že SLOG zabírá více místa:

  • Mnoho DDL se provádí v jedné transakci. Například v jedné transakci rychle vytváří a ruší dočasné tabulky.
  • Tabulka obsahuje velmi velký počet oddílů a indexů, které jsou změněny. Například operace DROP TABLE v takové tabulce by vyžadovala velkou rezervaci paměti SLOG, která by zpozdilo zkrácení transakčního protokolu a operace vrácení zpět/znovu. Jako alternativní řešení zahoďte indexy jednotlivě a postupně a pak tabulku vypusťte.

  Další informace o SLOG naleznete v tématu součásti obnovení ADR.

• Zabraňte nebo snižte nepotřebné přerušené transakce. Vysoká míra přerušení transakcí klade tlak na čistič PVS a snižuje výkon ADR. Přerušení může pocházet z vysoké míry zablokování, duplicitních klíčů, porušení omezení nebo vypršení časového limitu dotazu. Zobrazení dynamické správy sys.dm_tran_aborted_transactions zobrazuje všechny přerušené transakce v instanci databázového stroje. Sloupec nested_abort označuje, že transakce byla potvrzena, ale existují části, které byly ukončeny (například body uložení nebo vnořené transakce), což může také oddálit proces čištění PVS.

• Ujistěte se, že databáze má dostatek místa pro využití PVS. Pokud databáze nemá dostatek místa pro růst PVS, může selhat generování verzí ADR, což způsobí selhání příkazů DML.

• Pokud je povolená možnost ADR s úlohami náročnými na zápis, může se výrazně zvýšit rychlost generování transakčních protokolů, protože se protokolují verze řádků zapsané do PVS. To může zvýšit velikost záloh transakčních protokolů.

• Pokud používáte transakční replikaci, replikaci snímkůnebo zachycení změn dat (CDC), agresivní chování ADR při zkracování protokolu je deaktivováno, aby čtenář protokolu mohl sbírat změny z transakčního protokolu. Ujistěte se, že je transakční protokol dostatečně velký.

  Ve službě Azure SQL Database možná budete muset zvýšit úroveň služby nebo velikost výpočetních prostředků, abyste měli jistotu, že je pro potřeby všech vašich úloh k dispozici dostatečný prostor transakčního protokolu. Podobně ve službě Azure SQL Managed Instance možná budete muset zvýšit maximální velikost úložiště instance.

• Pro SQL Server izolujte úložiště verzí PVS ve skupině souborů v úložišti vyšší vrstvy, jako je například vysoce endové SSD nebo pokročilé SSD nebo trvalá paměť (PMEM), někdy označované jako paměť třídy úložiště (SCM). Další informace naleznete v tématu Změna umístění PVS na jinou skupinu souborů.

• V případě SQL Serveru monitorujte protokol chyb pro položky PreallocatePVS. Pokud jsou k dispozici položky PreallocatePVS, možná budete muset zvýšit ADR schopnost předalokovat stránky prostřednictvím úlohy na pozadí. Předběžné přidělení stránek PVS na pozadí zlepšuje výkon ADR tím, že omezí potřebu nákladnějších přidělení PVS v popředí. Tuto částku můžete zvýšit pomocí konfigurace ADR Preallocation Factor serveru. Pro další informace se podívejte na Konfigurace serveru: ADR Preallocation Factor.

• U SQL Server 2022 (16.x) a novějších zvažte povolení vícevláknového PVS čištění, pokud není dostatečný výkon při čištění s jedním vláknem. Další informace, naleznete v tématu Konfigurace serveru: ADR Cleaner Thread Count.

• Pokud zaznamenáte problémy, jako je vysoké využití místa v databázi pomocí PVS nebo pomalé vyčištění PVS, přečtěte si Řešení potíží s akcelerovaným obnovením databáze.

Vylepšení ADR v SQL Serveru 2022

Existuje několik vylepšení řešení úložiště trvalých verzí (PVS) a zlepšení celkové škálovatelnosti. Další informace o nových funkcích SYSTÉMU SQL Server 2022 (16.x) najdete v tématu Novinky v systému SQL Server 2022.

Stejná vylepšení jsou dostupná také ve službě Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (pouze vyhrazený fond SQL) a v Databázi SQL v Microsoft Fabric.

• čištění uživatelských transakcí

  Vyčistěte stránky, které nedokážete vyčistit běžným procesem kvůli selhání při získávání zámku.

  Tato funkce umožňuje uživatelským transakcím spustit čištění na stránkách, které nebylo možné řešit pravidelným procesem čištění kvůli konfliktům zámků na úrovni tabulky. Toto vylepšení pomáhá zajistit, aby proces čištění ADR neztroskotal donekonečna kvůli tomu, že uživatelské úlohy nemohou získat zámky na úrovni tabulky.

• Snížení využití paměti pro sledování stránek PVS

  Toto vylepšení sleduje stránky PVS na úrovni rozsahu, aby se snížily nároky na paměť potřebné k údržbě verzí stránek.

• Vylepšení čističe PVS

  PVS Cleaner má vylepšenou efektivitu čištění verzí, aby zlepšil způsob sledování a zaznamenávání verzí řádků, který používá databázový stroj pro přerušené transakce. To vede k vylepšení využití paměti a úložiště.

• úložiště trvalých verzí na úrovni transakcí (PVS)

  Toto vylepšení umožňuje ADR vyčistit verze, které patří do potvrzených transakcí nezávisle na tom, zda jsou v systému přerušené transakce. Díky tomuto vylepšení je možné dealokovat stránky PVS, i když není možné úspěšně dokončit skenování a oříznout přerušenou mapu transakcí.

  Výsledkem tohoto zlepšení je snížení růstu PVS i v případě, že čištění PVS je pomalé nebo selže.

• Údržba verzí s více vlákny

  V SQL Serveru 2019 (15.x) probíhá proces čištění v instanci databázového stroje jednovláknově.

  Počínaje SQL Serverem 2022 (16.x) je podporováno vyčištění verze s více vlákny. To umožňuje paralelní vyčištění více databází ve stejné instanci databázového stroje nebo rychlejší vyčištění jedné databáze. Další informace naleznete v tématu Konfigurace serveru: ADR Cleaner Thread Count.

  Byla přidána nová rozšířená událost tx_mtvc2_sweep_statspro monitorování vícevláknové verze čističe ADR PVS.

Související obsah

• Správa zrychleného obnovení databáze
• řešení potíží s akcelerovaným obnovením databáze