Automatisk reseed for Fabric-spejlede databaser fra Azure SQL Managed Instance

I denne artikel beskrives automatisk genudbedring til spejling af en database i Azure SQL Managed Instance.

Under visse omstændigheder, hvis der er en forsinkelse i spejling til Fabric, kan det resultere i øget brug af transaktionslogfiler. Transaktionsloggen kan ikke afkortes, før de bekræftede ændringer er replikeret til den spejlede database. Når transaktionslogstørrelsen når sin maksimale definerede grænse, mislykkes skrivninger til databasen.

For at beskytte operationelle databaser mod skrivefejl for kritiske OLTP-transaktioner bruger mirroring i Azure SQL Database og Azure SQL Managed Instance autoreseed-funktionen, som tillader at transaktionsloggen afkortes og geninitialiserer databasespejlingen til Fabric.

En genudførsel stopper strømmen af transaktioner til Microsoft Fabric fra den spejlede database og initialiserer spejlingen igen i den aktuelle tilstand. En reseed omfatter generering af et nyt indledende øjebliksbillede af de tabeller, der er konfigureret til spejling, og replikering af det til Microsoft Fabric. Efter øjebliksbilledet replikeres trinvise ændringer.

I Azure SQL Database og Azure SQL Managed Instance kan der ske reseed på databaseniveau eller tabelniveau.

Reseed på databaseniveau: Igangværende spejling af data stoppes for alle tabeller i databasen, der er aktiveret til spejling, transaktionsloggen afkortes, og spejling initialiseres igen for databasen ved at genudgive det første øjebliksbillede af alle tabeller, der er aktiveret til spejling. Derefter genoptages trinvise ændringer løbende replikering.
Omseedning på tabelniveau: Igangværende spejling af data stoppes kun for tabeller, der kræver genseedning. Spejlingen initialiseres igen for de berørte tabeller ved at genudgive det oprindelige øjebliksbillede. Derefter genoptages trinvise ændringer løbende replikering.

Årsager til automatisk genræsning på databaseniveau

En reseed på databaseniveau beskytter tilgængeligheden af databaseskrivning ved at sikre, at transaktionsloggen ikke vokser til maksimal størrelse. Den maksimale størrelse på transaktionsloggen er baseret på databasens serviceniveaumål for Azure SQL Database eller Azure SQL Managed Instance. Brugen af transaktionsloggen for en database, der er aktiveret til Fabric-spejling, kan fortsætte med at vokse og forsinke logtrunkeringen. Når transaktionslogstørrelsen når den maksimale definerede grænse, mislykkes skrivninger til databasen.

Forhindret logtrunkering på grund af spejling kan ske af flere årsager:
- Ventetid ved spejling af data fra kilden til den spejlede database forhindrer, at transaktioner, der afventer replikering, afkortes fra transaktionsloggen.
- Langvarige replikerede transaktioner, der venter på replikering, kan ikke afkortes, så transaktionslogpladsen holdes fast.
- Vedvarende fejl, der skriver til landingszonen i OneLake, kan forhindre replikation.
  - Dette scenarie kan skyldes utilstrækkelige tilladelser. Spejling til Fabric bruger System Assigned Managed Identity (SAMI) eller User Assigned Managed Identity (UAMI) til at skrive til landingszonen i One Lake. Hvis dette ikke er konfigureret korrekt, kan replikering af transaktioner gentagne gange fejle.
    
    Notat
    
    Understøttelse af User Assigned Managed Identity (UAMI) er i øjeblikket i preview.
Hvis Fabric-kapaciteten er sat på pause og genoptaget, forbliver den spejlede databasestatus Midlertidigt afbrudt. Som følge heraf replikeres ændringer, der er foretaget i kilden, ikke til OneLake. Hvis du vil genoptage spejling, skal du gå til den spejlede database på Fabric-portalen og vælge Genoptag replikering. Spejlingen fortsætter fra det sted, hvor den blev sat på pause.

Hvis strukturkapaciteten forbliver sat på pause i lang tid, genoptages spejlingen muligvis ikke fra stoppunktet og vil genstarte data fra begyndelsen. Dette skyldes, at afbrydelse af spejling i lang tid kan medføre, at brugen af kildedatabasens transaktionslog vokser og forsinker logtrunkeringen. Når spejling genoptages, og den anvendte transaktionslogfilplads er tæt på fuld, startes en reseed af databasen for at frigive den tilbageholdte logplads.

Årsager til automatisk genseedning på tabelniveau

Når der sker skemaændringer i de kildetabeller, der er aktiveret til spejling, stemmer skemaet for de spejlede tabeller i Fabric ikke længere overens med kilden. Dette kan ske på grund af følgende ALTER TABLE DDL (DATA DEFINITION LANGUAGE) T-SQL-sætninger på kilden:

Tilføj/slip/ænd/omdøb kolonne
Afkort/omdøb tabel
Tilføj primær nøgle, der ikke er grupperet

Reseed udløses kun for de påvirkede tabeller.

Diagnosticere

Hvis du vil identificere, om Fabric-spejling forhindrer logtrunkering for en spejlet database, skal du kontrollere log_reuse_wait_desc kolonnen i systemkatalogvisningen sys.databases for at se, om årsagen er REPLICATION. Du kan finde flere oplysninger om ventetyperne for genbrug af logfiler under Faktorer, der forsinker afkortning af transaktionsloggen. For eksempel:

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

Hvis forespørgslen viser REPLICATION ventetypen for genbrug af log, kan transaktionsloggen ikke tømme bekræftede transaktioner på grund af Fabric-spejling og fortsætter med at udfylde. Du kan finde yderligere fejlfinding af logbrug i Azure SQL Database under Foretag fejlfinding af transaktionslogfejl med Azure SQL Database.

Brug følgende T-SQL-script til at kontrollere den samlede logplads og det aktuelle logforbrug og den tilgængelige plads:


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 gensåning

Under reseedning er det spejlede databaseelement i Microsoft Fabric tilgængeligt, men modtager ikke trinvise ændringer, før reseedningen er fuldført. Kolonnen reseed_state i sys.sp_help_change_feed_settings angiver genseedningstilstanden.

I Fabric Mirroring overvåges SQL-databasens transaktionslog. En automatisk genudløsning udløses kun, når følgende tre betingelser er opfyldt:

Transaktionsloggen er mere end @autoreseedthreshold procent fuld, for eksempel, 70.
Årsagen til genbrug af log er REPLICATION.
Da ventetiden på genbrug af REPLICATION log kan udløses for andre funktioner, f.eks. transaktionsreplikering eller CDC, sker automatisk genudsætning kun, når sys.databases.is_data_lake_replication_enabled = 1. Denne værdi konfigureres af Fabric Mirroring.

Kontrollér, om en reseed på databaseniveau er blevet udløst

Hvis hele databasen bliver genseedet, skal du kigge efter følgende betingelser.

Kolonnen reseed_state i den systemlagrede procedure sys.sp_help_change_feed_settings i SQL-kildedatabasen angiver dens aktuelle reseed-tilstand.
- 0 = Normalt.
- 1 = Databasen har startet processen med at initialisere til Fabric igen. Overgangstilstand.
- 2 = Databasen initialiseres igen til Fabric og venter på, at replikeringen genstarter. Overgangstilstand. Når replikeringen er etableret, flyttes genseed-tilstanden til 0.
Du kan finde flere oplysninger i sys.sp_help_change_feed_settings.
Alle tabeller, der er aktiveret til spejling i databasen, har værdien 7 for state kolonnen i sys.sp_help_change_feed_table.

Du kan finde flere oplysninger i sys.sp_help_change_feed_table.

Kontroller, om en reseed på tabelniveau er blevet udløst

For alle tabeller, der seedes igen, skal du kigge efter en værdi på 7 for state kolonnen i sys.sp_help_change_feed_table.

Du kan finde flere oplysninger i sys.sp_help_change_feed_table.

Foretag fejlfinding af Fabric-spejlede databaser fra Azure SQL Managed Instance

Feedback

Var denne side nyttig?

Last updated on 2025-11-25