Datenbank im Status Recovery Pending

Die Datenbank kommt nach dem Neustart nicht hoch. ERRORLOG-Diagnose, die vier häufigsten Ursachen und die sichere Lösungssequenz — ohne reflexhafte Reparatur.

Es ist Sonntagvormittag, 11:17 Uhr, kurz nach einem geplanten Wartungs-Neustart des Servers bei der Trendforge Digital GmbH. Eigentlich Routine — Updates eingespielt, Maschine neu gestartet, alles sollte wie immer hochkommen. Doch im Management Studio steht neben einer der wichtigsten Datenbanken nicht das gewohnte grüne Symbol, sondern ein nüchternes, beunruhigendes Wort in Klammern: (Recovery Pending). Die Datenbank ist da, aber sie ist nicht da — kein Zugriff, keine Abfragen, nichts. Und während sich der erste Gedanke an Korruption und verlorene Daten festsetzt und jemand schon das letzte Backup sucht, ist die Wahrheit meist viel harmloser: Die Daten sind höchstwahrscheinlich völlig in Ordnung. Der Server kommt nur gerade nicht an sie heran.

Willkommen bei einem Notfall aus dem SQL-Server-Notarztwagen (die Triage-Übersicht liegt unter /sql-server-notarztwagen/), der dramatischer aussieht, als er fast immer ist. Recovery Pending klingt nach Datenverlust, ist aber in der Regel ein reines Zugriffsproblem — eine Datei, die der Server nicht öffnen kann. Dieser Beitrag zeigt dir, wie du über das ERRORLOG in Minuten die genaue Ursache findest, die vier häufigsten Fälle und ihre sichere Lösung — und vor allem den einen Reflex, der hier echten Schaden anrichtet: das voreilige Reparatur-Werkzeug, das Daten wegwirft, die kerngesund sind.

Was „Recovery Pending“ technisch bedeutet

Um den Status zu verstehen, muss man wissen, was beim Hochfahren einer Datenbank passiert. Bei jedem Start durchläuft jede Datenbank die Recovery — einen Prozess, der das Transaktionslog auswertet, abgeschlossene Transaktionen nachzieht (Redo) und unvollständige zurückrollt (Undo), um die Datenbank in einen konsistenten Zustand zu bringen. Erst danach ist sie online und nutzbar. Der Status RECOVERY_PENDING bedeutet nun etwas sehr Spezifisches: Der Server konnte diese Recovery nicht einmal beginnen. Er ist gar nicht so weit gekommen, das Log auszuwerten — er hängt schon einen Schritt davor, weil ihm eine Voraussetzung fehlt, meist der Zugriff auf eine benötigte Datei.

Diese Unterscheidung ist der Schlüssel zum ganzen Notfall — und der Grund, warum er meist harmlos ist. Weil die Recovery nicht gestartet wurde, hat der Server auch nichts an den Daten verändert oder als beschädigt erkannt. Die Daten selbst sind in aller Regel völlig intakt; sie liegen unversehrt auf der Platte, der Server kommt nur gerade nicht an sie heran. Das ist ein fundamentaler Unterschied zum Status SUSPECT, bei dem die Recovery begonnen und dabei einen schweren Fehler gefunden hat — dort geht es um inhaltliche Korruption. Recovery Pending ist „komme nicht ran“, Suspect ist „ist beschädigt“. Wer beide verwechselt, greift zu völlig falschen Werkzeugen.

Die Ursachen für „komme nicht ran“ sind erfreulich überschaubar und fast immer physischer Natur: Eine Datendatei oder das Log fehlt am erwarteten Ort, weil sie verschoben oder gelöscht wurde; ein Laufwerk oder Mount-Point ist offline (gerade nach einem Neustart ein Klassiker, wenn die Reihenfolge nicht stimmte); dem SQL-Service-Account fehlt die Berechtigung auf die Datei; oder das Storage hatte einen kurzen Aussetzer. In jedem dieser Fälle lautet die Behandlung nicht „repariere die Datenbank“, sondern „stelle den Zugriff wieder her“ — und das ist ein riesiger Unterschied in Aufwand und Risiko.

Die Ursachen-Verzweigung

Bei Recovery Pending führt der Weg über das ERRORLOG zu einer von vier Ursachen — und jede hat ihre klare Maßnahme. Die folgende Skizze zeigt die Verzweigung, den Rückkehr-Befehl und die zwei Dinge, die du nicht verwechseln darfst:

Die Skripte: Ursache finden und sicher zurückholen

Schritt 1 — Status und erwartete Dateipfade prüfen

Zuerst die Bestandsaufnahme: Welche Datenbank ist betroffen, und wo sollten ihre Dateien liegen? sys.master_files verrät die Pfade auch bei offline-Datenbanken:

Den ErwarteterPfad gleichst du jetzt mit der Realität ab: Existiert die Datei dort? Ist das Laufwerk eingebunden? Diese Diskrepanz zwischen Soll und Ist ist oft schon die halbe Diagnose.

Schritt 2 — Das ERRORLOG nach dem genauen Grund fragen

Das ERRORLOG nennt beim Hochfahren die konkrete Datei und den genauen Fehler — die zweite Hälfte der Diagnose:

Schritt 3 — Nach behobener Ursache zurückholen

Ist der Zugriff wiederhergestellt, holt SET ONLINE die Recovery nach, die der Server vorher nicht starten konnte — und die Datenbank kommt meist mit diesem einen Befehl sauber zurück. Genau das ist der Lohn der richtigen Diagnose: keine Reparatur, kein Datenverlust, nur der wiederhergestellte Zugriff.

Die vier häufigsten Ursachen

Recovery Pending hat fast immer einen dieser vier Gründe — alle physisch, alle ohne Datenverlust lösbar:

1. Datei fehlt oder Laufwerk offline

Der häufigste Fall, besonders nach einem Neustart: Eine Daten- oder Logdatei liegt nicht am erwarteten Ort, weil das Laufwerk nicht (rechtzeitig) eingebunden wurde, der Pfad sich änderte oder die Datei verschoben wurde. Lösung: das Laufwerk einbinden bzw. die Datei zurücklegen — oder, bei dauerhaftem neuen Ort, den Pfad per MODIFY FILE korrigieren —, dann SET ONLINE.

2. Fehlende Berechtigung des Service-Accounts

Der Account, unter dem der SQL-Dienst läuft, hat keine NTFS-Rechte auf die Datei (operating system error 5 im ERRORLOG). Tritt gern nach Migrationen, Storage-Umbauten oder neu eingebundenen Laufwerken auf. Lösung: dem Dienstkonto volle Rechte auf die Daten- und Log-Ordner geben, dann SET ONLINE.

3. Logdatei unerreichbar oder kein Platz

Fehlt die Logdatei oder ist kein Platz für die Recovery da, kann der Server die Wiederherstellung nicht starten. Lösung: den Log-Pfad oder das Speicherproblem beheben; nur in seltenen, gut verstandenen Fällen ist das Neuaufbauen des Logs ein Thema — und das gehört nicht zu den ersten Schritten, sondern in fachkundige Hände.

4. Storage-Aussetzer

Das SAN oder die Disk war zum Startzeitpunkt kurz nicht verfügbar und ist jetzt wieder da. Hier reicht oft ein SET ONLINE, sobald das Storage stabil erreichbar ist. Aber: Ein Storage-Aussetzer ist ein Warnsignal — wenn er sich wiederholt, liegt das eigentliche Problem unter dem SQL Server, und das gehört untersucht, bevor es zu einem ernsteren Schaden führt.

Was du auf keinen Fall tun solltest

Nachsorge: damit es nicht wiederkommt

Ein Recovery Pending ist fast immer ein Hinweis auf eine Schwachstelle in der Infrastruktur — und die schließt man in der Nachsorge. Drei Schritte: Erstens, die Abhängigkeit von Laufwerken und Mount-Points prüfen: Kommen die Storage-Volumes beim Neustart zuverlässig und rechtzeitig vor dem SQL-Dienst hoch? Eine falsche Start-Reihenfolge ist die häufigste Ursache des „nach dem Neustart war sie plötzlich Recovery Pending“. Zweitens, die Berechtigungen des Service-Accounts dokumentieren und nach jeder Storage-Änderung kontrollieren — gerade bei Migrationen gehen sie gern verloren. Drittens, bei einem Storage-Aussetzer der Ursache nachgehen: Ein einmaliger Aussetzer mag Zufall sein, ein wiederkehrender ist ein ernstes Warnsignal aus dem Storage-Subsystem. Und über allem steht: ein geprüftes Backup, das im echten Ernstfall (wenn es doch einmal Korruption ist) den sicheren Weg zurück bietet.

Vertiefung in der Buchreihe

Datenbank-Status, Recovery-Mechanik und die Infrastruktur darunter füllen in der Buchreihe „SQL Server in der Praxis“ eigene Kapitel — alle Bände in der Übersicht auf der SQL-Pillar-Seite unter /sql-server/.

Verwandte Notfälle im Notarztwagen

Recovery Pending hat enge Nachbarn — diese Beiträge sind die nächste Station:

Drei Wege, wenn die Datenbank jetzt Recovery Pending zeigt

Akut-Hotline

Wenn die Datenbank in diesem Moment im Status Recovery Pending hängt und der Betrieb wartet: anrufen. Halte zwei Dinge bereit — die Meldung aus dem ERRORLOG rund um die betroffene Datenbank (besonders einen „operating system error“-Code) und die erwarteten Dateipfade aus sys.master_files. Mit diesen Informationen ist die Ursache meist in Minuten klar, und die Lösung läuft fast immer auf das Wiederherstellen des Zugriffs und ein SET ONLINE hinaus — ganz ohne die riskanten Reparatur-Werkzeuge, die intakte Daten gefährden.

Festpreis-Analyse

Wenn nach Neustarts oder Storage-Änderungen immer wieder Datenbanken in Recovery Pending landen und du die strukturelle Ursache abstellen willst? Die Festpreis-Analyse liefert sie: Ich prüfe die Storage- und Mount-Abhängigkeiten, die Start-Reihenfolge, die Service-Account-Berechtigungen und die Datei-Layouts — und liefere einen Bericht mit priorisierten Maßnahmen, die den nächsten Schreck nach dem Neustart verhindern. Zum vereinbarten Festpreis, ohne Stundenzähler.

Selbst-Diagnose-Kit

Für alle, die den nächsten Recovery-Pending-Fall selbst sicher lösen wollen: Das Diagnose-Kit bündelt die Skripte aus diesem Beitrag — Status- und Pfad-Prüfung über sys.master_files, die ERRORLOG-Suche, den Rückhol-Ablauf mit SET ONLINE — plus die Ursachen-Verzweigung zum Ausdrucken und eine Tabelle, die jeden „operating system error“-Code seiner Ursache zuordnet. Damit liest du den Befund und handelst gezielt, statt zum gefährlichen Reparatur-Werkzeug zu greifen.

Häufige Fragen (FAQ)

Diese Sektion ist auf häufige Suchanfragen abgestimmt. Sie hilft dir, schnell den Punkt zu finden, der dir gerade akut weiterhilft — und sie ist gleichzeitig die Eingabe für das FAQPage-Schema auf der Seite.

Was bedeutet Datenbank-Status Recovery Pending?

Recovery Pending heißt: Der SQL Server wollte die Datenbank beim Start hochfahren, konnte aber die nötige Wiederherstellung (Recovery) nicht einmal beginnen — meist, weil er auf eine benötigte Datei nicht zugreifen kann. Wichtig ist die Betonung auf „nicht beginnen“: Es ist kein Korruptions-Fall, bei dem die Daten beschädigt wären, sondern fast immer ein physisches Zugriffsproblem. Eine Datendatei oder die Logdatei fehlt, liegt auf einem offline gegangenen Laufwerk, wurde verschoben, oder dem SQL-Service-Account fehlt die Berechtigung darauf. Die Daten selbst sind in aller Regel völlig intakt — sie sind nur gerade nicht erreichbar. Das macht diesen Status deutlich weniger dramatisch als sein Ruf, sofern man richtig reagiert.

Wie komme ich aus dem Status Recovery Pending heraus?

Indem du die Zugriffsursache behebst und die Datenbank dann wieder online schaltest. Der Ablauf: Zuerst das SQL Server ERRORLOG lesen — es nennt fast immer die konkrete Datei und den genauen Grund, warum der Zugriff scheiterte. Dann diese Ursache beheben: den fehlenden Pfad oder das Laufwerk wiederherstellen, die Datei an den erwarteten Ort zurücklegen, oder die fehlende Berechtigung des Service-Accounts korrigieren. Anschließend bringt ALTER DATABASE [DB] SET ONLINE die Datenbank meist mit einem einzigen Befehl zurück — der Server holt dann die Recovery nach, die er vorher nicht starten konnte. Wichtig: nicht reflexhaft zu EMERGENCY und Reparatur-Werkzeugen greifen, das ist für Korruption gedacht, nicht für ein Zugriffsproblem.

Was ist der Unterschied zwischen Recovery Pending und Suspect?

Es ist der Unterschied zwischen „komme nicht ran“ und „ist beschädigt“. Recovery Pending bedeutet, dass der Server die Wiederherstellung gar nicht erst beginnen konnte — meist ein physisches Zugriffsproblem (Datei fehlt, Laufwerk offline, Berechtigung fehlt), während die Daten selbst intakt sind. Suspect dagegen bedeutet, dass der Server die Recovery begonnen hat, aber dabei auf einen schwerwiegenden Fehler stieß — typischerweise eine inhaltliche Korruption der Daten oder des Logs. Vereinfacht: Recovery Pending ist meist harmlos und durch Behebung des Zugriffs lösbar, Suspect ist ernst und ein Fall für die Recovery-Pyramide aus Backup-Restore und im Notfall Reparatur. Die beiden zu verwechseln führt zu völlig falschen Maßnahmen.

Welche Berechtigungen braucht der SQL-Service-Account?

Der Account, unter dem der SQL-Server-Dienst läuft, braucht volle Zugriffsrechte (Lesen und Schreiben) auf alle Ordner, in denen Datendateien (.mdf, .ndf) und Logdateien (.ldf) der Datenbanken liegen. Fehlt diese Berechtigung — etwa weil ein Laufwerk neu eingebunden, ein Ordner verschoben oder bei einer Migration die Rechte nicht mitgenommen wurden —, kann der Service die Datei nicht öffnen, und die Datenbank landet im Status Recovery Pending. Auf NTFS-Ebene wird das Recht idealerweise dem SQL-Server-Dienstkonto direkt zugewiesen (bei einem virtuellen Dienstkonto der instanzspezifischen SID). Genau diese fehlende Berechtigung ist eine der vier Hauptursachen — und eine, die nach jeder Storage- oder Migrations-Änderung gern auftritt.

Wie analysiere ich das ERRORLOG?

Das SQL Server ERRORLOG ist bei Recovery Pending die erste und wichtigste Anlaufstelle — es protokolliert beim Hochfahren genau, welche Datei der Server nicht öffnen konnte und warum. Du liest es entweder über die Prozedur sp_readerrorlog (gefiltert nach dem Datenbanknamen oder Schlüsselwörtern wie „error“ oder „open“) oder direkt als Datei im Log-Verzeichnis der Instanz. Suche nach dem Zeitpunkt des letzten Starts und den Meldungen rund um die betroffene Datenbank: Oft steht dort wörtlich der Pfad der vermissten Datei und ein Hinweis wie „operating system error 5“ (Zugriff verweigert — Berechtigung) oder „error 2/3“ (Datei/Pfad nicht gefunden). Diese Meldung zeigt dir direkt, welche der vier Ursachen vorliegt.

Wann sollte ich ALTER DATABASE SET EMERGENCY verwenden?

Möglichst gar nicht bei reinem Recovery Pending — EMERGENCY und die damit verbundenen Reparatur-Werkzeuge sind für echte Korruption (den Status Suspect) gedacht, nicht für ein Zugriffsproblem. Bei Recovery Pending ist der richtige Weg, die Zugriffsursache zu beheben und dann SET ONLINE zu nutzen; die Daten sind ja intakt. EMERGENCY versetzt die Datenbank in einen Sonderzustand, in dem man sie trotz Problemen lesen und im äußersten Notfall mit REPAIR_ALLOW_DATA_LOSS reparieren kann — wobei diese Reparatur beschädigte Daten verwirft. Auf eine intakte, nur unerreichbare Datenbank losgelassen, würde das Daten wegwerfen, die vollkommen in Ordnung sind. EMERGENCY gehört zum Suspect-Beitrag, nicht hierher.

Wie finde ich den Pfad einer Datenbankdatei?

Über die Systemsicht sys.master_files, die für jede Datenbank die logischen Namen und die physischen Pfade aller Daten- und Logdateien enthält — und zwar unabhängig davon, ob die Datenbank gerade online ist, was bei Recovery Pending entscheidend ist. Du fragst sie mit einem einfachen SELECT ab, gefiltert auf die betroffene Datenbank, und bekommst die erwarteten Pfade. Diese gleichst du dann mit der Realität ab: Existiert die Datei dort wirklich? Ist das Laufwerk eingebunden? Hat der Service-Account Zugriff? Die Diskrepanz zwischen erwartetem und tatsächlichem Zustand ist die halbe Diagnose. Die konkrete Abfrage steht im Skript-Abschnitt dieses Beitrags.