Sdílet prostřednictvím


Automatické obnovení ve službě Fabric pro zrcadlené databáze z Azure SQL Managed Instance

Tento článek se zabývá automatickým obnovením zrcadlení databáze ve službě Azure SQL Managed Instance.

Za určitých podmínek, pokud dojde ke zpoždění zrcadlení na Fabric, může dojít ke zvýšenému využití transakčního log souboru. Transakční protokol nelze zkrátit, dokud se potvrzené změny nereplikují do zrcadlené databáze. Jakmile velikost transakčního protokolu dosáhne maximálního definovaného limitu, zápisy do databáze selžou.

K ochraně provozních databází před chybám při zápisu důležitých transakcí OLTP se zrcadlení ve službě Azure SQL Database a službě Azure SQL Managed Instance využívá možnost autoreseed, která umožňuje zkrácení transakčního protokolu a reinitializuje zrcadlení databáze na Fabric.

Opětovné obnovení zastaví tok transakcí do Microsoft Fabric ze zrcadlené databáze a znovu inicializuje zrcadlení v současné době. Opětovné vytvoření zahrnuje vygenerování nového počátečního snímku tabulek nakonfigurovaných pro zrcadlení a jeho replikaci do Microsoft Fabric. Po vytvoření snímku se přírůstkové změny replikují.

Ve službách Azure SQL Database a Azure SQL Managed Instance může dojít k přesazení na úrovni databáze nebo na úrovni tabulky.

  • Opětovné zasetí na úrovni databáze: Průběžné zrcadlení dat je zastaveno pro všechny tabulky povolené pro zrcadlení v databázi, transakční protokol je zkrácen a zrcadlení je znovu inicializováno opětovným publikováním počátečního snímku všech tabulek povolených pro zrcadlení. Přírůstkové změny pak budou pokračovat v průběžné replikaci.

  • Opětovné osazení úrovně tabulky: Průběžné zrcadlení dat je zastaveno pouze u tabulek, které vyžadují opětovné osazení. Zrcadlení se znovu inicializuje pro ty ovlivněné tabulky opětovným publikováním počátečního snímku. Přírůstkové změny pak budou pokračovat v průběžné replikaci.

Příčiny automatického obnovení na úrovni databáze

Obnovení na úrovni databáze chrání dostupnost zápisu databáze tím, že zajišťuje, aby se transakční protokol nezvětšoval na maximální velikost. Maximální velikost transakčního protokolu je založená na cíli na úrovni databázové služby azure SQL Database nebo spravované instance Azure SQL. Využití záznamového protokolu pro databázi s povoleným zrcadlením Fabric může nadále růst a zadržovat zkrácení záznamového protokolu. Jakmile velikost transakčního protokolu dosáhne maximálního definovaného limitu, zápisy do databáze selžou.

  • Zabránění zkrácení protokolu kvůli zrcadlení může dojít z několika důvodů:

    • Latence zrcadlení dat ze zdroje do zrcadlené databáze brání zkrácení transakcí čekajících na replikaci z transakčního protokolu.
    • Dlouho běžící replikované transakce čekající na replikaci nelze zkrátit, protože zabírají místo v protokolu transakcí.
    • Trvalé chyby zápisu do přistávací zóny v OneLake mohou zabránit replikaci.
      • Tento scénář může být způsobený nedostatečnými oprávněními. Zrcadlení do Fabric používá spravovanou identitu přiřazenou systémem (SAMI) nebo uživatelsky přiřazenou spravovanou identitu (UAMI) k zápisu do zóny přistání v One Lake. Pokud to není správně nakonfigurované, replikace transakcí může opakovaně selhat.

        Poznámka:

        Podpora spravované identity přiřazené uživatelem (UAMI) je aktuálně ve verzi Preview.

  • Pokud je kapacita Fabric pozastavená a obnovená, stav zrcadlené databáze zůstane pozastavený. V důsledku toho se změny provedené ve zdroji nereplikují do OneLake. Pokud chcete obnovit zrcadlení, přejděte na portálu Fabric do zrcadlené databáze a vyberte Pokračovat v replikaci. Zrcadlení pokračuje tam, kde bylo pozastaveno.

    Pokud kapacita Fabric po dlouhou dobu zůstane pozastavená, nemusí replikace pokračovat ze svého zastavovacího bodu a znovu načte data od začátku. Důvodem je to, že pozastavení zrcadlení po dlouhou dobu může způsobit, že se využití protokolu transakcí zdrojové databáze zvětšuje a zabraňuje zkrácení protokolu. Při obnovení zrcadlení, pokud je využité místo v souboru transakčního protokolu téměř plné, dojde k reinicializaci databáze, aby se uvolnil zabraný prostor v protokolu.

Příčiny automatického obnovení na úrovni tabulky

Pokud dojde ke změnám schématu ve zdrojových tabulkách, které jsou povolené pro zrcadlení, schéma pro tyto zrcadlené tabulky ve Fabric už neodpovídá zdroji. K tomu může dojít z důvodu následujících ALTER TABLE příkazů jazyka DDL (Data Definition Language) T-SQL ve zdroji:

  • Přidání, přetažení, změna nebo přejmenování sloupce
  • Zkrácení nebo přejmenování tabulky
  • Přidání neclusterovaného primárního klíče

Opětovné obnovení se aktivuje jenom pro ovlivněné tabulky.

Diagnostika

Pokud chcete zjistit, jestli zrcadlení prostředků infrastruktury brání zkrácení protokolu pro zrcadlenou databázi, zkontrolujte log_reuse_wait_desc sloupec v zobrazení systémového sys.databases katalogu a zjistěte, jestli je REPLICATIONdůvodem . Další informace o typech čekání opakovaného použití protokolu naleznete v tématu Faktory zpoždění zkrácení transakčního protokolu. Například:

SELECT [name], log_reuse_wait_desc 
FROM sys.databases 
WHERE is_data_lake_replication_enabled = 1;

Pokud dotaz zobrazuje REPLICATION typ čekání pro opakované použití protokolu, pak kvůli zrcadlení transakčního protokolu nemůže vyprázdnit potvrzené transakce a bude pokračovat v vyplňování. Další řešení potíží s používáním protokolů ve službě Azure SQL Database najdete v tématu Řešení potíží s chybami transakčního protokolu ve službě Azure SQL Database.

Pomocí následujícího skriptu T-SQL zkontrolujte celkové místo v protokolu a aktuální využití protokolu a dostupné místo:


USE <Mirrored database name>
GO 
--initialize variables
DECLARE @total_log_size bigint = 0; 
DECLARE @used_log_size bigint = 0;
DECLARE @size int;
DECLARE @max_size int;
DECLARE @growth int;

--retrieve total log space based on number of log files and growth settings for the database
DECLARE sdf CURSOR
FOR
SELECT SIZE*1.0*8192/1024/1024 AS [size in MB],
            max_size*1.0*8192/1024/1024 AS [max size in MB],
            growth
FROM sys.database_files
WHERE TYPE = 1 
OPEN sdf 
FETCH NEXT FROM sdf INTO @size,
                @max_size,
                @growth 
WHILE @@FETCH_STATUS = 0 
BEGIN
SELECT @total_log_size = @total_log_size + 
CASE @growth
        WHEN 0 THEN @size
        ELSE @max_size
END 
FETCH NEXT FROM sdf INTO @size,
              @max_size,
              @growth 
END 
CLOSE sdf;
DEALLOCATE sdf;

--current log space usage
SELECT @used_log_size = used_log_space_in_bytes*1.0/1024/1024
FROM sys.dm_db_log_space_usage;

-- log space used in percent
SELECT @used_log_size AS [used log space in MB],
       @total_log_size AS [total log space in MB],
       @used_log_size/@total_log_size AS [used log space in percentage];

Během opětovného zasetí

Během opětovného obnovení je položka zrcadlené databáze v Microsoft Fabric k dispozici, ale nebude dostávat přírůstkové změny, dokud se znovu nedokončí. Sloupec reseed_state indikuje sys.sp_help_change_feed_settings stav opětovného obnovení.

V zrcadlení prostředků infrastruktury se monitoruje protokol transakcí zdrojové databáze SQL. Autoreseed se aktivuje pouze v případech, kdy jsou splněny následující tři podmínky:

  • Transakční protokol je více než @autoreseedthreshold procent plný, 70například .
  • Důvodem opakovaného použití protokolu je REPLICATION.
  • Vzhledem k tomu, že REPLICATION je možné vyvolat čekání na opakované použití protokolu pro jiné funkce, jako je transakční replikace nebo CDC, dojde k automatickému vytváření pouze v případě, že sys.databases.is_data_lake_replication_enabled = 1. Tato hodnota je nakonfigurována zrcadlením prostředků infrastruktury.

Zkontrolujte, jestli se aktivovalo obnovení na úrovni databáze.

Pokud je obnovována celá databáze, vyhledejte následující podmínky.

  • reseed_state sloupec v systémové uložené proceduře sys.sp_help_change_feed_settings na zdrojové SQL databázi označuje aktuální stav přesevu.

    • 0 = Normální.
    • 1 = Databáze spustila proces opětovné inicializace do prostředků infrastruktury. Přechodný stav.
    • 2 = Databáze se znovu inicializuje do prostředků infrastruktury a čeká na restartování replikace. Přechodný stav. Po vytvoření replikace se stav opětovného obnovení přesune do 0.

    Další informace najdete v tématu sys.sp_help_change_feed_settings.

  • Všechny tabulky povolené pro zrcadlení v databázi budou mít hodnotu 7 sloupce state v sys.sp_help_change_feed_table.

    Další informace najdete v sys.sp_help_change_feed_table.

Kontrola, jestli se aktivovala změna na úrovni tabulky

  • Pro každou tabulku, která se přesazuje, vyhledejte hodnotu 7 pro sloupec state v sys.sp_help_change_feed_table.

    Další informace najdete v sys.sp_help_change_feed_table.