Freigeben über

Automatisches Neuanlegen für Fabric-gespiegelte Datenbanken in Azure SQL-Datenbank

Dieser Artikel behandelt das automatische Neuinitialisieren für das Mirroring einer Datenbank in der Azure SQL-Datenbank.

Unter bestimmten Bedingungen kann eine Verzögerung bei der Spiegelung in Fabric zu einer erhöhten Nutzung der Transaktionsprotokolldatei führen. Das Transaktionsprotokoll kann erst verkürzt werden, nachdem festgeschriebene Ä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, verwendet die Spiegelung in Azure SQL-Datenbank und azure SQL Managed Instance die autoreseed-Funktion, mit der 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. Ein Neustart umfasst das Generieren einer neuen anfänglichen Momentaufnahme der Tabellen, die für die Spiegelung konfiguriert sind, und die Replikation in Microsoft Fabric. Nach der Momentaufnahme werden inkrementelle Änderungen repliziert.

In der Azure SQL-Datenbank und in der verwalteten Azure SQL-Instanz kann ein erneutes Senden auf Datenbankebene oder auf Tabellenebene erfolgen.

  • Neuinitialisierung auf Datenbankebene: Die laufende Spiegelung der Daten wird für alle Tabellen in der für die Spiegelung aktivierten Datenbank gestoppt, das Transaktionsprotokoll wird verkürzt, und die Spiegelung wird durch erneute Veröffentlichung des Anfangs-Snapshots aller für die Spiegelung aktivierten Tabellen in der Datenbank neu initialisiert. Anschließend werden inkrementelle Änderungen kontinuierlich repliziert.

  • Tabellenneusaat: Die laufende Datenreplikation wird nur für Tabellen gestoppt, die eine Neusaat erfordern. Die Spiegelung wird für die betroffenen Tabellen erneut initialisiert, indem die ursprüngliche Momentaufnahme erneut veröffentlicht wird. Anschließend werden inkrementelle Änderungen kontinuierlich repliziert.

Ursachen für automatisches Erneutes Senden auf Datenbankebene

Ein erneutes Speichern auf Datenbankebene schützt die Verfügbarkeit von Datenbankschreibvorgängen, indem sichergestellt wird, dass das Transaktionsprotokoll nicht auf maximale Größe anwachsen kann. Die maximale Größe des Transaktionsprotokolls basiert auf dem Ziel der Dienstebene der Azure SQL-Datenbank oder der verwalteten Instanz von Azure SQL. Die Verwendung des Transaktionsprotokolls für eine Datenbank, die für die Fabric-Spiegelung aktiviert ist, kann weiterhin wachsen und die Protokolltrunkierung verhindern. Sobald die Größe des Transaktionsprotokolls den maximal definierten Grenzwert erreicht hat, schlagen Schreibvorgänge in die Datenbank fehl.

  • Das Verhindern des Abschneidens von Protokollen aufgrund der Spiegelung kann aus mehreren Gründen erfolgen:

    • Latenz beim Spiegeln von Daten aus der Quelle in die gespiegelte Datenbank verhindert, dass Transaktionen, die auf ausstehende Replikationen warten, aus dem Transaktionsprotokoll gekürzt werden.
    • Lange laufende, replizierte Transaktionen, die auf die Replikation warten, können nicht abgeschnitten werden, wodurch Transaktionsprotokollspeicher belegt wird.
    • Dauerhafte Fehler beim Schreiben in die Landezone in OneLake können die Replikation verhindern.

      • Dieses Szenario kann durch unzureichende Berechtigungen verursacht werden. Die Spiegelung in Fabric verwendet System Assigned Managed Identity (vom System zugewiesene verwaltete Identität, SAMI) oder User Assigned Managed Identity (vom Benutzer zugewiesene verwaltete Identität, UAMI), um Daten in die Zielzone von One Lake zu schreiben. Wenn dies nicht ordnungsgemäß konfiguriert ist, kann die Replikation von Transaktionen wiederholt fehlschlagen.

        Hinweis

        Die Unterstützung für benutzerzugewiesene verwaltete Identitäten (User Assigned Managed Identity, UAMI) befindet sich derzeit im Preview-Modus.

  • Wenn die Fabric-Kapazität angehalten und fortgesetzt wird, bleibt der Spiegeldatenbankstatus angehalten. Daher werden änderungen, die an der Quelle vorgenommen wurden, nicht in OneLake repliziert. Um die Spiegelung fortzusetzen, wechseln Sie zur gespiegelten Datenbank im Fabric-Portal, und wählen Sie " Replikation fortsetzen" aus. Die Spiegelung wird an der Stelle fortgesetzt, an der sie angehalten wurde.

    Wenn die Fabric-Kapazität lange angehalten bleibt, wird die Spiegelung möglicherweise nicht vom Haltepunkt fortgesetzt, und die Daten werden von Anfang an erneut angezeigt. Dies liegt daran, dass das Anhalten der Spiegelung über einen längeren Zeitraum dazu führen kann, dass die Nutzung des Transaktionsprotokolls der Quelldatenbank ansteigt und die Protokollkürzung blockiert wird. Wenn die Spiegelung fortgesetzt wird und der verwendete Speicherplatz der Transaktionsprotokolldatei fast voll ist, wird eine Neusynchronisierung der Datenbank initiiert, um den belegten Protokollspeicher freizugeben.

Ursachen für automatisches Erneutes Senden auf Tabellenebene

Wenn Schemaänderungen in den Quelltabellen auftreten, die für die Spiegelung aktiviert sind, stimmt das Schema für diese gespiegelten Tabellen in Fabric nicht mehr mit der Quelle überein. Dies kann aufgrund folgender ALTER TABLE DDL-T-SQL-Anweisungen (Data Definition Language) für die Quelle passieren:

  • Spalte hinzufügen/ablegen/ändern/umbenennen
  • Tabelle abschneiden/umbenennen
  • Hinzufügen eines nicht gruppierten Primärschlüssels

Die Neuinitialisierung wird nur für die betroffenen Tabellen ausgelöst.

Diagnostizieren

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. Weitere Problembehandlung bei der Protokollverwendung in der Azure SQL-Datenbank finden Sie unter Problembehandlung bei Transaktionsprotokollfehlern mit Azure SQL-Datenbank.

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

Während der Neusaat

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.

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.
  • 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.

Überprüfen Sie, ob ein Datenbank-Reseed auf Datenbankebene erfolgt ist

Wenn die gesamte Datenbank erneut eingereet wird, suchen Sie nach den folgenden Bedingungen.

  • Die reseed_state Spalte in der systemgespeicherten Prozedur sys.sp_help_change_feed_settings in der SQL-Quelldatenbank gibt den aktuellen Wiederherstellungszustand 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.

Überprüfen, ob eine erneute Gliederung auf Tabellenebene ausgelöst wurde

  • Suchen Sie für eine beliebige Tabelle, die erneut eingefügt wird, nach einem 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.

Verwandte Inhalte

  • Last updated on