Update: Fehler 9002 und Fehler 3052 Wenn versuchen hinzufügen oder Protokolldatei 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: 3095156
Problembeschreibung
Angenommen Sie, Sie AlwaysOn Availability Group in einer Microsoft SQL Server 2012-Datenbank verwenden und eine große offene aktive Transaktion vorhanden und erfordert zusätzlichen Speicherplatz. Wenn die Protokolldatei die folgenden Gründe wachsen kann nicht, schlägt die Transaktion.
  • Mangelnde zusätzlichen Speicherplatz
  • Die Protokolldatei sieht nicht wachsen
  • Die Protokolldatei hat die konfigurierte maximale Größe erreicht.
Darüber hinaus wird die folgende Fehlermeldung angezeigt:
Fehler 9002, Schweregrad: 17, Status: 9.
Die Protokolldatei für Datenbank 'Name der Datenbank> "vollständige durch 'LOG_BACKUP' ist.
Nach dem Ausführen einer Sicherung wird eine weitere Fehlermeldung 9002:
Fehler 9002, Schweregrad: 17, Status: 9.
Die Protokolldatei für Datenbank 'Name der Datenbank> "vollständige durch 'ACTIVE_TRANSACTION' ist.
Nach anderen protokollsicherung Fehlermeldung dann anderen 9002 gefolgt von einer Fehlermeldung 5901:
Fehler 9002, Schweregrad: 17, Status: 9.
Die Protokolldatei für Datenbank 'Name der Datenbank> "vollständige durch 'AVAILABILITY_REPLICA' ist.

Einen Checkpoint-Datensatz konnte nicht in die Datenbank geschrieben werden.Name der Datenbank> das Protokoll voll ist. Wenden Sie sich an den Datenbankadministrator, um das Protokoll abzuschneiden oder mehr Speicherplatz in der Datenbank-Protokolldateien.
Fehler: 5901, Schweregrad: 16, Status: 1.
Ein oder mehrere Recovery Produktionseinheiten Datenbank 'Name der Datenbank> ' Fehler beim Generieren eines Checkpoints. Dies wird normalerweise durch mangelnde Systemressourcen wie Datenträger oder oder in einigen Fällen durch eine Beschädigung der Datenbank verursacht. Überprüfen Sie vorherige Einträge im Fehlerprotokoll Ausführlichere Informationen zu diesem Fehler.
Bei nachfolgenden Prüfpunkt oder Log Backups dann beim Rollback der Transaktion kann die folgende Fehlermeldung angezeigt:
Msg 3052, Ebene 16, Status 1, Zeile 4
BACKUP LOG konnte sich Updates für Datenbank 'Name der Datenbank>'. Nachfolgende Sicherungen müssen Sicherungsort aus wechseln "LSN-Id 1> ' 'LSN Id 2> ' Protokollspeicherplatz für Eintrag vorgenommen wurde.
Wenn diese Nachrichten empfangen, Sie können keine neuen Transaktionen an die Datenbank senden und nicht anwachsen die Protokolldatei oder eine weitere Protokolldatei hinzuzufügen.

Lösung
Das Problem wurde erstmals das folgende kumulative Update von SQL Server behoben: Empfehlung: Installieren Sie das neueste kumulative Update für SQL Server
Jeder neues Kumulatives Update für SQL Server enthält alle Hotfixes und alle die Sicherheitsupdates wurden in das vorherige kumulative Update enthalten. Herunterladen und Installieren der neuesten kumulativen Updates für SQL Server empfohlen:
Abhilfe
Das folgende Verfahren können Sie Abschneiden der Protokolle und Aktivitäten fortsetzen.
  1. Überprüfen Sie jedes sekundäre Replikat sekundäre Replikat Last_hardened_lsn (Siehe überprüfen Sys.dm_hadr_database_replica_states) primäres Replikat Last_hardened_lsnentspricht. Hierzu können Sie mit die folgende Abfrage ist die primären Instanz verbunden
    SELECT ags.name as AGGroupName,    ar.replica_server_name as InstanceName,    hars.role_desc,    db_name(drs.database_id)as DBName,    drs.last_hardened_lsn, drs.log_send_queue_size,    drs.synchronization_state_desc as SyncState,    ar.availability_mode_desc as SyncMode,    CASE drs.is_local WHEN 1 THEN drs.database_id ELSE NULL END as database_id    FROM sys.dm_hadr_database_replica_states drs    LEFT JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id    LEFT JOIN sys.availability_groups ags  ON ar.group_id = ags.group_id    LEFT JOIN sys.dm_hadr_availability_replica_states hars        ON ar.group_id = hars.group_id and ar.replica_id = hars.replica_id      WHERE db_name(drs.database_id) = '<database name>'
  2. Primäres Replikat
    • Entfernen Sie die Datenbank aus der Availability Group.
    • Der Availability Group erneut die Datenbank hinzufügen.
  3. Jede sekundäre Replikat
    • Der Availability Group erneut die Datenbank hinzufügen.
Entfernen Sie die Datenbank aus der Availability Group, wird sofort Abschneiden der Protokolle und Speicherplatz freizugeben.

Last_hardened_lsnauf den sekundären Replikaten entspricht primäres Replikat und keine Sicherungen erfolgen Zeit Availability Group die Datenbank aufheben und erneut die Datenbank auf jeden sekundären werden sekundäre Replikat erfolgreich erneut ohne Fehler oder Wiederherstellung der Sicherungskopien auf dem sekundären Server hinzugefügt.

Wenn sekundäre Replikat nicht mit der primären Kopie ist und die Datenbank Verfügbarkeit Gruppe entfernen, bevor der sekundären ermitteln kann, möglicherweise, dass sekundäre Replikat Sicherungskopien wiederhergestellt einzuholen, bevor erneut Verfügbarkeit Gruppe hinzufügen oder löschen Sie die Datenbank auf dem sekundären Replikat und erneutes Seeding mit einer vollständigen und Sicherung des Transaktionsprotokolls Datenbank haben.
Status
Microsoft hat bestätigt, dass es sich um ein Problem bei den Microsoft-Produkten handelt, die im Abschnitt "Eigenschaften" aufgeführt sind.

Warnung: Dieser Artikel wurde automatisch übersetzt.

Eigenschaften

Artikelnummer: 3095156 – Letzte Überarbeitung: 09/22/2015 02:56:00 – Revision: 1.0

Microsoft SQL Server 2012 Service Pack 2

  • kbqfe kbsurveynew kbfix kbexpertiseadvanced kbmt KB3095156 KbMtde
Feedback