Automatisch opnieuw verzenden voor gespiegelde Fabric-databases vanuit Azure SQL Database

2025-10-17

In dit artikel wordt het automatisch opnieuw zaaien voor het spiegelen van een database in Azure SQL Database behandeld.

Onder bepaalde voorwaarden, als er sprake is van een vertraging in de spiegeling naar Fabric, kan een toegenomen gebruik van transactielogboekbestanden tot gevolg hebben. Het transactielogboek kan pas worden afgekapt nadat doorgevoerde wijzigingen zijn gerepliceerd naar de gespiegelde database. Zodra de maximale gedefinieerde limiet voor het transactielogboek is bereikt, mislukken schrijfbewerkingen naar de database. Als u operationele databases wilt beschermen tegen schrijffouten voor kritieke OLTP-transacties, kunt u een mechanisme voor automatisch beheer instellen waarmee het transactielogboek kan worden afgekapt en de databasespiegeling opnieuw kan worden geïnitialiseerd naar Fabric.

De functie voor automatisch beheer is ingeschakeld en kan niet worden beheerd of uitgeschakeld in Azure SQL Database en Azure SQL Managed Instance.

Een herverdeelde stroom stopt de stroom van transacties naar Microsoft Fabric vanuit de gespiegelde database en initialiseert de spiegeling bij de huidige status opnieuw. Een nieuwe kopie omvat het genereren van een nieuwe momentopname van de tabellen die zijn geconfigureerd voor spiegeling en het repliceren ervan naar Microsoft Fabric. Na de momentopname worden incrementele wijzigingen gerepliceerd.

In Azure SQL Database en Azure SQL Managed Instance kan het opnieuw worden verzonden op databaseniveau of op tabelniveau.

Het formaat van de database is gewijzigd: Doorlopend spiegelen van gegevens wordt gestopt voor alle tabellen in de database die zijn ingeschakeld voor spiegeling, het transactielogboek wordt afgekapt en spiegeling wordt opnieuw geïnitialiseerd voor de database door de eerste momentopname van alle tabellen die zijn ingeschakeld voor spiegeling opnieuw te publiceren. Daarna worden incrementele wijzigingen voortdurend gerepliceerd.
Herinitialisatie op tabelniveau: Doorlopende spiegeling van gegevens wordt alleen gestopt voor tabellen waarvoor een herinitialisatie vereist is. De spiegeling wordt opnieuw geïnitialiseerd voor de betrokken tabellen door de eerste momentopname opnieuw te publiceren. Daarna worden incrementele wijzigingen voortdurend gerepliceerd.

Oorzaken van automatisch opnieuw verzenden op databaseniveau

Een reseed op databaseniveau beschermt de beschikbaarheid van database-schrijven door ervoor te zorgen dat het transactielogboek niet tot de maximale grootte groeit. De maximale grootte van transactielogboeken is gebaseerd op de serviceniveaudoelstelling van de database van de Azure SQL Database of Azure SQL Managed Instance. Het gebruik van transactielogboeken voor een database die is ingeschakeld voor Fabric mirroring kan blijven groeien en voorkomt het afkappen van logboeken. Zodra de maximale gedefinieerde limiet voor het transactielogboek is bereikt, mislukken schrijfbewerkingen naar de database.

Het voorkomen van logboekafkapping vanwege spiegeling kan om verschillende redenen voorkomen.
- Latentie bij het spiegelen van gegevens van de bron naar de gespiegelde database voorkomt dat transacties die in behandeling zijn, worden afgekapt uit het transactielogboek.
- Langlopende gerepliceerde transacties in afwachting van replicatie kunnen niet worden afgekort, waardoor transactielogruimte wordt vastgehouden.
- Permanente fouten bij het schrijven naar de landingszone in OneLake verhinderen replicatie.
  - Bijvoorbeeld als gevolg van onvoldoende machtigingen. Spiegeling naar Fabric maakt gebruik van door het systeem toegewezen beheerde identiteit om te schrijven naar landingszone in One Lake. Als dit niet juist is geconfigureerd, kan de replicatie van transacties herhaaldelijk mislukken.
Om dit te waarborgen, initieert spiegeling automatisch het opnieuw indelen van de hele database wanneer de gebruikte logboekruimte een bepaalde drempelwaarde voor de totale geconfigureerde logboekruimte heeft overschreden.
Als de capaciteit van de Fabric is gepauzeerd en hervat, blijft de status van de gespiegelde database Gepauzeerd. Als gevolg hiervan worden wijzigingen in de bron niet gerepliceerd naar OneLake. Als u spiegeling wilt hervatten, gaat u naar de gespiegelde database in de Fabric-portal en selecteert u Replicatie hervatten. Spiegeling gaat verder vanaf waar het is onderbroken.

Als de capaciteit van de infrastructuur lange tijd onderbroken blijft, wordt spiegeling mogelijk niet hervat vanaf het stoppunt en worden de gegevens vanaf het begin opnieuw verzonden. Dit komt omdat het lang onderbreken van de spiegeling ertoe kan leiden dat het gebruik van het transactielogboek van de brondatabase toeneemt en het verkorten van logboeken tegenhoudt. Wanneer spiegeling wordt hervat en de gebruikte ruimte voor het transactielogboekbestand bijna vol is, wordt een herverwijdering van de database gestart om de bewaarde logboekruimte vrij te geven.

Oorzaken van automatisch opnieuw verzenden op tabelniveau

Wanneer schemawijzigingen optreden in de brontabellen die zijn ingeschakeld voor spiegeling, komt het schema voor die gespiegelde tabellen in Fabric niet meer overeen met de bron. Dit kan gebeuren vanwege de volgende ALTER TABLE DDL-T-SQL-instructies (Data Definition Language) op de bron:

Kolom toevoegen/verwijderen/wijzigen/hernoemen
Tabel afkappen/de naam ervan wijzigen
Niet-geclusterde primaire sleutel toevoegen

Opnieuw initialiseren wordt alleen geactiveerd voor de getroffen tabellen.

Diagnose stellen

Als u wilt bepalen of fabricspiegeling verhindert dat logboeken worden afgekapt voor een gespiegelde database, controleert u de log_reuse_wait_desc kolom in de sys.databases systeemcatalogusweergave om te zien of de reden is REPLICATION. Zie Factoren voor het afkappen van transactielogboeken voor meer informatie over de wachttypen voor opnieuw gebruiken van logboeken. Voorbeeld:

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

Als in de query het wachttype voor opnieuw gebruiken van logboeken wordt weergegeven REPLICATION , kan het transactielogboek vanwege het spiegelen van het transactielogboek geen vastgelegde transacties leegmaken en blijft deze invullen. Zie Problemen met transactielogboeken met Azure SQL Database oplossen voor aanvullende probleemoplossing voor logboekgebruik in Azure SQL Database.

Gebruik het volgende T-SQL-script om de totale logboekruimte en het huidige logboekgebruik en de beschikbare ruimte te controleren:


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

Tijdens het opnieuw zaaien

Tijdens het opnieuw verzenden is het gespiegelde database-item in Microsoft Fabric beschikbaar, maar ontvangt het geen incrementele wijzigingen totdat het opnieuw verzenden is voltooid. De reseed_state kolom in sys.sp_help_change_feed_settings geeft de status opnieuw verzonden aan.

In Fabric Mirroring wordt het transactielogboek van de SQL-database in de bron bewaakt. Een autoreseed wordt alleen geactiveerd wanneer aan de volgende drie voorwaarden wordt voldaan:

Het transactielogboek is bijvoorbeeld @autoreseedthresholdmeer dan 70 het percentage vol.
De reden voor opnieuw gebruiken van logboeken is REPLICATION.
Omdat het opnieuw gebruiken van logboeken REPLICATION kan worden verhoogd voor andere functies, zoals transactionele replicatie of CDC, treedt automatisch alleen op wanneer sys.databases.is_data_lake_replication_enabled = 1. Deze waarde wordt geconfigureerd door Fabric Mirroring.

Controleren of het opnieuw verzenden op databaseniveau is geactiveerd

Als de hele database opnieuw wordt geïnitialiseerd, let op de volgende omstandigheden.

De reseed_state kolom in de systeemopgeslagen procedure sys.sp_help_change_feed_settings in de bron-SQL-database geeft zijn huidige reseed-status aan.
- 0 = Normaal.
- 1 = De database is begonnen met het opnieuw initialiseren van Fabric. Overgangsstatus.
- 2 = De database wordt opnieuw geïnitialiseerd naar Fabric en wacht tot de replicatie opnieuw is gestart. Overgangsstatus. Wanneer replicatie tot stand is gebracht, wordt de status opnieuw verzonden naar 0.
Zie sys.sp_help_change_feed_settings voor meer informatie.
Alle tabellen die zijn ingeschakeld voor spiegeling in de database hebben een waarde van 7 voor de state-kolom in sys.sp_help_change_feed_table.

Zie sys.sp_help_change_feed_table voor meer informatie.

Controleren of een opnieuw verzonden tabelniveau is geactiveerd

Zoek voor elke tabel die opnieuw wordt verzonden naar een waarde voor 7 de state kolom in sys.sp_help_change_feed_table.

Zie sys.sp_help_change_feed_table voor meer informatie.

Problemen met gespiegelde Fabric-databases oplossen vanuit Azure SQL Database

Feedback

Is deze pagina nuttig?