Konfigurieren des automatischen erneuten Speicherns für gespiegelte Fabric-Datenbanken aus SQL Server

In diesem Artikel wird das automatische Erneute Senden für die Spiegelung einer Datenbank aus einer SQL Server-Instanz behandelt.

Es gibt bestimmte Situationen, in denen Verzögerungen bei der Spiegelung in Fabric zu einer erhöhten Verwendung von Transaktionsprotokolldateien führen können. Dies liegt daran, dass das Transaktionsprotokoll erst abgeschnitten werden kann, nachdem zugesicherte Änderungen in die gespiegelte Datenbank repliziert wurden. Sobald die Größe des Transaktionsprotokolls ihren maximalen definierten Grenzwert erreicht hat, schlagen Schreibvorgänge in die Datenbank fehl. Um Betriebsdatenbanken vor Schreibfehlern für kritische OLTP-Transaktionen zu schützen, können Sie einen autoreseierten Mechanismus einrichten, mit dem das Transaktionsprotokoll abgeschnitten und die Datenbankspiegelung in Fabric erneut initialisiert wird.

Ein erneuter Ablauf von Transaktionen an Microsoft Fabric wird aus der gespiegelten Datenbank beendet und die Spiegelung im aktuellen Zustand erneut initialisiert. Dies umfasst das Generieren einer neuen anfänglichen Momentaufnahme der Tabellen, die für die Spiegelung konfiguriert sind, und dies in Microsoft Fabric replizieren. Nach der Momentaufnahme werden inkrementelle Änderungen repliziert.

Beim erneuten Senden ist das gespiegelte Datenbankelement in Microsoft Fabric verfügbar, empfängt aber erst dann inkrementelle Änderungen, wenn das erneute Senden abgeschlossen ist. Die reseed_state Spalte in sys.sp_help_change_feed_settings gibt den erneuten Zustand an.

Das Feature Autoreseed ist in SQL Server 2025 standardmäßig deaktiviert. Um es zu aktivieren, siehe Autoreseed aktivieren. Das autoreseierte Feature ist aktiviert und kann in azure SQL-Datenbank und azure SQL Managed Instance nicht verwaltet oder deaktiviert werden.

In Fabric Mirroring wird das SQL-Quelldatenbanktransaktionsprotokoll überwacht. Ein autoreseed wird nur ausgelöst, wenn die folgenden drei Bedingungen erfüllt sind:

Das Transaktionsprotokoll ist beispielsweise @autoreseedthresholdmehr als 70 Prozent voll. Konfigurieren Sie diesen Wert auf SQL Server, wenn Sie das Feature mit sys.sp_change_feed_configure_parameters aktivieren.
Der Grund für die Wiederverwendung des Protokolls lautet REPLICATION.
Da die Wiederverwendung des REPLICATION Protokolls für andere Features wie die Transaktionsreplikation oder CDC ausgelöst werden kann, tritt das autoreseierte Ereignis nur auf, wenn sys.databases.is_data_lake_replication_enabled = 1. Dieser Wert wird von Fabric Mirroring konfiguriert.

Diagnose

Um festzustellen, ob die Fabric-Spiegelung das Abschneiden von Protokollen für eine gespiegelte Datenbank verhindert, überprüfen Sie die log_reuse_wait_desc Spalte in der sys.databases Systemkatalogansicht, um festzustellen, ob der Grund ist REPLICATION. Weitere Informationen zum Wiederverwenden von Wartetypen im Protokoll finden Sie unter Faktoren, die das Abschneiden des Transaktionsprotokolls verzögern. Beispiel:

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

Wenn die Abfrage den Wartetyp "Protokoll wiederverwenden" anzeigt REPLICATION , kann das Transaktionsprotokoll aufgrund der Fabric-Spiegelung keine zugesicherten Transaktionen leeren und wird weiterhin ausgefüllt.

Verwenden Sie das folgende T-SQL-Skript, um den gesamten Protokollspeicher sowie die aktuelle Protokollnutzung und den verfügbaren Speicherplatz zu überprüfen:


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

Autoreseed aktivieren

Wenn die vom vorherigen T-SQL-Skript zurückgegebene Protokollverwendung nahezu voll ist (z. B. größer als 70%), sollten Sie die gespiegelte Datenbank für die automatische Erneutes Senden mithilfe der sys.sp_change_feed_configure_parameters gespeicherten Systemprozedur aktivieren. So aktivieren Sie z. B. das autoreseierte Verhalten:

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

Weitere Informationen finden Sie unter sys.sp_change_feed_configure_parameters.

In der Quelldatenbank sollte das erneute Speichern des Transaktionsprotokolls durch Spiegelung freigegeben werden. Geben Sie ein Handbuch CHECKPOINT für die SQL Server-Quelldatenbank aus, um die Freigabe des Protokollspeicherplatzes zu erzwingen, wenn der Haltegrund weiterhin REPLICATION auf spiegelungsbedingte Ursachen zurückzuführen ist. Weitere Informationen finden Sie unter CHECKPOINT (Transact-SQL).

Manuelles Erneutes Bearbeiten

Als bewährte Methode können Sie manuelles Erneutes Einfügen für eine bestimmte Datenbank mithilfe des folgenden gespeicherten Verfahrens testen, um die Auswirkungen zu verstehen, bevor Sie die automatische Erneutverwertungsfunktion aktivieren.

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

Weitere Informationen finden Sie unter sys.sp_change_feed_reseed_db_init.

Überprüfen, ob ein erneutes Senden ausgelöst wurde

Die reseed_state Spalte in der Systemgespeicherte Prozedur sys.sp_help_change_feed_settings in der SQL-Quelldatenbank gibt ihren aktuellen Rücksetzungsstatus an.
- 0 = Normal.
- 1 = Die Datenbank hat den Prozess der Erneutitialisierung in Fabric gestartet. Übergangszustand.
- 2 = Die Datenbank wird erneut auf Fabric initialisiert und wartet auf den Neustart der Replikation. Übergangszustand. Wenn die Replikation eingerichtet wird, wird der erneute Zustand in 0den Zustand verschoben.
Weitere Informationen finden Sie unter sys.sp_help_change_feed_settings.
Alle Tabellen, die für die Spiegelung in der Datenbank aktiviert sind, haben einen Wert 7 für die state Spalte in sys.sp_help_change_feed_table.

Weitere Informationen finden Sie unter sys.sp_help_change_feed_table.

Feedback

War diese Seite hilfreich?

Last updated on 2025-10-15