it-swarm.com.de

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

Während des Wochenendes funktionierte eine von mir betriebene Website nicht mehr und zeichnete bei jeder Anforderung an die Website den folgenden Fehler in der Ereignisanzeige auf:

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, sodass ich RDP in den Server einbinden und herumstöbern kann. Die LDF -Datei für die Datenbank ist im C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA Ordner, aber der Versuch, über Management Studio mit der Datenbank zu arbeiten, führt zu einem Dialogfeld, in dem derselbe Fehler gemeldet wird - 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 abtrennte und dann ein Backup von vor ein paar Tagen wiederherstellte. Ich befürchte jedoch, dass dieser Fehler auf ein unheimlicheres Problem hinweist, nämlich einen Festplattenfehler.

Ich habe den Support des Webhosting-Unternehmens per E-Mail gesendet und dies war ihre Antwort:

Es scheint keine anderen Hinweise auf die Ursache im Ereignisprotokoll zu geben, daher ist es möglich, dass das Protokoll beschädigt wurde. Derzeit liegen die Ressourcen des Speichers bei 87%, was ebenfalls Auswirkungen haben kann, aber unwahrscheinlich ist.

Kann das Protokoll nur "beschädigt werden"?

Meine Frage : Was sind die nächsten Schritte, die ich unternehmen sollte, um dieses Problem zu diagnostizieren? Wie kann ich feststellen, ob dies tatsächlich ein Hardwareproblem ist? Und wenn ja, gibt es andere Optionen als das Ersetzen der Festplatte?

Vielen Dank

20
Scott Mitchell

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

Wahrscheinlich handelt es sich um ein Speicherproblem.

Wenn es erneut passiert, 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. Sie müssen die Datenbank wahrscheinlich im Notfallmodus online schalten, um checkdb für die Datenbank auszuführen.

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

16
mrdenny

Ich konnte dieses Problem lösen, indem ich die Datenbank in Management Studio offline schaltete und sie dann sofort wieder online stellte. dbcc checkdb hatte Fehler ausgelöst, die danach behoben wurden. Ich kann nicht sagen warum das hat nur funktioniert, dass es hat funktioniert.

8
Factor Mystic

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

5
Clarice Bouwer

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

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 ändern

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

1

Ich werde raten/hoffen, dass Sie einen Raid für die Festplatte Ihres SQL-Servers haben. Wenn Sie Hardwareprobleme vermuten, würde ich als erstes Ihre RAID-Wartungs-/Diagnosetools ausführen.

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

0
Thirster42

Ok, machen Sie im ersten Schritt eine Sicherungskopie Ihres Protokolls und Ihrer MDF-Dateien auf einem völlig anderen Laufwerk. SCHNELL! (Dateikopie)

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

Versuchen Sie als nächstes Folgendes. Trennen Sie die aktuelle Datenbank mithilfe Ihrer aktuellen Datenbank, wenn Sie können, und löschen Sie sie dann oder verschieben Sie sie an einen völlig anderen Speicherort auf der Festplatte. Fügen Sie dann die Datenbank erneut hinzu, und sie wird in der GUI 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. Wenn Sie es ohne Protokoll anhängen, wird es gezwungen, eine Protokolldatei für die Datenbank am Standardspeicherort zu erstellen.

Gib mir Bescheid.

0
Ryk

Gestern hatte ich den gleichen Fehler erhalten "Das Protokoll für die Datenbank '%' ist nicht verfügbar. Schwerwiegender Fehler 9001, Nachricht 21. Bitte wenden Sie sich an Ihren Administrator" -

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

0

Ja, ich habe auch das gleiche Problem, es betraf den TempDb-Fehler 9001, d. H. Das Protokoll ist nicht verfügbar. Wir haben die Dienste neu gestartet und alles war in Ordnung.

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

0
Bunny