Freigeben über

Fehler 9002: Das Transaktionsprotokoll für die Datenbank ist voll aufgrund der Fehlermeldung AVAILABILITY_REPLICA in SQL Server

  • Artikel

Dieser Artikel hilft Ihnen, den 9002-Fehler zu beheben, der auftritt, wenn das Transaktionsprotokoll zu einem großen oder nicht mehr verfügbaren Speicherplatz in SQL Server wird.

Ursprüngliche Produktversion: SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012
Ursprüngliche KB-Nummer: 2922898

Problembeschreibung

Stellen Sie sich folgendes Szenario vor:

  • Sie haben Microsoft SQL Server 2012 oder eine höhere Version auf einem Server installiert.
  • Die Instanz von SQL Server ist ein primäres Replikat in der Umgebung "Always On Availability Groups".
  • Die Option für die automatische Vergrößerung für Transaktionsprotokolldateien wird in SQL Server festgelegt.

In diesem Szenario kann das Transaktionsprotokoll groß werden und nicht genügend Speicherplatz vorhanden sein oder die Option "MaxSize " für das Transaktionsprotokoll im primären Replikat überschreiten, und Sie erhalten eine Fehlermeldung, die wie folgt aussieht:

Fehler: 9002, Schweregrad: 17, Status: 9. Das Transaktionsprotokoll für die Datenbank '%.*ls' ist aufgrund von 'AVAILABILITY_REPLICA' voll.

Ursache

Dies tritt auf, wenn die protokollierten Änderungen am primären Replikat noch nicht im sekundären Replikat gehärtet werden. Weitere Informationen zum Datensynchronisierungsprozess in alwaysOn-Umgebung finden Sie unter Datensynchronisierung hronisierungsprozess.

Problembehandlung

Es gibt zwei Szenarien, die zu einem Protokollwachstum in einer Verfügbarkeitsdatenbank und zu folgendem 'AVAILABILITY_REPLICA' log_reuse_wait_descführen können:

  • Szenario 1: Latenz, die protokollierte Änderungen an sekundären Änderungen liefert

    Wenn Transaktionen Daten im primären Replikat ändern, werden diese Änderungen in Protokolldatensätze gekapselt, und diese protokollierten Blöcke werden an die Datenbankprotokolldatei im sekundären Replikat übermittelt und gehärtet. Das primäre Replikat kann Protokollblöcke in einer eigenen Protokolldatei erst überschreiben, wenn diese Protokollblöcke in allen sekundären Replikaten bereitgestellt und in die entsprechende Datenbankprotokolldatei gehärtet wurden. Jede Verzögerung bei der Übermittlung oder Härtung dieser Blöcke an ein Replikat in der Verfügbarkeitsgruppe verhindert das Abschneiden dieser protokollierten Änderungen in der Datenbank am primären Replikat und führt dazu, dass die Verwendung der Protokolldatei vergrößert wird.

    Weitere Informationen finden Sie unter "Hohe Netzwerklatenz" oder "Geringer Netzwerkdurchsatz", was die Protokollerstellung für das primäre Replikat verursacht.

  • Szenario 2: Wiederholen der Latenz

    Sobald die sekundäre Datenbankprotokolldatei gehärtet wurde, wendet ein dedizierter Wiederholen-Thread in der sekundären Replikatinstanz die enthaltenen Protokolldatensätze auf die entsprechenden Datendateien an. Das primäre Replikat kann Protokollblöcke in seiner eigenen Protokolldatei erst überschreiben, wenn alle Wiederholen-Threads in allen sekundären Replikaten die enthaltenen Protokolldatensätze angewendet haben.

    Wenn der Wiederholungsvorgang für ein sekundäres Replikat nicht in der Lage ist, mit der Geschwindigkeit, mit der Protokollblöcke bei diesem sekundären Replikat gehärtet werden, auf dem laufenden zu bleiben, führt es zu protokolliertem Wachstum am primären Replikat. Das primäre Replikat kann nur sein eigenes Transaktionsprotokoll abschneiden und wiederverwenden, bis zu dem Punkt, auf den alle Wiederholungsthreads des sekundären Replikats angewendet wurden. Wenn mehrere sekundäre Elemente vorhanden sind, vergleichen Sie die truncation_lsn Spalte der sys.dm_hadr_database_replica_states dynamischen Verwaltungsansicht über mehrere Secondaries hinweg, um zu ermitteln, welche sekundäre Datenbank das Protokollabschneiden am meisten verzögert.

    Sie können die Always On Dashboard- und sys.dm_hadr_database_replica_states dynamischen Verwaltungsansichten verwenden, um die Warteschlange zum Senden von Protokollen und die Wiederherstellen-Warteschlange zu überwachen. Einige Schlüsselfelder sind:

    Feld BESCHREIBUNG
    log_send_queue_size Anzahl der Protokolldatensätze, die nicht zum sekundären Replikat gelangt sind
    log_send_rate Häufigkeit, mit der Protokolldatensätze an die sekundären Datenbanken gesendet werden.
    redo_queue_size Die Menge an Protokolldatensätzen in den Protokolldateien des sekundären Replikats, die noch nicht neu erstellt wurde, in Kilobyte (KB).
    redo_rate Die Rate, mit der die Protokolldatensätze in einer bestimmten sekundären Datenbank in Kilobyte (KB)/Sekunde erneut bearbeitet werden.
    last_redone_lsn Tatsächliche Protokollfolgenummer des letzten Protokolldatensatzes, der zuletzt für die sekundäre Datenbank wiederholt wurde. last_redone_lsn ist immer kleiner als last_hardened_lsn.
    last_received_lsn Die Protokollblock-ID, die den Punkt angibt, an dem alle Protokollblöcke vom sekundären Replikat empfangen wurden, das diese sekundäre Datenbank hosten soll. Gibt eine Protokollblock-ID an, die mit Nullen aufgefüllt ist. Es handelt sich nicht um eine tatsächliche Protokollsequenznummer.

    Führen Sie z. B. die folgende Abfrage für das primäre Replikat aus, um das Replikat mit der frühesten truncation_lsn zu melden, und ist die obere Grenze, die das primäre Objekt in seinem eigenen Transaktionsprotokoll zurückgeben kann:

    SELECT ag.name AS [availability_group_name]
, d.name AS [database_name]
, ar.replica_server_name AS [replica_instance_name]
, drs.truncation_lsn , drs.log_send_queue_size
, drs.redo_queue_size
FROM sys.availability_groups ag
INNER JOIN sys.availability_replicas ar
    ON ar.group_id = ag.group_id
INNER JOIN sys.dm_hadr_database_replica_states drs
    ON drs.replica_id = ar.replica_id
INNER JOIN sys.databases d
    ON d.database_id = drs.database_id
WHERE drs.is_local=0
ORDER BY ag.name ASC, d.name ASC, drs.truncation_lsn ASC, ar.replica_server_name ASC

    Korrekturmaßnahmen können umfassen, sind jedoch nicht auf Folgendes beschränkt:

    • Stellen Sie sicher, dass keine Ressourcen- oder Leistungsengpässe an der sekundären Stelle vorhanden sind.
    • Stellen Sie sicher, dass der Redo-Thread nicht an der sekundären Stelle blockiert ist. Verwenden Sie das lock_redo_blocked erweiterte Ereignis, um zu ermitteln, wann dies geschieht und welche Objekte der Redo-Thread blockiert wird.

Problemumgehung

Nachdem Sie die sekundäre Datenbank identifiziert haben, die dies bewirkt, versuchen Sie eine oder mehrere der folgenden Methoden, um dieses Problem vorübergehend zu umgehen:

  • Entfernen Sie die Datenbank aus der Verfügbarkeitsgruppe für die problematische sekundäre.

    Notiz

    Diese Methode führt zum Verlust des Szenarios "Hohe Verfügbarkeit/Notfallwiederherstellung" für die sekundäre Methode. Möglicherweise müssen Sie die Verfügbarkeitsgruppe in Zukunft erneut einrichten.

  • Wenn der Redo-Thread häufig blockiert wird, deaktivieren Sie das Readable Secondary Feature, indem Sie den ALLOW_CONNECTIONS Parameter des SECONDARY_ROLE Replikats in NO ändern.

    Notiz

    Dadurch wird verhindert, dass Benutzer die Daten im sekundären Replikat lesen, was die Ursache der Blockierung ist. Nachdem die Redo-Warteschlange auf eine akzeptable Größe verworfen wurde, sollten Sie das Feature erneut aktivieren.

  • Aktivieren Sie die Einstellung für die automatische Vergrößerung , wenn sie deaktiviert ist und speicherplatz verfügbar ist.

  • Erhöhen Sie den MaxSize-Wert für die Transaktionsprotokolldatei, wenn sie erreicht wurde und speicherplatz verfügbar ist.

  • Fügen Sie eine zusätzliche Transaktionsprotokolldatei hinzu, wenn die aktuelle datei maximal 2 TB des Systems erreicht hat oder zusätzlichen Speicherplatz auf einem anderen verfügbaren Volume verfügbar ist.

Weitere Informationen

Gilt für:

  • SQL Server 2012 Enterprise
  • SQL Server 2014 Enterprise
  • SQL Server 2014 Business Intelligence
  • SQL Server 2014 Standard
  • SQL Server 2016 Enterprise
  • SQL Server 2016 Standard
  • SQL Server 2017 Enterprise
  • SQL Server 2017 Standard Windows