Die Datenbank wechselt jedes Mal in den Wiederherstellungsmodus, wenn das Transaktionsprotokoll voll ist

Ich stehe vor einer Situation, die nur schwer anzugehen ist. Ich brauche Hilfe, um zu verstehen, was passiert.

TL; DR : Jedes Mal, wenn das Transaktionsprotokoll in SQL Server voll ist, muss die Datenbank heruntergefahren werden, um in den Wiederherstellungsmodus zu gelangen und die fehlerhaften Transaktionen zurückzusetzen. Ist das immer getan durch Design oder dies geschieht nur , wenn etwas Schlimmes passiert?

Das Szenario:

Eine unserer häufig genutzten Produktionsdatenbanken, in der mehrere ETL-Jobs und lange laufende Tabellenstapel ausgeführt werden, wurde in den Wiederherstellungsmodus versetzt und war für einige Zeit nicht mehr zugänglich. Dies geschah diese Woche dreimal (dieser Server ist seit ca. 2 Jahren eingeschaltet, und wir haben dieses Problem in der Vergangenheit nicht bemerkt).

In den Fehlerprotokollen wurde klar, was passiert ist: Das Transaktionsprotokoll war voll, die Datenbank musste zum Rollback der Transaktion benötigt werden, das Rollback schlug fehl, die Datenbank wurde heruntergefahren und im Wiederherstellungsmodus gestartet.

Der DBA verteidigt dies als normales Verhalten von SQL Server. Das heißt, nach ihm, jedesmal , wenn das Transaktionsprotokoll voll ist und eine Transaktion muss die Datenbank - Rollback wird im Wiederherstellungsmodus betreten aufgrund des Fehlens von Log - Raum. Nach dem Rollback (der laut ihm nur im Wiederherstellungsmodus durchgeführt werden kann) wird die Datenbank wieder verfügbar.

Ich habe keine Referenz für diese Information gefunden. Also stimme ich überhaupt nicht zu. Ich würde mich sehr freuen, wenn mich jemand davon überzeugen würde, dass ich falsch liege.

Mein Punkt:

Meines Wissens ist ein DBMS zum Verwalten / Ausführen von Abfragen erstellt. Wenn nicht genügend Speicherplatz vorhanden ist, schlägt die Abfrage fehl. Einfach wie es ist. Und ich spreche nicht von der Leistung von irgendetwas anderem, sondern nur von der Verfügbarkeit.

Es macht für mich keinen Sinn zu akzeptieren, dass ein DBMS von Natur aus heruntergefahren werden muss, um eine Transaktion zurückzusetzen. Nach meinem Verständnis spielt es keine Rolle, ob ich Tonnen von Abfragen ausführe oder ob die Abfragen schlecht gestaltet sind. Die schlechten Abfragen sollten fehlschlagen und das Leben geht weiter. Nicht wahr?

Ich vermute, dass etwas anderes zum Scheitern führt, und ich muss nachverfolgen, was passiert.

Ist mein Verständnis falsch oder funktioniert SQL Server wirklich so? Angenommen, ich liege nicht falsch. Was kann ich noch tun, um die Ursache dieses Problems zu ermitteln?

Einige zusätzliche Informationen

• select @@version: Microsoft SQL Server 2012 (SP1) - 11.0.3156.0 (X64) 4. Mai 2015 18:48:09 Copyright (c) Microsoft Corporation Standard Edition (64-Bit) unter Windows NT 6.2 (Build 9200 :)
• Diese Datenbank befindet sich im einfachen Wiederherstellungsmodell.
• In derselben Instanz befinden sich andere Datenbanken. Sie stellen nicht das gleiche Problem dar, werden aber auch nicht häufig verwendet.
• Nur das Transaktionsprotokoll ist voll, nicht die Festplatte. Die Festplatte verfügt über ausreichend Speicherplatz, die Protokollgröße für die Datenbank ist jedoch begrenzt.
• Wir überwachen diesen Server, die CPU-Auslastung ist in Ordnung, die Speichernutzung ist in Ordnung, die Festplatten verwenden RAID-5 und der Controller weist keine Abstürze oder Lesefehler auf. Es gibt einige Spitzen in der Ressourcennutzung, aber nichts Ungewöhnliches.
• Ich weiß, dass die Abfragen verbessert werden können, um das Protokoll effizient zu nutzen. Ich weiß auch, dass ich den Transaktionsprotokollbereich vergrößern kann. Aber das ist hier wirklich nicht mein Punkt.
• Ein DBA wurde kürzlich beauftragt, sich um diese Datenbank zu kümmern. Daher wurden kürzlich einige Konfigurationen zu Optimierungszwecken geändert. Er machte mich auf alle Änderungen aufmerksam (z. B. Deaktivieren der automatischen Verkleinerung, Vergrößerung der automatischen Vergrößerung usw.). Ich habe nichts gefunden, was der Datenbank schaden könnte.

Protokollspeicherauszug (in der Reihenfolge des Auftretens wurden Duplikate entfernt)

[02:58:37am ~ 04:47:42pm, 12 times]Fehler: 845. Schweregrad: 17. Status: 1. Beim Warten auf Puffer-Latch Typ 3 für Seite (1: 8728760) ist eine Zeitüberschreitung aufgetreten. Datenbank-ID 7. FlushCache: 10460 Bufs mit 6709 Schreibvorgängen in 77540 ms bereinigt (864 neue Dirty Bufs vermieden) für db 7: 0 durchschnittlicher Durchsatz: 1,05 MB / s. E / A-Sättigung: 107. Kontextwechsel 391 Letztes ausstehendes Ziel: 4800. avgWriteLatency 0 FlushCache: 95448 Bufs mit 37560 Schreibvorgängen in 85820 ms (60465 neue Dirty Bufs vermieden) für DB 7: 0 durchschnittlicher Durchsatz: 8,69 MB / s bereinigt. E / A-Sättigung: 17026. Kontextschalter 20713 Letztes ausstehendes Ziel: 446. avgWriteLatency 3.

[02:58:37am ~ 04:47:42pm, 13 times]Beim Warten auf die Pufferverriegelung ist eine Zeitüberschreitung aufgetreten - Typ 3. bp 000000109B9E69C0. Seite 1: 73430228. stat 0x10b. Datenbank-ID: 7. ID der Zuordnungseinheit: 72057594304790528. Task 0x00000008BC0850C8: 1. Wartezeit 300 Sekunden. Flags 0x100000001a. Besitzaufgabe 0x0000000827B38188. Nicht weiter warten.

[02:58:37am ~ 04:47:42pm, 12 times]Fehler: 5901. Schweregrad: 16. Status: 1. Eine oder mehrere Wiederherstellungseinheiten der Datenbank 'XXXXXXXXXX' konnten keinen Prüfpunkt generieren. Dies wird normalerweise durch einen Mangel an Systemressourcen wie Festplatte oder Speicher oder in einigen Fällen durch eine Beschädigung der Datenbank verursacht. Untersuchen Sie frühere Einträge im Fehlerprotokoll, um detailliertere Informationen zu diesem Fehler zu erhalten.

[05:14:29pm ~ 05:14:53pm, 9 times] Fehler: 9002. Schweregrad: 17. Status: 4. Das Transaktionsprotokoll für die Datenbank 'XXXXXXXXXX' ist aufgrund von 'ACTIVE_TRANSACTION' voll.

[05:14:53pm, once]Fehler: 3314. Schweregrad: 21. Status: 3. Die Datenbank XXXXXXXXXX wurde aufgrund des Fehlers 3314 in der Routine 'XdesRMReadWrite :: RollbackToLsn' heruntergefahren. Ein Neustart für Nicht-Snapshot-Datenbanken wird versucht, nachdem alle Verbindungen zur Datenbank abgebrochen wurden.

[05:14:53pm ~ 05:14:53pm, 16 times]Fehler: 3314. Schweregrad: 21. Status: 3. Beim Rückgängigmachen eines protokollierten Vorgangs in der Datenbank 'XXXXXXXXXX' ist ein Fehler bei der Protokolldatensatz-ID (8064074: 20971: 110) aufgetreten. In der Regel wird der spezifische Fehler zuvor als Fehler im Windows-Ereignisprotokolldienst protokolliert. Stellen Sie die Datenbank oder Datei aus einer Sicherung wieder her oder reparieren Sie die Datenbank.

[05:14:53pm ~ 05:14:53pm, 9 times]Fehler: 9001. Schweregrad: 21. Status: 5. Das Protokoll für die Datenbank 'XXXXXXXXXX' ist nicht verfügbar. Überprüfen Sie das Ereignisprotokoll auf verwandte Fehlermeldungen. Beheben Sie alle Fehler und starten Sie die Datenbank neu.

[05:14:58, once] Starten der Datenbank 'XXXXXXXXXX'.

[05:15:02, once]Die Wiederherstellung der Datenbank 'XXXXXXXXXX' (7) ist zu 0% abgeschlossen (ca. 2931 Sekunden verbleiben). Phase 1 von 3. Dies ist nur eine Informationsnachricht. Es ist keine Benutzeraktion erforderlich.

...

[05:51:01pm, once]6 Transaktionen wurden in der Datenbank 'XXXXXXXXXX' (7: 0) zurückgesetzt. Dies ist nur eine Informationsnachricht. Es ist keine Benutzeraktion erforderlich.

[05:51:01pm, once]Bei der Wiederherstellung wird ein Prüfpunkt in die Datenbank 'XXXXXXXXXX' (7) geschrieben. Dies ist nur eine Informationsnachricht. Es ist keine Benutzeraktion erforderlich.

[05:56:47pm, once]Wiederherstellung für Datenbank XXXXXXXXXX (Datenbank-ID 7) in 2505 Sekunden abgeschlossen (Analyse 1774 ms Wiederherstellen 406623 ms Rückgängigmachen 1749182 ms) Dies ist nur eine Informationsnachricht. Es ist keine Benutzeraktion erforderlich.

Ich habe keine anderen relevanten Protokolleinträge im Fehlerprotokoll oder in der Ereignisanzeige gefunden. Der nächste Fehler, der in der Ereignisanzeige auftritt, ist:

[04:56:45pm ~ 05:27:24pm, 13 times]Die anwendungsspezifischen Berechtigungseinstellungen gewähren dem Benutzer MY_DOMAIN \ dba keine lokale Aktivierungsberechtigung für die COM Server-Anwendung mit CLSID {FDC3723D-1588-4BA3-92D4-42C430735D7D} und APPID {83B33982-693D-4824-B42E-7196AE61BB05}. personal.user SID (S-1-5-21-000000000-000000000-0000000000-00000) von der Adresse LocalHost (Using LRPC), die im Anwendungscontainer ausgeführt wird Nicht verfügbare SID (nicht verfügbar). Diese Sicherheitsberechtigung kann mit dem Verwaltungstool Component Services geändert werden.

Dieser Fehler trat ungefähr 18 Minuten vor dem Start des Wiederherstellungsprozesses durch die Datenbank auf und wurde manchmal zu Beginn der Wiederherstellung wiederholt. Es hat etwas mit dem DBA-Benutzer zu tun, aber ich weiß wirklich nicht, was es ist (ich hatte noch keine Zeit, nach dem DBA zu fragen).

Zuallererst wenige Hauswirtschaftsregeln.

• Sie (oder Ihr DBA) sollten den Transaktionsprotokollbereich abhängig von Ihrem Wiederherstellungsmodell verwalten.
• Lassen Sie das Transaktionsprotokoll nicht vollständig werden und beeinträchtigen Sie die Verfügbarkeit Ihrer Datenbank / Anwendung.

Wenn Sie zwei Links folgen, können Sie die Transaktionsprotokolldatei besser verwalten.

• Handbuch zur Architektur und Verwaltung des SQL Server-Transaktionsprotokolls
• Wie löscht man das SQL Server-Transaktionsprotokoll? Beantwortet von Aaron Bertrand, der auch einige großartige Ressourcen zu Transaktionsprotokollproblemen auflistete.

Was Sie erleben, ist kein normales Verhalten, wenn die Transaktionsprotokolldatei voll ist und nicht weiter wachsen kann.

Wenn das Transaktionsprotokoll voll ist, gibt SQL Server Database Engine einen 9002-Fehler aus. Das Protokoll kann gefüllt werden, wenn die Datenbank online ist oder sich in der Wiederherstellung befindet. Wenn das Protokoll gefüllt wird, während die Datenbank online ist, bleibt die Datenbank online, kann jedoch nur gelesen und nicht aktualisiert werden. Wenn das Protokoll während der Wiederherstellung gefüllt wird, markiert das Datenbankmodul die Datenbank als RESOURCE PENDING. In beiden Fällen ist eine Benutzeraktion erforderlich, um den Protokollspeicherplatz verfügbar zu machen.

Die angemessene Antwort auf ein vollständiges Transaktionsprotokoll hängt teilweise davon ab, unter welchen Bedingungen das Protokoll gefüllt wurde. Verwenden Sie die Spalten log_reuse_wait und log_reuse_wait_desc in der Katalogansicht sys.database, um herauszufinden, was das Abschneiden von Protokollen in einem bestimmten Fall verhindert.

Was Sie sehen, ist ein Fehler beim Transaktions-Rollback. Für weitere Details lesen Sie diesen Beitrag.

• INF: Was passiert mit einer Datenbank, wenn das Transaktions-Rollback fehlschlägt?

Gemäß dem Blog-Beitrag von Paul Randal sind Sie auf einen Fehler gestoßen, der in SQL 2012 SP4 behoben wurde.

• 2012/2014 Fehler, der dazu führen kann, dass Datenbank oder Server offline geschaltet werden

Weitere Details zu Fehler 3314:

• Fehlerbehebung Fehler 3313, 3314, 3414 oder 3456 (SQL Server)

Referenz:

• Fehlerbehebung bei einem vollständigen Transaktionsprotokoll (SQL Server-Fehler 9002)

Das erste und wichtigste ist, dass sich Ihre Datenbank bereits im einfachen Wiederherstellungsmodus befindet, sodass das Protokoll erst dann stark wächst, wenn es von einer einzelnen Transaktion aufgehalten wird. Sobald der Prüfpunkt erreicht ist, wird das Protokoll selbst abgeschnitten. Nachdem Sie die Protokollgröße begrenzt haben, führt SQL Server einen Wurf durch, wenn sich die Transaktion in der Mitte befindet und kein Protokollbereich mehr vorhanden ist. Einfach gehalten, benötigt die Transaktion das Protokoll, um zu wachsen. Sie können die Transaktionen nicht abschließen, ohne dass die Protokolle bei Bedarf erweitert werden. Aus diesem Grund ist es am besten, die AUTOGROWTH aktiviert zu lassen.

SQL Server behandelt dies als Absturz und führt dann eine Wiederherstellung durch, um die unvollständigen Befehle, wie im Fehlerprotokoll angezeigt, zurückzusetzen.

Lösung: Aktivieren Sie das AUTOGROWTH. Wenn dies eine wichtige Datenbank ist, wechseln Sie in den vollständigen Wiederherstellungsmodus und konfigurieren Sie Protokollsicherungen.

Dies ist meine Einstellung zu Ihrem Problem:

Microsoft SQL Server 2012 (SP1) - 11.0.3156.0

Dies ist ein ziemlich alter Build und viele Korrekturen wurden in neuere SPs eingefügt. Sie sollten Ihren Server mit SP4 atleast - 11.00.7001 patchen .

Fehler: 845. Schweregrad: 17. Status: 1.

Dies ist Ihr Festplattensubsystem, das Probleme verursacht. Überprüfen Sie Ihren Ordner \ MSSQL \ LOG \ sqldump . Sie werden Stack-Dumps erstellen lassen. Sie können es gemäß dem Zeitlimit für SQL Server Latch & Debugging-Latch analysieren oder einen Fall mit Microsoft eröffnen. Überprüfen Sie erneut Ihr Festplattensubsystem.

Fehler: 5901. Schweregrad: 16. Status: 1

Dies wurde in Cumulative Update 8 für SQL Server 2012 SP2 behoben

also zum Mitnehmen:

• Patchen Sie mit SP4 und prüfen Sie, ob Probleme auftreten.
• Erkundigen Sie sich bei Ihrem Windows- oder Speicheradministrator nach Festplattenkonflikten.
• Stellen Sie sicher, dass Sie über genügend RAM verfügen und der maximale Speicher entsprechend eingestellt ist.
• Der CPU-Leistungsplan ist auf hohe Leistung im Gegensatz zu ausgeglichen eingestellt.
• Aktivieren Sie das automatische Wachstum auf feste MB, damit die Datenbank entsprechend wachsen kann.
• Führen Sie sp_Blitz aus, um mögliche Probleme zu identifizieren .