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).
quelle
Antworten:
Zuallererst wenige Hauswirtschaftsregeln.
Wenn Sie zwei Links folgen, können Sie die Transaktionsprotokolldatei besser verwalten.
Was Sie erleben, ist kein normales Verhalten, wenn die Transaktionsprotokolldatei voll ist und nicht weiter wachsen kann.
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.
Gemäß dem Blog-Beitrag von Paul Randal sind Sie auf einen Fehler gestoßen, der in SQL 2012 SP4 behoben wurde.
Weitere Details zu Fehler 3314:
Referenz:
quelle
in normal conditions--wenn Sie für aktive Transaktion meinen, dann ja.In normal conditions= normale Datenbanknutzung, Tonnen von Benutzern, die Transaktionen starten, Einfügungen, Aktualisierungen, Löschungen, Festschreibungen und Rollbacks vornehmen. Das heißt, Benutzer zu sein.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.
quelle
Dies ist meine Einstellung zu Ihrem Problem:
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 .
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.
Dies wurde in Cumulative Update 8 für SQL Server 2012 SP2 behoben
also zum Mitnehmen:
quelle