Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Als Datenbankadministrator kann der Umgang mit einer SQL‑Datenbank, die im Wiederherstellungszustand hängenbleibt, den Betrieb stören und den Datenzugriff blockieren, was zu Ausfallzeiten kritischer Systeme führt. Dies resultiert häufig aus unvollständigen Wiederherstellungsvorgängen oder Konfigurationsproblemen.
In diesem Leitfaden erläutern wir die Ursachen für eine im Wiederherstellungsmodus hängengebliebene Datenbank und stellen sechs praktische Lösungen – einschließlich T‑SQL‑Befehlen – vor, um das Problem auf Basis praktischer DBA‑Erfahrungen effizient zu beheben.
Die meisten Fälle einer im Wiederherstellungsmodus hängengebliebenen Datenbank lassen sich auf einfache, behebbare Probleme zurückführen—dies sind die wahrscheinlichen Gründe (und deren Zusammenhang mit den nachfolgenden Lösungen):
Manuelle Wiederherstellungen sind fehleranfällig. i2Backup automatisiert den gesamten Ablauf von der vollständigen Sicherung bis zur Wiederherstellung für SQL Server, vermeidet hängende Zustände und verkürzt die Wiederherstellungszeit. Mehr erfahren »
Im Folgenden finden Sie sechs praktische Lösungen zur Behebung des Problems mit dem hängenden Wiederherstellungsmodus. Sie können diese nacheinander testen oder für langfristige Effizienz auf eine optimierte SQL‑Server‑Sicherungslösung zurückgreifen.
Dieses Problem tritt üblicherweise auf, wenn eine Wiederherstellung mit dem Flag NORECOVERY ausgeführt wird, der abschließende Wiederherstellungsschritt aber weggelassen wird. Dadurch verbleibt der Zustand „Wiederherstellung“, weil die Engine die Anwendung weiterer Transaktionsprotokolle erwartet.
Die Lösung
Wenn keine weiteren Sicherungsdateien mehr angewendet werden müssen, bringen Sie die Datenbank mit folgendem Befehl online:
-- Ersetzen Sie [YourDatabaseName] durch den tatsächlichen Datenbanknamen
RESTORE DATABASE [YourDatabaseName] WITH RECOVERY;
GO
Funktionsweise
Der Parameter WITH RECOVERy teilt SQL Server mit, dass die Wiederherstellungssequenz abgeschlossen ist. Die Engine führt anschließend die „Undo“‑Phase aus – nicht‑festgeschriebene Transaktionen werden rückgängig gemacht, um Datenkonsistenz sicherzustellen. Dadurch wechselt der Status der Datenbank von „Wiederherstellung“ auf „Online“ und steht Benutzern zur Verfügung.
Wenn Sie den SSMS‑Wiederherstellungsassistenten verwenden und die Option „Tail‑Log‑Sicherung erstellen“ aktiviert lassen, kann die Datenbank im Wiederherstellungsmodus hängenbleiben – falls diese Sicherung fehlschlägt oder versehentlich der Wiederherstellungszustand „Datenbank nicht betriebsbereit belassen“ ausgewählt wurde.
Die Lösung
Beheben Sie das Problem, indem Sie den Wiederherstellungsvorgang mit korrekten Einstellungen neu starten. Gehen Sie wie folgt vor:
Funktionsweise
Diese Einstellungen stellen sicher, dass der Assistent den gesamten Wiederherstellungsvorgang abschließt. Mit „RESTORE WITH RECOVERY“ weisen Sie SQL Server an, die Daten endgültig fertigzustellen und online zu schalten. Das Deaktivieren der Tail‑Log‑Sicherung verhindert, dass der Assistent auf eine möglicherweise beschädigte oder nicht verfügbare Protokolldatei wartet.
Gelegentlich blockieren Hintergrundaufgaben oder Anwendungsverbindungen den abschließenden Wiederherstellungsschritt. Dadurch bleibt die Datenbank im Wiederherstellungsmodus hängen, da die SQL‑Server‑Engine nicht den benötigten exklusiven Zugriff erhält, um die Daten online zu schalten.
Die Lösung
Beheben Sie dies, indem Sie alle weiteren Verbindungen erzwingen zu schließen. Dadurch kann die Datenbank ihre Wiederherstellung abschließen. Führen Sie folgendes Skript aus:
-- Alle aktiven Sitzungen beenden und Transaktionen rückgängig machen
ALTER DATABASE [YourDatabaseName] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
-- Datenbank online schalten
RESTORE DATABASE [YourDatabaseName] WITH RECOVERY;
GO
-- Datenbank wieder in den normalen Mehrbenutzermodus versetzen
ALTER DATABASE [YourDatabaseName] SET MULTI_USER;
GO
Funktionsweise
Der Befehl SET SINGLE_USER WITH ROLLBACK IMMEDIATE löst Sitzungssperren, indem Benutzer getrennt und deren Transaktionen rückgängig gemacht werden. Sobald keine Sperren mehr vorhanden sind, kann die Engine die abschließende Wiederherstellungsphase sicher durchführen. Nach dem Wechsel der Datenbank auf den Status „Online“ ermöglicht der Rückwechsel zum MULTI_USER‑Modus die erneute Verbindung von Anwendungen.
In Hochverfügbarkeits‑Konfigurationen wie der Datenbank‑Spiegelung oder Always‑On‑Verfügbarkeitsgruppen befinden sich sekundäre Datenbanken standardmäßig im Zustand „Wiederherstellung“, um Protokoll‑Aktualisierungen vom Primärserver zu übernehmen. Wenn die Verbindung zwischen diesen Servern unterbricht oder die Datenbank fehlerhaft aus der Gruppe entfernt wird, bleibt die sekundäre Kopie oft im Wiederherstellungsmodus hängen.
Die Lösung
Beheben Sie dies, indem Sie die Verbindung zwischen Primär‑ und Sekundärdatenbank manuell trennen. Bei Verwendung der Datenbank‑Spiegelung führen Sie auf der sekundären Instanz folgenden Befehl aus:
-- Spiegelungsbeziehung aufheben, um die Datenbank freizugeben
ALTER DATABASE [YourDatabaseName] SET PARTNER OFF;
GO
Wenn die Datenbank Teil einer Verfügbarkeitsgruppe ist, entfernen Sie sie mit folgendem Befehl auf dem Sekundärserver:
-- Datenbank aus der Verfügbarkeitsgruppe entfernen
ALTER DATABASE [YourDatabaseName] SET HADR OFF;
GO
Funktionsweise
Diese Befehle teilen SQL Server mit, keine Daten mehr von einem Partnerserver zu erwarten. Durch das Deaktivieren von „Partner“ oder „HADR“ (High‑Availability‑Disaster‑Recovery) wird die sekundäre Datenbank zu einer eigenständigen Datenbank. Sobald sie nicht mehr auf externe Protokolle wartet, können Sie sie mit dem in Lösung 1 genannten WITH‑RECOVERY‑Befehl online schalten.
Bei einer Protokollweiterleitung‑Konfiguration befindet sich die sekundäre Datenbank konstruktionsbedingt im Zustand „Wiederherstellung“ oder „Standby“. Dadurch kann sie kontinuierlich Transaktionsprotokollsicherungen vom Primärserver übernehmen und anwenden. Neue DBAs bemerken diesen Zustand oft und befürchten einen Fehler – obwohl das System einwandfrei funktioniert.
Die Lösung
Prüfen Sie zuerst, ob die Datenbank Teil einer Protokollweiterleitung‑Paarung ist. Falls ja und Sie die Datenbank tatsächlich online schalten müssen (z. B. bei einem Notfall‑Failover), beenden Sie die Protokollweiterleitungs‑Aufträge und stellen Sie die Datenbank manuell wieder her:
-- Nur ausführen, wenn Sie die Protokollweiterleitung trennen und die Datenbank online schalten möchten
RESTORE DATABASE [YourDatabaseName] WITH RECOVERY;
GO
Wenn die Datenbank in diesem Zustand lesbar sein soll, konfigurieren Sie die Protokollweiterleitung für den „Standby‑Modus“ statt des „No‑Recovery‑Modus“.
Funktionsweise
Hier handelt es sich häufig um einen „falschen Alarm“ und keinen technischen Fehler. Die Protokollweiterleitung erfordert, dass die Zieldatenbank im nicht‑wiederhergestellten Zustand verbleibt, um mit den Protokollen des Primärservers Schritt zu halten. Der Wiederherstellungsbefehl weist SQL Server an, nicht mehr auf Protokolle zu warten und die Daten abzuschließen – dadurch wird die Datenbank zugänglich, aber die Protokollweiterleitungskette wird unterbrochen.
Gelegentlich bricht eine Wiederherstellung zur Hälfte ab – verursacht durch Hardware‑Probleme, vollen Festplattenspeicher oder beschädigte Sicherungsdateien. Dadurch kann die SQL‑Datenbank im Zustand „Wiederherstellung ausstehend“ oder dauerhaft im Wiederherstellungsmodus hängenbleiben. In diesen Fällen kann die SQL‑Server‑Engine die Datenintegrität oder die Protokoll‑Sequenznummern (LSN) nicht prüfen und verhindert das Online‑Schalten der Datenbank.
Die Lösung
Wenn Sie vermuten, dass die Wiederherstellung durch Beschädigung fehlgeschlagen ist, empfiehlt es sich, die hängenden Metadaten zu bereinigen und mit einer geprüften, neuen Wiederherstellung neu zu beginnen. Gehen Sie wie folgt vor:
-- Hängende Datenbank löschen, falls eine einfache Wiederherstellung nicht möglich ist
DROP DATABASE [YourDatabaseName];
GO
-- Neue Wiederherstellung aus einer nachweislich intakten Sicherungsdatei durchführen
RESTORE DATABASE [YourDatabaseName]
FROM DISK = 'C:\Backups\YourBackup.bak'
WITH RECOVERY, REPLACE, STATS = 10;
GO
Funktionsweise
Bei Metadaten‑Abweichungen oder Beschädigungen schlägt die interne Wiederherstellungsphase „Redo/Undo“ fehl. Durch das Löschen der Datenbank und den REPLACE‑Befehl entfernen Sie beschädigte Verweise und ermöglichen SQL Server, die Dateien neu zu erstellen. Die Angabe STATS = 10 erlaubt Ihnen, den Fortschritt zu verfolgen, damit der Vorgang nicht erneut hängenbleibt.
In großskaligen Unternehmensumgebungen kann das alleinige Vertrauen auf manuelle T‑SQL‑Skripte oder die SSMS‑Grafikoberfläche riskant sein. In großen Unternehmen mit komplexen Datenanforderungen kann ein einziger menschlicher Fehler – wie ein falsch gesetztes Flag – kostspielige Ausfallzeiten verursachen. Um die Geschäftskontinuität sicherzustellen, setzen viele Organisationen auf unternehmensgeeignete Lösungen wie i2Backup.
So unterstützt i2Backup DBAs in Unternehmen bei der Aufrechterhaltung einer stabilen Umgebung:
Die Integration eines robusten Tools wie i2Backup in Ihre Infrastruktur ersetzt fehleranfällige manuelle Aufgaben durch einen hochverfügbaren Ablauf. Dadurch sind Ihre SQL‑Server‑Datenbanken stets geschützt, geprüft und können ohne Verzögerung online geschaltet werden.
Der Umgang mit einer SQL‑Datenbank, die während der Wiederherstellung hängenbleibt, kann belastend sein – insbesondere wenn Benutzer auf den Datenzugriff warten. In den meisten Fällen ist dieser Zustand jedoch lediglich ein Hinweis darauf, dass die SQL‑Server‑Engine auf eine abschließende Anweisung oder einen exklusiven Zugriff wartet, um ihre Arbeit abzuschließen.
Für großskalige Unternehmensumgebungen, in denen manuelle Fehler mit hohen Risiken verbunden sind, kann der Einsatz einer professionellen Lösung wie i2Backup diese Probleme vollständig durch Automatisierung und Echtzeit‑Synchronisation verhindern. Unabhängig von der gewählten Methode sollten Sie immer über geprüfte Sicherungen verfügen und bei fehlgeschlagenen Wiederherstellungsvorgängen die SQL‑Server‑Fehlerprotokolle prüfen. Mit dem richtigen Vorgehen lassen sich Wiederherstellungsprobleme schnell beheben und eine stabile, leistungsfähige Datenbankumgebung aufrechterhalten.
