Automatisk omsådd för Fabric-speglade databaser från Azure SQL Database

2025-10-17

Den här artikeln beskriver automatisk återberäkning för spegling av en databas i Azure SQL Database.

Under vissa förhållanden kan en fördröjning i speglingen till Fabric leda till ökad användning av transaktionsloggfiler. Transaktionsloggen kan inte trunkeras förrän de genomförda ändringarna har replikerats till den speglade databasen. När transaktionsloggens storlek når sin maximala definierade gräns misslyckas skrivningar till databasen. För att skydda driftdatabaser från skrivfel för kritiska OLTP-transaktioner kan du konfigurera en mekanism med automatisk genomstrykning som gör att transaktionsloggen trunkeras och initierar om databasspeglingen till Infrastrukturresurser.

Funktionen för automatisk borttagning är aktiverad och kan inte hanteras eller inaktiveras i Azure SQL Database och Azure SQL Managed Instance.

En återställd stoppar flödet av transaktioner till Microsoft Fabric från den speglade databasen och initierar speglingen igen i det aktuella tillståndet. En återställning innebär att generera en ny initial ögonblicksbild av de tabeller som konfigurerats för spegling och replikera dem till Microsoft Fabric. Efter ögonblicksbilden replikeras inkrementella ändringar.

I Azure SQL Database och Azure SQL Managed Instance kan återställning ske på databasnivå eller tabellnivå.

Databasnivå har återställts: Pågående spegling av data stoppas för alla tabeller i databasen som är aktiverade för spegling, transaktionsloggen trunkeras och speglingen initieras om för databasen genom att den första ögonblicksbilden av alla tabeller som är aktiverade för spegling publiceras igen. Sedan återupptas ändringarna och replikeras kontinuerligt.
Tabellnivå har återställts: Pågående spegling av data stoppas endast för tabeller som behöver återställas. Speglingen initieras på nytt för de tabeller som påverkas genom att den första ögonblicksbilden publiceras igen. Sedan återupptas ändringarna och replikeras kontinuerligt.

Orsaker till automatisk återställning på databasnivå

En omseedning på databasnivå skyddar tillgängligheten för databasskrivning genom att se till att transaktionsloggen inte växer till maximistorlek. Den maximala transaktionsloggstorleken baseras på databasens servicenivåmål för Azure SQL Database eller Azure SQL Managed Instance. Användningen av transaktionsloggen för en databas som är aktiverad för spegling i Fabric kan fortsätta att växa och förhindra loggtrunkeringen. När transaktionsloggens storlek når den maximala definierade gränsen misslyckas skrivningar till databasen.

Förhindrad loggtrunkering på grund av spegling kan inträffa av flera orsaker:
- Fördröjning vid spegling av data från källan till den speglade databasen hindrar att transaktioner som väntar på replikering tas bort från transaktionsloggen.
- Långvariga replikerade transaktioner som väntar på replikering kan inte trunkeras, vilket upptar utrymme i transaktionsloggen.
- Beständiga fel vid skrivning till landningszonen i OneLake förhindrar replikering.
  - Till exempel på grund av brist på tillräckliga behörigheter. Spegling till Fabric använder systemtilldelad hanterad identitet för att skriva till landningszon i One Lake. Om detta inte är korrekt konfigurerat kan replikering av transaktioner upprepade gånger misslyckas.
För att skydda mot detta utlöser spegling automatiskt en ny initiering av hela databasen när det använda loggutrymmet har passerat ett visst tröskelvärde för totalt konfigurerat loggutrymme.
Om Fabric-kapaciteten pausas och återupptas, förblir den speglade databasstatusen pausad. Därför replikeras inte ändringar som görs i källan till OneLake. Om du vill återuppta speglingen går du till den speglade databasen i Infrastrukturportalen och väljer Återuppta replikering. Speglingen fortsätter där den pausades.

Om fabric-kapaciteten förblir pausad under en längre tid kanske speglingen inte återupptas från sin stoppunkt utan istället initierar data från början. Det beror på att att pausa spegling under en längre tid kan leda till att användningen av källdatabasens transaktionslogg växer och förhindrar loggtrunkering. När speglingen återupptas initieras en återställning av databasen för att frigöra det lagrade loggutrymmet om det använda transaktionsloggfilutrymmet är nästan fullt.

Orsaker till automatisk återinitiering på tabellnivå

När schemaändringar sker i källtabellerna som är aktiverade för spegling matchar schemat för de speglade tabellerna i Infrastruktur inte längre källan. Detta kan inträffa på grund av följande ALTER TABLE T-SQL-instruktioner för datadefinitionsspråk (DDL) på källan:

Lägg till/släpp/ändra/byta namn på kolumn
Trunkera/byta namn på tabell
Lägg till icke-klustrad primärnyckel

Omstart initieras endast för de berörda tabellerna.

Diagnostisera

Om du vill ta reda på om infrastrukturspegling förhindrar loggtrunkering för en speglad databas kontrollerar du log_reuse_wait_desc kolumnen i sys.databases systemkatalogvyn för att se om orsaken är REPLICATION. Mer information om loggens återanvändningsväntetyper finns i Faktorer som fördröjer trunkering av transaktionsloggar. Till exempel:

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

Om frågan visar REPLICATION loggens återanvändningsväntetyp kan transaktionsloggen inte tömma de incheckade transaktionerna på grund av fabric-spegling och fortsätter att fyllas. Ytterligare felsökning av logganvändning i Azure SQL Database finns i Felsöka transaktionsloggfel med Azure SQL Database.

Använd följande T-SQL-skript för att kontrollera det totala loggutrymmet och aktuell logganvändning och tillgängligt utrymme:


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];

Under återplantering

Under återställningen är det speglade databasobjektet i Microsoft Fabric tillgängligt men får inte inkrementella ändringar förrän det återställda har slutförts. Kolumnen reseed_state i sys.sp_help_change_feed_settings anger det återställda tillståndet.

I Infrastrukturspegling övervakas SQL Database-källtransaktionsloggen. En autoreseed utlöses endast när följande tre villkor är uppfyllda:

Transaktionsloggen är mer än @autoreseedthreshold procent full, till exempel 70.
Loggens återanvändningsorsak är REPLICATION.
Eftersom loggens REPLICATION återanvändningsvänte kan aktiveras för andra funktioner, till exempel transaktionsreplikering eller CDC, sker autoväxling endast när sys.databases.is_data_lake_replication_enabled = 1. Det här värdet konfigureras av Infrastrukturspegling.

Kontrollera om en återställning på databasnivå har utlösts

Om hela databasen återställs letar du efter följande villkor.

Kolumnen reseed_state i den system lagrade proceduren sys.sp_help_change_feed_settings i SQL-källdatabasen anger dess aktuella återställda tillstånd.
- 0 = Normal.
- 1 = Databasen har påbörjat processen med att initiera om till Infrastrukturresurser. Övergångstillstånd.
- 2 = Databasen initieras om till Infrastrukturresurser och väntar på att replikeringen ska startas om. Övergångstillstånd. När replikeringen upprättas flyttas tillståndet som har återställts till 0.
Mer information finns i sys.sp_help_change_feed_settings.
Alla tabeller som är aktiverade för spegling i databasen har värdet 7 för state kolumnen i sys.sp_help_change_feed_table.

Mer information finns i sys.sp_help_change_feed_table.

Kontrollera om en återsådd på tabellnivå har utlösts

För alla tabeller som skickas om letar du efter värdet 7 för kolumnen state i sys.sp_help_change_feed_table.

Mer information finns i sys.sp_help_change_feed_table.

Felsöka speglade Fabric-databaser från Azure SQL Database

Feedback

Var den här sidan till hjälp?