Zrychlené obnovení databáze v Azure SQL

Platí pro:Azure SQL DatabaseAzure SQL Managed Instance

Zrychlené obnovení databáze (ADR) je funkce databázového stroje SQL Serveru, která výrazně 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 SQL Serveru.

ADR je aktuálně k dispozici pro Azure SQL Database, Azure SQL Managed Instance, databáze v Azure Synapse Analytics a SQL Server na virtuálních počítačích Azure počínaje SQL Serverem 2019. Informace o ADR na SQL Serveru najdete v tématu Správa zrychleného obnovení databáze.

Poznámka:

Služba ADR je ve výchozím nastavení povolená ve službě Azure SQL Database a ve službě Azure SQL Managed Instance. Zakázání ADR ve službě Azure SQL Database a azure SQL Managed Instance se nepodporuje.

Přehled

Hlavními výhodami ADR jsou:

  • Rychlé a konzistentní obnovení databáze

    U ADR nemají dlouhotrvající transakce 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 velikostech.

  • Okamžité vrácení transakcí zpět

    U ADR je vrácení transakce okamžité, bez ohledu na čas, kdy byla transakce aktivní, nebo počet aktualizací, které provedly.

  • Agresivní zkrácení protokolu

    U ADR se transakční protokol agresivně zkracuje, a to i v přítomnosti aktivních dlouhotrvajících transakcí, což brání jeho rozšíření mimo kontrolu.

Standardní proces obnovení databáze

Obnovení databáze se řídí modelem obnovení ARIES a skládá se ze tří fází, které jsou znázorněny v následujícím diagramu a podrobněji jsou vysvětleny podle diagramu.

current recovery process

  • Fáze analýzy

    Přeposlání kontroly transakčního protokolu od začátku posledního úspěšného kontrolního bodu (nebo nejstarší špinavé stránky LSN) až do konce, aby bylo možné určit stav každé transakce v době, kdy databáze přestala.

  • Fáze opětovného dokončení

    Přeposlání prohledávání transakčního protokolu od nejstarší nepotvrzené transakce až do konce, aby se databáze dostala do stavu, kdy došlo k chybovému ukončení, opětovným použitím všech potvrzených operací.

  • Zpět – fáze

    Pro každou transakci, která byla aktivní v době chybového ukončení, prochází protokol zpět a vrátí zpět operace, které tato transakce provedla.

Na základě tohoto návrhu je doba obnovení databázového stroje SQL Serveru z neočekávaného restartování (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í. Proces obnovení proto může trvat dlouhou dobu v přítomnosti dlouhotrvajících transakcí (například velkých hromadných operací vložení nebo operací sestavení indexu u velké tabulky).

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

Kromě toho databázový stroj SQL Serveru nemůže zkrátit transakční protokol, pokud existují dlouhotrvající transakce, protože jejich odpovídající záznamy protokolu jsou potřeba pro procesy obnovení a vrácení zpět. V důsledku tohoto návrhu databázového stroje SQL Serveru někteří zákazníci použili k vyřešení problému, že velikost transakčního protokolu roste velmi velký a spotřebovává obrovské množství místa na disku.

Proces zrychleného obnovení databáze

ADR řeší výše uvedené problémy tím, že zcela přepracuje proces obnovení databázového stroje SQL Serveru na:

  • Zajistěte, aby byl konstantní čas a okamžitě, protože nemusíte prohledávat protokol od/do 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šího čísla sekvence protokolu špinavé stránky (LSN)). V důsledku toho není doba obnovení ovlivněna dlouhotrvajícími transakcemi.
  • Minimalizujte požadovaný prostor transakčního protokolu, protože už není potřeba zpracovat protokol pro celou transakci. V důsledku toho může být transakční protokol agresivně zkrácen, protože dojde k kontrolním bodům a zálohám.

ADR na vysoké úrovni dosahuje rychlého obnovení databáze tím, že zvládá všechny úpravy fyzické databáze a vrátí zpět pouze logické 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 aktuální proces obnovení. Jak tyto fáze fungují s ADR, je znázorněno v následujícím diagramu a podrobněji je vysvětleno podle diagramu.

ADR recovery process

  • Fáze analýzy

    Proces zůstává stejný jako předtím s přidáním rekonstruování SLOG a kopírováním záznamů protokolu pro nesprávě verzí.

  • Fáze opětovného dokončení

    Rozdělené do dvou fází (P)

    • Fáze 1

      Znovu z protokolu SLOG (nejstarší nepotvrzená transakce až do posledního kontrolního bodu). Znovu je rychlá operace, protože z protokolu SLOG stačí zpracovat jenom několik záznamů.

    • Fáze 2

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

  • Zpět – fáze

    Fáze Vrácení zpět s ADR se dokončí téměř okamžitě pomocí SLOG k vrácení nespravovaných operací a trvalého úložiště verzí (PVS) s logickou revert pro provedení vrácení zpět na úrovni řádků zpět.

Součásti obnovení ADR

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

  • Trvalé úložiště verzí (PVS)

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

  • Logický návrat

    Logický návrat je asynchronní proces zodpovědný za provádění vrácení zpět na úrovni řádků na úrovni řádků – poskytuje okamžité vrácení transakcí zpět a vrácení zpět pro všechny operace s verzí. Logická zpětná operace se provádí takto:

    • Sledování všech přerušených transakcí a jejich označení neviditelné pro jiné transakce.
    • Provedení vrácení zpět pomocí PVS pro všechny uživatelské transakce, místo fyzické kontroly transakčního protokolu a vrácení změn postupně zpět.
    • Uvolnění všech zámků ihned po přerušení transakce. Vzhledem k tomu, že přerušení zahrnuje jednoduché označení změn v paměti, proces je velmi efektivní a proto zámky nemusí být dlouho uchovány.
  • DŘINA

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

    • Nízký svazek a paměť
    • Zachování na disku serializacem během procesu kontrolního bodu
    • Pravidelné zkrácení jako potvrzení transakcí
    • Zrychluje opakování a vrátí zpět zpracování pouze operací, které nejsou verze.
    • Umožňuje agresivní zkrácení transakčního protokolu zachováním pouze požadovaných záznamů protokolu.
  • Čistší

    Čistější je asynchronní proces, který se pravidelně probudí a vyčistí verze stránek, které nejsou potřeba.

Vzory zrychleného obnovení databáze (ADR)

Z ADR využívají většinu následujících typů úloh:

  • Pro úlohy s dlouhotrvajícími transakcemi se doporučuje ADR.
  • Pro úlohy, které zaznamenaly případy, kdy aktivní transakce způsobují, že se transakční protokol výrazně zvětšuje, se doporučuje ADR.
  • Pro úlohy, u kterých došlo k dlouhé době nedostupnosti databáze, se doporučuje adržování obnovení (například neočekávané restartování služby nebo ruční vrácení transakcí).

Osvědčené postupy pro zrychlené obnovení databáze

  • Vyhněte se dlouhotrvajícím transakcím v databázi. I když jedním z cílů ADR je zrychlit obnovení databáze z důvodu dlouhotrvajících aktivních transakcí, dlouhotrvající transakce můžou zpozdit vyčištění verze a zvýšit velikost PVS.

  • Vyhněte se velkým transakcím se změnami definice dat nebo operacemi DDL. ADR používá mechanismus SLOG (systémový stream protokolu) ke sledování operací DDL používaných při obnovení. Protokol SLOG se používá pouze v době, kdy je transakce aktivní. SLOG je kontrolní bod, takže vyhněte se velkým transakcím, které používají SLOG, může pomoct celkovému výkonu. 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 vyřazuje 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. Alternativním řešením může být, že indexy zahodíte jednotlivě a postupně a pak tabulku vypustíte. Další informace o SLOGu najdete v tématu Součásti obnovení ADR.

  • Zabraňte nebo snižte nepotřebné přerušené situace. Vysoká míra přerušení způsobí tlak na čistič PVS a nižší výkon ADR. Přerušení může pocházet z vysoké míry zablokování, duplicitních klíčů nebo jiných porušení omezení.

    • Zobrazení sys.dm_tran_aborted_transactions dynamické správy zobrazuje všechny přerušené transakce v instanci SQL Serveru. Sloupec nested_abort označuje, že transakce potvrzena, ale existují části, které přerušily (body uložení nebo vnořené transakce), které mohou blokovat proces čištění PVS. Další informace najdete v tématu sys.dm_tran_aborted_transactions (Transact-SQL).

    • Chcete-li aktivovat proces čištění PVS ručně mezi úlohami nebo během údržby, použijte sys.sp_persistent_version_cleanup. Další informace najdete v tématu sys.sp_persistent_version_cleanup.

  • Pokud zaznamenáte problémy s využitím úložiště, vysokou přerušení transakce a další faktory, přečtěte si téma Řešení potíží s akcelerovaným obnovením databáze (ADR) na SQL Serveru.

Další kroky