Automatisch opnieuw verzenden configureren voor gespiegelde Fabric-databases vanuit SQL Server

Dit artikel behandelt het automatisch opnieuw initialiseren voor het spiegelen van een database voor een SQL Server-exemplaar.

Er zijn bepaalde situaties waarin vertragingen in spiegeling naar Fabric kunnen leiden tot een verhoogd gebruik van transactielogboekbestanden. Dit komt doordat het transactielogboek pas kan 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.

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

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.

De functie voor automatisch beheer is standaard uitgeschakeld in SQL Server 2025 (preview) om automatisch herstellen in te schakelen. De functie voor automatisch beheer is ingeschakeld en kan niet worden beheerd of uitgeschakeld in Azure SQL Database en Azure SQL Managed Instance.

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. Configureer deze waarde in SQL Server wanneer u de functie inschakelt, met sys.sp_change_feed_configure_parameters.
• 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.

Diagnose

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.

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

Automatisch beheren inschakelen

Als het logboekgebruik dat wordt geretourneerd door het vorige T-SQL-script bijna vol is (bijvoorbeeld groter dan 70%), kunt u overwegen om de gespiegelde database in te schakelen voor automatisch opnieuw verzenden met behulp van de door het sys.sp_change_feed_configure_parameters systeem opgeslagen procedure. Als u bijvoorbeeld het automatischreseed gedrag wilt inschakelen:

USE <Mirrored database name>
GO
EXECUTE sys.sp_change_feed_configure_parameters 
  @autoreseed = 1
, @autoreseedthreshold = 70; 

Zie sys.sp_change_feed_configure_parameters voor meer informatie.

In de brondatabase moet de reseed de ruimte voor het transactielogboek vrijgeven die wordt vastgehouden door spiegeling. Geef een handleiding CHECKPOINT uit op de SQL Server-brondatabase om de vrijgave van logboekruimte af te dwingen als de reden van de bewaring nog steeds REPLICATION wordt veroorzaakt door spiegeling. Zie CHECKPOINT (Transact-SQL)voor meer informatie.

Handmatig opnieuw verzenden

Als best practice kunt u handmatig opnieuw verzenden voor een specifieke database testen met behulp van de volgende opgeslagen procedure om inzicht te hebben in de impact voordat u de functionaliteit voor automatisch opnieuw verzenden inschakelt.

USE <Mirrored database name>
GO
EXECUTE sp_change_feed_reseed_db_init @is_init_needed = 1;

Zie sys.sp_change_feed_reseed_db_init voor meer informatie.

Controleren of een opnieuw verzonden bericht is geactiveerd

• De reseed_state kolom in de systeemeigen opgeslagen procedure sys.sp_help_change_feed_settings van de bron-SQL-database geeft de 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.

Verwante inhoud

• Problemen met gespiegelde Fabric-databases oplossen vanuit SQL Server
• Prestaties optimaliseren voor gespiegelde databases vanuit SQL Server