Automatisk reseed for Fabric speilede databaser fra Azure SQL Database

Denne artikkelen dekker automatisk reseeding for speiling av en database i Azure SQL Database.

Under visse omstendigheter hvis det er en forsinkelse i speiling til Fabric, kan det føre til økt bruk av transaksjonsloggfiler. Transaksjonsloggen kan ikke avkortes før etter at bekreftede endringer er replikert til den speilede databasen. Når transaksjonsloggstørrelsen når sin maksimale definerte grense, mislykkes skriving til databasen.

For å beskytte operative databaser mot skrivefeil for kritiske OLTP-transaksjoner, bruker speiling i Azure SQL Database og Azure SQL Managed Instance autoreseed-funksjonen som gjør det mulig å avkorte transaksjonsloggen og reinitialiserer databasespeilingen til Fabric.

En ny seeding stopper flyten av transaksjoner til Microsoft Fabric fra den speilede databasen og initialiserer speilingen på nytt i gjeldende tilstand. En reseed innebærer å generere et nytt innledende øyeblikksbilde av tabellene som er konfigurert for speiling, og replikere det til Microsoft Fabric. Etter øyeblikksbildet replikeres trinnvise endringer.

I Azure SQL Database og Azure SQL Managed Instance kan reseeding skje på databasenivå eller tabellnivå.

Gjendefinering på databasenivå: Pågående speiling av data stoppes for alle tabeller i databasen som er aktivert for speiling, transaksjonsloggen avkortes, og speiling initialiseres på nytt for databasen ved å publisere det første øyeblikksbildet av alle tabeller som er aktivert for speiling, på nytt. Deretter fortsetter inkrementelle endringer kontinuerlig replikering.
Tabell nivå reseed: Pågående speiling av data stoppes bare for tabeller som krever ny seeding. Speilingen initialiseres på nytt for de berørte tabellene ved å publisere det første øyeblikksbildet på nytt. Deretter fortsetter inkrementelle endringer kontinuerlig replikering.

Årsaker til automatisk reseed på databasenivå

En ny seed på databasenivå beskytter tilgjengeligheten av databaseskriving ved å sikre at transaksjonsloggen ikke vokser til maksimal størrelse. Den maksimale størrelsen på transaksjonsloggen er basert på databasens tjenestenivåmål for Azure SQL Database eller Azure SQL Managed Instance. Bruk av transaksjonslogg for en database som er aktivert for strukturspeiling, kan fortsette å vokse og holde loggavkorting oppe. Når transaksjonsloggstørrelsen når den maksimale definerte grensen, mislykkes skriving til databasen.

Forhindret loggavkorting på grunn av speiling kan skje av flere årsaker:
- Ventetid ved speiling av data fra kilden til den speilede databasen hindrer at transaksjoner som venter på replikering, avkortes fra transaksjonsloggen.
- Langvarige replikerte transaksjoner som venter på replikering, kan ikke avkortes, og holder på transaksjonsloggplass.
- Vedvarende feil som skriver til landingssonen i OneLake kan forhindre replikasjon.
  - Dette scenariet kan skyldes utilstrekkelige tillatelser. Speiling til Fabric bruker System Assigned Managed Identity (SAMI) eller User Assigned Managed Identity (UAMI) for å skrive til landingssonen i One Lake. Hvis dette ikke er riktig konfigurert, kan replikering av transaksjoner gjentatte ganger feile.
    
    Note
    
    Støtte for User Assigned Managed Identity (UAMI) er for øyeblikket i forhåndsvisning.
Hvis Fabric-kapasiteten er midlertidig stanset og gjenopptatt, forblir den speilede databasestatusen Midlertidig stanset. Som et resultat av dette replikeres ikke endringer som er gjort i kilden, til OneLake. Hvis du vil gjenoppta speiling, går du til den speilede databasen i Fabric-portalen og velger Gjenoppta replikering. Speilingen fortsetter fra der den ble satt på pause.

Hvis Fabric-kapasiteten forblir satt på pause i lang tid, kan det hende at speiling ikke gjenopptas fra stopppunktet og vil starte data på nytt fra begynnelsen. Dette er fordi det å sette speiling på pause i lang tid kan føre til at bruken av kildedatabasens transaksjonslogg vokser og forsinker loggavkorting. Når speiling gjenopptas, hvis transaksjonsloggfilplassen som brukes er nesten full, vil en ny seeding av databasen bli startet for å frigjøre den forsinkede loggplassen.

Årsaker til automatisk reseed på tabellnivå

Når skjemaendringer skjer i kildetabellene som er aktivert for speiling, samsvarer ikke skjemaet for de speilede tabellene i Fabric lenger med kilden. Dette kan skje på grunn av følgende ALTER TABLE DDL (DATA DEFINITION LANGUAGE) T-SQL-setninger på kilden:

Legg til/slipp/endre/gi nytt navn til kolonne
Avkort/gi nytt navn til tabell
Legg til ikke-gruppert primærnøkkel

Reseed utløses bare for de berørte tabellene.

Diagnostisere

Hvis du vil identifisere om Fabric Mirroring hindrer loggavkorting for en speilet database, kontrollerer log_reuse_wait_desc du kolonnen i sys.databases systemkatalogvisningen for å se om årsaken er REPLICATION. Hvis du vil ha mer informasjon om ventetypene for gjenbruk av logg, kan du se Faktorer som forsinker avkorting av transaksjonslogg. Eksempel:

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

Hvis spørringen viser REPLICATION ventetype for gjenbruk av logg, kan ikke transaksjonsloggen tømme ut forpliktede transaksjoner på grunn av Fabric-speiling, og den vil fortsette å fylles ut. Hvis du vil ha ytterligere feilsøking av loggbruk i Azure SQL Database, kan du se Feilsøke transaksjonsloggfeil med Azure SQL Database.

Bruk følgende T-SQL-skript til å kontrollere total loggplass, gjeldende loggbruk og tilgjengelig plass:


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 såing

Under reseeding er det speilede databaseelementet i Microsoft Fabric tilgjengelig, men vil ikke motta trinnvise endringer før reseedingen er fullført. Kolonnen reseed_state i sys.sp_help_change_feed_settings angir tilstanden for ny seeding.

I Fabric Mirroring overvåkes transaksjonsloggen for SQL-databasen. En automatisk reseed vil bare utløses når følgende tre betingelser er oppfylt:

Transaksjonsloggen er for eksempel @autoreseedthresholdmer enn 70 prosent full, .
Årsaken til gjenbruk av loggen er REPLICATION.
Fordi ventetiden for gjenbruk av REPLICATION logg kan utløses for andre funksjoner, for eksempel transaksjonsreplikering eller CDC, skjer automatisk gjenbruk bare når sys.databases.is_data_lake_replication_enabled = 1. Denne verdien konfigureres av Fabric Mirroring.

Sjekk om en reseed på databasenivå er utløst

Hvis hele databasen blir seedet på nytt, se etter følgende betingelser.

Kolonnen reseed_state i den systemlagrede prosedyren sys.sp_help_change_feed_settings i SQL-kildedatabasen angir gjeldende status for reseeding.
- 0 = Normalt.
- 1 = Databasen har startet prosessen med å initialisere på nytt til Fabric. Overgangstilstand.
- 2 = Databasen initialiseres på nytt til Fabric og venter på at replikeringen skal starte på nytt. Overgangstilstand. Når replikering er etablert, flyttes reseed-tilstanden til 0.
Hvis du vil ha mer informasjon, kan du se sys.sp_help_change_feed_settings.
Alle tabeller som er aktivert for speiling i databasen, vil ha verdien 7 for state kolonnen i sys.sp_help_change_feed_table.

Hvis du vil ha mer informasjon, kan du se sys.sp_help_change_feed_table.

Sjekk om en ny seed på tabellnivå er utløst

For alle tabeller som blir seedet på nytt, se etter en verdi på 7 for state kolonnen i sys.sp_help_change_feed_table.

Hvis du vil ha mer informasjon, kan du se sys.sp_help_change_feed_table.

Feilsøke strukturspeilede databaser fra Azure SQL Database

Tilbakemeldinger

Var denne siden nyttig?

Last updated on 2025-12-02