Automatické obnovení pro databáze zrcadlené v systému Fabric ze služby Azure SQL Database

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

Za určitých podmínek, pokud dojde ke zpoždění zrcadlení na Fabric, může dojít ke zvýšení využití souboru transakčního logu. 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ě Azure SQL Database a Azure SQL Managed Instance může dojít k reseedu na úrovni databáze nebo na úrovni tabulky.

Doplnění na úrovni databáze: Průběžné zrcadlení dat je zastaveno pro všechny tabulky v databázi, které mají zrcadlení povoleno, transakční log se zkrátí a zrcadlení se znovu inicializuje pro databázi znovu publikováním výchozího snímku všech tabulek, které mají zrcadlení povoleno. Přírůstkové změny pak budou pokračovat v průběžné replikaci.
Opětovné nasazení na úrovni tabulky: Průběžné zrcadlení dat je zastaveno pouze u tabulek, které vyžadují nové nasazení. 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 převysévání 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í transakčního protokolu pro databázi s povoleným zrcadlením Fabricu může stále růst a bránit zkrácení 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 nastat 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í prostor v transakčním protokolu.
- 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 spravovanou identitu přiřazenou uživatelem (UAMI) k zápisu do cílové zóny 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 systému Fabric po dlouhou dobu zůstane pozastavená, nemusí zrcadlení pokračovat od bodu zastavení a přeseje 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 se využité místo v souboru transakčního protokolu blíží maximální kapacitě, zahájí se opětovná inicializace databáze, aby se uvolnilo zadržené místo v protokolu.

Příčiny automatického přečítání 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 v Fabric již 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 nasazení

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 restartování na úrovni databáze.

Pokud je celá databáze znovu inicializována, zkontrolujte následující podmínky.

Sloupec reseed_state v systémové uložené proceduře sys.sp_help_change_feed_settings na zdrojové SQL databázi ukazuje její aktuální stav obnovy.
- 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.

Ověřte, zda bylo spuštěno resetování identity na úrovni tabulky

Pro každou tabulku, která se resetuje, vyhledejte hodnotu 7 pro sloupec state v sys.sp_help_change_feed_table.

Další informace najdete v sys.sp_help_change_feed_table.

Řešení potíží se zrcadlenými databázemi prostředků infrastruktury ze služby Azure SQL Database

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-11-25