Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Tento článek popisuje automatické obnovení pro zrcadlení databáze z instance SQL Serveru.
V určitých situacích mohou zpoždění při zrcadlení do Microsoft Fabric vést ke zvýšenému využití souborů transakčních logů. Tento nárůst nastává, protože transakční záznam nelze zkrátit, dokud nejsou potvrzené změny replikovány do zrcadlené databáze. Jakmile velikost transakčního logu dosáhne maximálního definovaného limitu, zápisy do databáze selžou. Chcete-li chránit provozní databáze před selháním zápisu u kritických transakcí OLTP, můžete nastavit mechanismus autoreseed, který umožňuje oříznutí protokolu transakcí a opětovnou inicializaci zrcadlení databáze do Fabric.
Reseed zastaví tok transakcí ze zrcadlené databáze do Fabric a reinicializuje zrcadlení do aktuálního stavu. Tento proces zahrnuje vytvoření nového počátečního snímku tabulek nakonfigurovaných pro zrcadlení a replikaci tohoto snímku do Fabric. Po vytvoření snímku se přírůstkové změny replikují.
Během opětovného naplnění je zrcadlená položka databáze ve Fabric dostupná, ale nepřijímá přírůstkové změny, dokud není opětovné naplnění dokončeno. Sloupec reseed_state v sys.sp_help_change_feed_settings označuje stav opětovného nasazení.
Ve výchozím nastavení je funkce automatického seedování v systému SQL Server 2025 zakázána. Chcete-li to povolit, viz Povolení automatického opětovného nasazení. V Azure SQL Database a Azure SQL Managed Instance je tato funkce povolena a nelze ji spravovat ani vypínat.
Ve Fabric Mirroring je monitorován transakční protokol zdrojové databáze SQL. Autoreseed se spustí pouze tehdy, jsou-li splněny následující tři podmínky:
- Protokol transakcí je zaplněn z více než
@autoreseedthresholdprocent, například70. Na SQL Server nastavte tuto hodnotu při zapnutí funkce pomocí sys.sp_change_feed_configure_parameters. - Důvodem opakovaného použití protokolu je
REPLICATION. - Protože čekání na opakované použití protokolu
REPLICATIONmůže být vyvoláno i jinými funkcemi, jako je transakční replikace nebo CDC, k autoreseed dojde pouze tehdy, kdyžsys.databases.is_data_lake_replication_enabled= 1. Tato hodnota je nakonfigurována pomocí Fabric Mirroring.
Diagnose
Chcete-li zjistit, zda Fabric mirroring brání zkrácení protokolu pro zrcadlenou databázi, zkontrolujte sloupec log_reuse_wait_desc v zobrazení systémového katalogu sys.databases a ověřte, zda je důvodem REPLICATION. Další informace o typech čekání na opětovné použití protokolu naleznete v tématu Faktory, které zpožďují 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 typ čekání na opětovné využití logu REPLICATION, pak kvůli zrcadlení ve Fabric nemůže transakční protokol odstranit již potvrzené transakce a dál se zaplňuje.
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];
Povolit automatické obnovení
Pokud je využití logů vrácené předchozím T-SQL skriptem téměř plné (například více než 70%), zvažte povolení automatického opětovného seedování zrcadlené databáze pomocí systémově uložené sys.sp_change_feed_configure_parameters procedury. Pokud chcete například povolit automatické chování:
USE <Mirrored database name>
GO
EXECUTE sys.sp_change_feed_configure_parameters
@autoreseed = 1
, @autoreseedthreshold = 70;
Další informace naleznete v sys.sp_change_feed_configure_parameters.
Ve zdrojové databázi by proces opětovné inicializace měl uvolnit prostor v protokolu transakcí blokovaný zrcadlením. Pokud je důvod prodlevy stále REPLICATION kvůli zrcadlení, ručně proveďte CHECKPOINT ve zdrojové databázi SQL Server, aby se vynutilo uvolnění místa v protokolu transakcí. Další informace naleznete v tématu CHECKPOINT (Transact-SQL).
Ruční opětovná inicializace
Doporučujeme, abyste ruční opětovné nasazení pro konkrétní databázi otestovali pomocí následující uložené procedury, abyste před povolením automatického opětovného nasazení porozuměli jeho dopadu.
USE <Mirrored database name>
GO
EXECUTE sp_change_feed_reseed_db_init @is_init_needed = 1;
Další informace najdete v sys.sp_change_feed_reseed_db_init.
Kontrola, jestli se aktivovalo opětovné spuštění
Sloupec
reseed_statev systémové uložené proceduřesys.sp_help_change_feed_settingsve zdrojové databázi SQL zobrazuje aktuální stav reseedu.-
0= Normální. -
1= Databáze zahájila proces reinicializace pro Fabric. Přechodný stav.-
2= Databáze se znovu inicializuje do Fabric a čeká na obnovení replikace. Přechodný stav. Když je replikace navázána, stav opětovného zavedení se změní na0.
-
Další informace najdete v tématu sys.sp_help_change_feed_settings.
-
Všechny tabulky povolené pro zrcadlení v databázi mají ve sloupci
7vstatehodnotusys.sp_help_change_feed_table.Další informace najdete v sys.sp_help_change_feed_table.