"Fehler 9002. Das Transaktionsprotokoll für die Datenbank ist durch 'AVAILABILITY_REPLICA' "Fehlermeldung in SQL Server 2012

Wichtig: Dieser Artikel wurde maschinell übersetzt und wird dann möglicherweise mithilfe des Community Translation Framework (CTF) von Mitgliedern unserer Microsoft Community nachbearbeitet. Weitere Informationen zu CTF finden Sie unter http://support.microsoft.com/gp/machine-translation-corrections/de.

Den englischen Originalartikel können Sie über folgenden Link abrufen: 2922898
Problembeschreibung
Betrachten Sie das folgende Szenario:
  • Sie haben Microsoft SQL Server 2012 auf einem Server installiert.
  • Die Instanz von SQL Server ist in einer Umgebung AwaysOn Verfügbarkeit Gruppen.
  • Die Option " Automatische Vergrößerung " für Transaktionsprotokolldateien wird in SQL Server festgelegt.
In diesem Szenario wird das Transaktionsprotokoll möglicherweise sehr groß und Speicherplatz oder möglicherweise voll. Daher erhalten Sie eine Fehlermeldung, die der folgenden ähnelt:

Fehler 9002, Schweregrad: 17, Status: 9.
Die Protokolldatei für Datenbank ' %. * ls auf 'AVAILABILITY_REPLICA' voll ist

Hinweis
in SQL Server 2012 die OptionAutomatische Vergrößerungfestgelegt, Transaktionsprotokolldateien normalerweise können automatisch erweitert bis die maximale Größe der Protokolldatei.
Ursache
"Fehler 9002" gibt an, dass das Protokoll voll, durch Verfügbarkeit Replikat ist. Dies bedeutet, dass Datenbank protokollierte Änderung der Verfügbarkeit im primären Replikat nicht angekommen sind und diese Änderungen auf die Verfügbarkeit eines sekundären Replikate Datenbank angewendet wurden. Bis protokollierte Änderung eintreffen und angewendet werden, können die Änderung von Protokoll der Verfügbarkeit im primären Replikat abgeschnitten werden.
Problembehandlung:
"Protokoll senden" und Warteschlange "Wiederherstellen" sind messbare Synchronisierung Datenbank Verfügbarkeit. Diese Datenpunkte können Sie überwachen, um festzustellen, ob ein Datenbankprotokoll Verfügbarkeit aufgrund der abgeschnitten werden kann das Protokoll AVAILABILITY_REPLICA verwendet.
  • Sendewarteschlange Protokoll
    Bei eine Transaktion auf dem Primärserver ausgeführt protokollierte Blöcke übermittelt und die Protokolldatei auf die abgesichert. Verzögerung verhindert diese protokollierte Änderung in der Datenbank primäres Replikat abgeschnitten. Eine häufige Gründe für eine nachhaltige Protokoll Sendewarteschlange Latenz im Netzwerk oder bei ist Hardening (Schreiben auf Datenträger) Protokoll Blöcke auf dem sekundären Server.
  • Wiederholungswarteschlange
    Als sekundäre Datenbank-Protokolldatei Sicherheitsmitarbeitern gilt ein dedizierte wiederholen Thread Protokolldatensätze. Vergrößerung kann auftreten, wenn der Wiederherstellungsvorgang mit dem Transaktionsprotokoll nicht einrichten, die generiert wird. Ist der Wiederherstellungsvorgang sekundäre Replikat hinter diese Änderungen in eine entsprechende sekundäre Datenbank anwenden, wird die primäre Abschneiden des Transaktionsprotokolls.

Identifizierung der sekundären Datenbank, die das Abschneiden des Protokolls verzögert.

Wenn es mehr als eine sekundäre, möglicherweise ein bestimmter sekundären für das Protokoll abschneiden Problem verantwortlich ist. Um die sekundäre Datenbank identifizieren, die Abschneiden anmelden primäres Replikat verzögern, Abfrage derTruncation_lsn -Spalte der sys.dm_hadr_database_replica_states dynamic Management View (DMV), und überprüfen Sie die Log_send_queue und Redo_queueDatenpunkte, um das Problem zu diagnostizieren.

AlwaysOn-Dashboard und sys.dm_hadr_database_replica_statesDMV überwachen den Status wiederherstellen. Die folgende Tabelle enthält einige wichtige Felder:
FeldBeschreibung
log_send_queue_sizeGröße der Protokolldatensätze, die sekundäre Kopie nicht erreicht.
log_send_rateRate der Benutzer Datensätze der sekundären Datenbanken gesendet werden.
redo_queue_sizeGröße der Datensätze in den Protokolldateien der sekundären Kopie nicht noch, in Kilobyte (KB) wiederhergestellt worden ist.
redo_rateRate, mit der Protokolleinträge für eine bestimmte sekundäre Datenbank in KB pro Sekunde wiederhergestellt werden.
last_redone_lsnTatsächliche Protokollsequenznummer des letzten Protokolldatensatzes auf die sekundäre Datenbank wiederhergestellt wurde. Last_redone_lsn-Wert ist immer weniger infiziertstattdie Last_hardened_lsn Wert.
last_received_lsnProtokollieren Sie Block-ID, die den Punkt angibt, bis zu dem alle Protokolldateien Blöcke sekundäre Replikat erhält, die sekundäre Datenbank hostet, Dieses Feld gibt eine Protokoll-Block-ID, die mit Nullen aufgefüllt. Es ist keine tatsächliche Sequenznummer.

Führen Sie folgende Abfrage gegen primäres Replikat beispielsweise um Log_send_queue und Redo_queue Werte für jede Datenbank sekundäre Verfügbarkeit melden.

select ar.replica_server_name, drs.truncation_lsn, drs.log_send_queue_size, drs.redo_queue_size from sys.dm_hadr_database_replica_states drs join sys.availability_replicas ar on drs.replica_id=ar.replica_id where drs.is_local=0

Abhilfemaßnahmen können unter anderem sind folgende:
  • Stellen Sie sicher, dass keine Ressource oder Performance-Engpass der sekundären.
  • Stellen Sie sicher, dass im sekundären Thread Wiederherstellen nicht blockiert ist.
  • Stellen Sie sicher, dass der Thread Wiederherstellen nicht hinter da Ressourcenkonflikte reporting Arbeitslast erstellt.

Abhilfe
Nachdem Sie die sekundäre Datenbank, die dadurch auftreten identifiziert, versuchen Sie eine oder mehrere der folgenden Methoden umgehen dieses Problem vorübergehend:
  • Schalten Sie die Datenbank aus der Verfügbarkeit für den anstößigen sekundären.

    Hinweis Diese Methode führt zum Verlust der hohe Verfügbarkeit/Disaster Recovery-Szenario für den sekundären. Möglicherweise wird der Availability Group später einrichten.
  • Fügen Sie weitere Protokolldateien Leerzeichen oder Protokoll.
Status
Microsoft hat bestätigt, dass es sich um ein Problem bei den Microsoft-Produkten handelt, die im Abschnitt "Eigenschaften" aufgeführt sind.
Weitere Informationen
Vergrößerung des Transaktionsprotokolls kann aus einem der folgenden Gründe auftreten:
  • Eine große Transaktionsprotokolldatei existiert.
  • Transaktionen können fehlschlagen und Rollback starten können.
  • Transaktionen dauern abgeschlossen lange.
  • Es können Leistungsprobleme auftreten.
  • Blockieren auftreten.

Informationen darüber, warum ein Transaktionsprotokoll wächst unerwartet oder wird voll in SQL Server klicken Sie auf die folgenden Artikelnummer der Microsoft Knowledge Base:
317375 Ein Transaktionsprotokoll wächst unerwartet oder wird voll in SQL Server

Weitere Informationen über das Wiederherstellen Vorgang Problem finden Sie im folgenden Blog des Microsoft Developer Network (MSDN):
Weitere Informationen zu AVAILABILITY_REPLICA-basierteLog_reuse_waitSpalten finden Sie auf der folgenden MSDN-Website:
Weitere Informationen über die sys.dm_hadr_database_replica_states-Ansicht finden Sie auf der folgenden Microsoft TechNet-Website:

Informationen zur Überwachung und Problembehandlung protokollierte Änderung, die nicht kommen und nicht rechtzeitig angewendet werden, finden Sie im folgenden TechNet-Website:

Warnung: Dieser Artikel wurde automatisch übersetzt.

Eigenschaften

Artikelnummer: 2922898 – Letzte Überarbeitung: 10/04/2015 13:10:00 – Revision: 2.0

Microsoft SQL Server 2012 Enterprise

  • kbsurveynew kbtshoot kbexpertiseadvanced kbmt KB2922898 KbMtde
Feedback