Diagnose des Microsoft SQL Server-Fehlers 9001: Das Protokoll für die Datenbank ist nicht verfügbar

20

Über das Wochenende hat eine von mir ausgeführte Website die Funktion eingestellt und bei jeder Anforderung der Website den folgenden Fehler in der Ereignisanzeige aufgezeichnet:

Ereignis-ID: 9001

Das Protokoll für die Datenbank ' Datenbankname ' ist nicht verfügbar. Überprüfen Sie das Ereignisprotokoll auf verwandte Fehlermeldungen. Beheben Sie alle Fehler und starten Sie die Datenbank neu.

Die Website wird auf einem dedizierten Server gehostet, so dass ich in der Lage bin, RDP in den Server einzuspielen und herumzustöbern. Die LDFDatei für die Datenbank ist im C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATAOrdner vorhanden. Wenn Sie jedoch versuchen, mit der Datenbank von Management Studio aus zu arbeiten, wird in einem Dialogfeld der gleiche Fehler gemeldet - 9001: Das Protokoll für die Datenbank ist nicht verfügbar.

Dies ist das erste Mal, dass ich diesen Fehler erhalte, und ich hoste diese Site (und andere) seit über zwei Jahren auf diesem dedizierten Webserver.

Nach meinem Verständnis weist dieser Fehler auf eine beschädigte Protokolldatei hin. Ich konnte die Website wieder online stellen, indem ich die Datenbank getrennt und dann ein Backup von vor ein paar Tagen wiederhergestellt habe. Ich befürchte jedoch, dass dieser Fehler auf ein unheimlicheres Problem hinweist, nämlich einen Festplattenfehler.

Ich schickte eine E-Mail an den Support des Webhosting-Unternehmens und dies war die Antwort:

Das Ereignisprotokoll enthält anscheinend keine weiteren Hinweise auf die Ursache. Daher ist das Protokoll möglicherweise beschädigt. Gegenwärtig sind 87% der Speicherressourcen belegt, was sich ebenfalls auswirken kann, aber unwahrscheinlich ist.

Kann das Protokoll nur "beschädigt werden?"

Meine Frage: Was sind die nächsten Schritte, um dieses Problem zu diagnostizieren? Wie kann ich feststellen, ob es sich tatsächlich um ein Hardwareproblem handelt? Und wenn ja, gibt es Optionen, die über das Ersetzen der Festplatte hinausgehen?

Vielen Dank

sql-server-2008

— Scott Mitchell
quelle

16

Weit über 99% der Datenbankbeschädigungsprobleme betreffen das Speichersystem. Die Hälfte der verbleibenden Probleme ist auf schlechten Arbeitsspeicher zurückzuführen, die andere Hälfte sind Fehler in SQL Server.

Wahrscheinlich handelt es sich um ein Speicherproblem.

Wenn dies erneut auftritt, führen Sie DBCC CHECKDB für die Datenbank aus. Dadurch erhalten Sie weitere Informationen zur Beschädigung und können das Problem beheben, ohne eine Wiederherstellung durchzuführen. Möglicherweise müssen Sie die Datenbank im Notfallmodus online schalten, um checkdb für die Datenbank auszuführen.

Eine Speichernutzung von 87% hat nichts mit dem Problem zu tun. SQL Server führt den Arbeitsspeicher standardmäßig zu 100% (oder in der Nähe davon) aus.

— mrdenny
quelle

Danke für die Vorschläge. Eigentlich habe ich versucht, DBCC CHECKDB auszuführen, aber es sind viele Fehler aufgetreten, darunter der Fehler, dass die Protokolldatei nicht gefunden werden konnte. Ich habe jedoch nicht versucht, die DB im Notfallmodus online zu schalten.

— Scott Mitchell

Wenn das Transaktionslog beschädigt ist, ist es normalerweise eine ziemlich schlechte Sache. CHECKDB kann es möglicherweise reparieren oder nicht, je nachdem, wie stark die Beschädigung ist. Wenn Sie Transaktionsprotokollsicherungen haben (Ihr Provider lässt diese möglicherweise nicht zu), haben Sie möglicherweise fast keine Daten verloren. Am Ende der checkdb-Ausgabe steht die Reparaturstufe, die zur Behebung der Probleme mit den Datenbankdateien erforderlich ist.

— Mrdenny

Richtig. Die Speichernutzung hat damit nichts zu tun - es sei denn, der Speicher war beschädigt und wurde einfach auf die Festplatte übertragen. In beiden Fällen sollten in Ihren Ereignisprotokollen andere Hinweise auf E / A-Probleme angezeigt werden. Irgendwo.

— Michael K Campbell

Sie können versuchen, eine Checkdisk (chkdsk) für den Datenträger auszuführen, um festzustellen, ob Windows Probleme mit dem Datenträger feststellt. Möglicherweise müssen Sie die Festplatte ersetzen. Es könnte sich jedoch nur um einen Fehler im Code des Festplattencontrollers oder im BIOS der Festplatte handeln. In beiden Fällen würde ich versuchen, die Festplatten und / oder den Controller auszutauschen.

— Mrdenny

8

Ich konnte dieses Problem lösen, indem ich die Datenbank in Management Studio offline und dann sofort wieder online stellte. dbcc checkdbhatte Fehler geworfen, die danach behoben wurden. Ich kann nicht sagen , warum dies funktioniert nur , dass es tat Arbeit.

— Factor Mystic
quelle

5

Ich hatte dieses Problem kürzlich auch und nach Bergen der Forschung scheint es üblich zu sein, wenn eine Datenbank auf AUTO CLOSE eingestellt ist. Ich habe alle Datenbanken auf AUTO CLOSE = FALSE gesetzt. Dies begann mit einer Datenbank, ging dann auf zwei über und die nächste war auf allen. Ich habe einfach den SQL Server-Instanzdienst neu gestartet, anstatt die Datenbanken wiederherzustellen. Eine andere Möglichkeit, das Symptom zu beheben, besteht darin, die problematische Datenbank offline zu schalten und wieder online zu schalten.

— Clarice Bouwer
quelle

1

MS SQL schaltet die Protokolle einer betroffenen Datenbank offline, um eine Beschädigung der Datenbank zu vermeiden. Deshalb erhalten Sie den 9001-Fehler.

Wenn Sie die betroffene Datenbank offline / online schalten, aktiviert MS SQL die betroffenen Datenbankprotokolle, bis der Fehler erneut auftritt.

Eine andere Möglichkeit, dies zu lösen, besteht darin, die Option Auto_Close auf OFF zu setzen

http://sqlmag.com/blog/worst-practice-allowing-autoclose-sql-server-databases

— Saul A. Greco V.
quelle

0

Ich werde raten / hoffen, dass Sie ein Raid für die Festplatte Ihres SQL-Servers haben. Wenn Sie Hardwareprobleme vermuten, ist das allererste, was ich tun würde, Ihre RAID-Wartungs- / Diagnosetools auszuführen.

Die zweite Sache (wahrscheinlich gleichzeitig, wenn Sie können) ist die Ausführung von dbcc checkdb in der Datenbank (möglicherweise auch in Ihren Systemdatenbanken).

— Durst42
quelle

0

Ok, mach als erstes ein Backup deines Logs und deiner mdf-Dateien auf einem ganz anderen Laufwerk. SCHNELL! (Dateikopie)

Versuchen Sie auch, eine vollständige Datenbanksicherung durchzuführen.

Versuchen Sie als Nächstes Folgendes. Trennen Sie Ihre aktuelle Datenbank, wenn Sie die Protokolldatei löschen können, oder verschieben Sie sie an einen anderen Speicherort auf der Festplatte. Schließen Sie die Datenbank erneut an, und sie wird in der Benutzeroberfläche mit einer Protokolldatei angezeigt. Klicken Sie auf Entfernen (oder Löschen) für die Protokolldatei, damit sie nicht angezeigt wird, und klicken Sie dann auf OK. Durch das Anhängen ohne Protokoll wird erzwungen, dass eine Protokolldatei für die Datenbank am Standardspeicherort erstellt wird.

Gib mir Bescheid.

— Ryk
quelle

0

Ja, ich habe auch das gleiche Problem, es handelte sich um den tempDb-Fehler 9001, dh das Protokoll ist nicht verfügbar. Wir haben die Dienste neu gestartet und alles war in Ordnung.

Das Problem dahinter war das SAN- oder Speicherproblem, während der E / A-Schreibvorgang länger als 15 Sekunden nicht ausgeführt werden konnte.

— Hase
quelle

0

Ich hatte gestern den gleichen Fehler erhalten: "Das Protokoll für die Datenbank '%' ist nicht verfügbar. Schwerwiegender Fehler 9001, Meldung 21. Bitte wenden Sie sich an Ihren Administrator."

Problemumgehung - Ich habe die 'TempDB' überprüft, aber auf die restlichen Systemdatenbanken konnte nicht auf diese zugegriffen werden. Bevor ich mich für die Reparaturoption entschieden habe, habe ich einfach die SQL-Dienste für diese Instanz neu gestartet und das Problem wurde behoben :) :)

— Poonam Choudhary
quelle

-2

Ich habe gesehen, dass dies passiert, wenn kein Speicherplatz für die Protokollerweiterung verfügbar ist. können Sie überprüfen, ob auf dem C: \ ausreichend Speicherplatz vorhanden ist und ob Ihre Protokolle verwaltet werden, dh, Sie werden gesichert, wenn Sie sich im vollständigen Wiederherstellungsmodus befinden.

Ich würde Ihre Ldf's (und MDF's) vom Boot-Volume entfernen, wenn Sie die Option haben.

— SqlACID
quelle

Wenn der Festplattenspeicher nicht ausreicht, wird die Datenbank NIEMALS beschädigt, es sei denn, Sie verwenden Thin Provisioned Storage und der Basisspeicher verfügt nicht über genügend Speicherplatz. Aber das ist ein ganz anderer Albtraum.

— Mrdenny

Ich werde es umformulieren. Es kann sein, dass die Datenbank nicht beschädigt ist, aber es ist sicher ein Grund dafür, dass Protokolldateien nicht verfügbar sind, wie in der Op angegeben.

— SqlACID

1

Das Laufwerk verfügt über mehr als 25 GB freien Speicherplatz, und die betreffende Datenbank ist weniger als 25 MB groß.

— Scott Mitchell

Der einzige Fehler, den Sie jemals sehen werden, wenn der Speicherplatz knapp wird, ist ein Dateifehler, wenn Sie versuchen, Zeilen in der Datenbank zu ändern, da die Transaktion nicht in das Protokoll geschrieben werden kann (nicht das, was das OP angibt). Wenn der Speicherplatz knapp wird, ist die Datenbank nicht mehr verfügbar (wie vom OP angegeben).

— Mrdenny

Nicht zustimmen. Auf dem Laufwerk, auf dem sich die Protokolldatei befand, war nicht mehr genügend Speicherplatz vorhanden, und es stellte sich genau das gleiche Problem heraus.

— ADNow