Jetzt teilen:
Inhaltsverzeichnis verstecken

SQL Server Datenbank im Wiederherstellungsmodus? Holen Sie sich jetzt 10 bewährte Lösungen! Schritt-für-Schritt-Lösungen von der einfachen Lösung bis zur erweiterten Reparatur.

1 Verstehen SQL Server Datenbankwiederherstellungsmodus

1.1 Was ist der Wiederherstellungsmodus in SQL Server

Wenn eine SQL Server Datenbank zeigt den Status „In Wiederherstellung“ an, das bedeutet SQL Server führt eine Absturzwiederherstellung oder Transaktionswiederherstellung durch, um die Datenbankkonsistenz sicherzustellen. Dieser automatische Prozess gewährleistet die Datenintegrität, indem festgeschriebene Transaktionen wiederholt und nicht festgeschriebene Transaktionen zurückgesetzt werden.

In SQL Serverenthält eine Datenbank das Tag „In Wiederherstellung“, was bedeutet, dass sie sich derzeit im Wiederherstellungsmodus befindet.

Der Wiederherstellungsmodus wird typischerweise nach unerwarteten Abschaltungen, Stromausfällen oder während der Datenbankwiederherstellung aktiviert. Dies ist zwar ein normaler Schutzmechanismus, aber es treten Probleme auf, wenn SQL Server Die Wiederherstellung der Datenbank dauert ungewöhnlich lange oder scheint hängen zu bleiben.

1.2 Die drei Phasen der Datenbankwiederherstellung

SQL Server Die Genesung verläuft in drei verschiedenen Phasen:

1.2.1 Analysephase

SQL Server Durchsucht das Transaktionsprotokoll vom letzten Prüfpunkt, um fehlerhafte Seiten und aktive Transaktionen zu identifizieren. Es erstellt eine Dirty Page Table (DPT) und eine Active Transaction Table (ATT), um zu verfolgen, was wiederhergestellt werden muss.

1.2.2 Wiederholungsphase (Roll Forward)

Das System wiederholt alle festgeschriebenen Transaktionen, die vor dem Absturz nicht auf die Festplatte geschrieben wurden. Dadurch wird sichergestellt, dass alle festgeschriebenen Änderungen ordnungsgemäß auf die Datenbankdateien angewendet werden.

1.2.3 Rückgängig-Phase (Rollback)

Um die Datenbankkonsistenz aufrechtzuerhalten, werden alle nicht festgeschriebenen Transaktionen zurückgesetzt. Nach Abschluss des Vorgangs steht die Datenbank für den normalen Betrieb zur Verfügung.

1.3 Häufige Symptome und Fehlermeldungen

Wenn Ihr SQL Server Wenn die Datenbank wiederhergestellt wird, sehen Sie normalerweise:

  • Datenbankname mit der Anzeige „(In Wiederherstellung)“ in SQL Server Management-Studio
  • Anmeldefehler mit der Meldung „Datenbank wird wiederhergestellt“
  • Fehlerprotokolleinträge mit Prozentangaben zum Wiederherstellungsfortschritt
  • Datenbankstatus zeigt bei Abfrage „WIEDERHERSTELLUNG“ an

2. Grundursachen von SQL Server Probleme mit dem Wiederherstellungsmodus

2.1 Unvollständige Wiederherstellungsvorgänge

Die häufigste Ursache tritt auf, wenn die Wiederherstellung aus mehreren Sicherungsdateien mithilfe von NORECOVERY Option ohne endgültige MIT WIEDERHERSTELLUNG Befehl. Dadurch wartet die Datenbank auf weitere Wiederherstellungsvorgänge.

2.2 Probleme mit dem Transaktionsprotokoll

Große Transaktionsprotokolldateien oder übermäßig viele virtuelle Protokolldateien (VLFs) verlangsamen die Wiederherstellung erheblich. Wenn MS SQL mit Tausenden von VLFs wiederhergestellt wird, kann der Vorgang Stunden oder Tage dauern.

2.3 Systembezogene Probleme

Hardwareausfälle, Stromausfälle oder unzureichender Speicherplatz können den normalen Datenbankbetrieb unterbrechen und beim Neustart langwierige Wiederherstellungsprozesse auslösen.

2.4 Datenbankbeschädigung

Beschädigte Datenbankdateien verhindern eine erfolgreiche Wiederherstellung und lassen die Datenbank auf unbestimmte Zeit im Wiederherstellungsmodus hängen.

3. Diagnoseschritte vor der Reparatur

3.1 Überprüfen SQL Server Fehlerprotokolle

Bevor Sie versuchen, eine Reparatur durchzuführen, prüfen Sie die SQL Server Fehlerprotokoll für Meldungen zum Wiederherstellungsfortschritt. Suchen Sie nach Einträgen, die den Prozentsatz der Fertigstellung und die geschätzte verbleibende Zeit anzeigen.

  1. Öffne SQL Server Management-Studio
  2. Navigieren Verwaltung -> SQL Server Logs
  3. Überprüfen Sie die letzten Einträge für Ihren Datenbanknamen
  4. Achten Sie auf Indikatoren für die Erholungsphase (Phase 1, 2 oder 3 von 3).

Überprüfung SQL Server Fehlerprotokolle für Meldungen zum Wiederherstellungsfortschritt.

3.2 Überwachung des Wiederherstellungsfortschritts

Verwenden Sie dynamische Verwaltungsansichten, um aktive Wiederherstellungsvorgänge zu verfolgen:

SELECT session_id, command, blocking_session_id, wait_type, wait_time, wait_resource
FROM sys.dm_exec_requests
WHERE command = 'DB STARTUP';

3.3 Überprüfen des Datenbankstatus

Überprüfen Sie den aktuellen Datenbankstatus, um den Wiederherstellungsstatus zu verstehen:

SELECT name, state_desc
FROM sys.databases
WHERE name = 'YourDatabaseName';

4. Lösung Nr. 1: Warten Sie, bis die natürliche Wiederherstellung abgeschlossen ist

Manchmal ist Geduld die beste Lösung, wenn Ihr SQL Server Datenbank wird wiederhergestellt. Dieser Ansatz funktioniert, wenn die Wiederherstellung normal verläuft, aber länger dauert als erwartet.

4.1 Wann ist Geduld angebracht?

Natürliche Vervollständigung zulassen, wenn:

  • Fehlerprotokolle zeigen stetigen Fortschritt mit abnehmenden Zeitschätzungen
  • Es werden keine Korruptionsfehler gemeldet
  • In der Datenbank kam es kürzlich zu großen Transaktionen
  • Die VLF-Anzahl ist überschaubar (unter 1,000)

4.2 Überwachung des Wiederherstellungsfortschritts

Die in Fehlerprotokollen angegebenen Wiederherstellungszeiten sind häufig ungenau. Konzentrieren Sie sich auf den Fortschritt in Prozent und nicht auf die verbleibende Zeit. Bei großen Datenbanken mit umfangreichen Transaktionshistorien kann die vollständige Wiederherstellung mehrere Stunden dauern.

5. Fix Nr. 2: Verwenden Sie RESTORE DATABASE WITH RECOVERY

Dieser Fix behebt unvollständige Wiederherstellungsvorgänge, bei denen der letzte Wiederherstellungsschritt ausgelassen wurde. Verwenden Sie diesen Fix, wenn Ihr SQL Server Die wiederhergestellte Datenbank ist das Ergebnis eines Wiederherstellungsprozesses mit NORECOVERY.

5.1 Den Befehl verstehen

Das Datenbank mit Recovery wiederherstellen Der Befehl schließt den Wiederherstellungsprozess ab, indem er nicht festgeschriebene Transaktionen zurücksetzt und die Datenbank online bringt.

5.2 Implementierungsschritte

  1. Öffne SQL Server Management-Studio
  2. Stellen Sie eine Verbindung zu Ihrem her SQL Server Instanz
  3. Gehen Sie auf Neu > Abfrage mit aktueller Verbindung
    Erstellen Sie eine neue Abfrage in SQL Server Management-Studio.
  4. Execute: RESTORE DATABASE [YourDatabaseName] WITH RECOVERY;
  5. Warten Sie auf die Abschlussbestätigung

Warnung: Verwenden Sie diesen Befehl nur, wenn Sie sicher sind, dass keine weiteren Wiederherstellungsvorgänge ausstehen.

6. Fix Nr. 3: Beheben Sie Probleme mit dem Transaktionsprotokoll

Probleme mit Transaktionsprotokollen sind eine der Hauptursachen für verlängerte Wiederherstellungszeiten. Dieser Fix behebt volle Protokolle, übermäßige VLFs und Probleme mit dem Protokollspeicher, die SQL Server in der Genesung.

6.1 Sichern von Transaktionsprotokollen

Geben Sie Protokollspeicherplatz frei, indem Sie Transaktionsprotokollsicherungen erstellen:

  1. Öffne SQL Server Management-Studio
  2. Klicken Sie mit der rechten Maustaste auf Ihre Datenbank -> Aufgaben -> Sichern
    Starten Sie einen Sicherungsvorgang für einen SQL Server Datenbank.
  3. Ändern Sicherungstyp zu Transaktionsprotokoll
    Ändern Sie den Sicherungstyp in Transaktionsprotokoll
  4. Backup-Ziel angeben
  5. Gehen Sie auf OK ausführen

6.2 Verwalten virtueller Protokolldateien (VLFs)

Überprüfen Sie die VLF-Anzahl mit:

DBCC LOGINFO('YourDatabaseName');

Wenn Sie über 1,000 VLFs haben, reduzieren Sie diese wie folgt:

  1. Sichern des Transaktionsprotokolls
  2. Verkleinern der Protokolldatei: DBCC SHRINKFILE(LogFileName, TRUNCATEONLY);
  3. Erweitern der Protokolldatei in großen Blöcken (1 GB oder mehr)

6.3 Sicheres Verkleinern von Protokolldateien

Verkleinern Sie Protokolle nur während Wartungsfenstern, wenn keine aktiven Transaktionen ausgeführt werden. Sichern Sie die Datenbank immer, bevor Sie Verkleinerungsvorgänge durchführen.

7. Fix Nr. 4: Führen Sie DBCC CHECKDB aus und reparieren Sie

Eine Datenbankbeschädigung kann eine erfolgreiche Wiederherstellung verhindern. DBCC CHECKDB ist ein integrierter Befehl, der kleinere Beschädigungen erkennt und behebt, die MS SQL im Wiederherstellungsmodus halten.

7.1 Prüfen auf Datenbankbeschädigung

Beginnen Sie mit der Standardmethode zur Überprüfung der Datenbankintegrität. Versuchen Sie zunächst direkt DBCC CHECKDB:

  1. Execute: DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS;
  2. Überprüfen Sie die Ergebnisse auf Konsistenzfehler
  3. Dokumentieren Sie alle Korruptionsmeldungen

Wenn DBCC CHECKDB fehlschlägt Bei Fehlermeldungen wie „Datenbank wird wiederhergestellt. Warten, bis die Wiederherstellung abgeschlossen ist“ bedeutet dies, dass sich die Datenbank aktiv im Wiederherstellungsmodus befindet und den Zugriff blockiert. Fahren Sie in diesem Fall mit Abschnitt 7.3 fort, um den NOTFALL-Modus zu verwenden.

7.2 Reparaturoptionen für zugängliche Datenbanken

Wenn DBCC CHECKDB erfolgreich ausgeführt wurde und eine Beschädigung festgestellt wurde, führen Sie die folgenden Reparaturschritte aus:

  1. Datenbank auf Einzelbenutzermodus einstellen: ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
  2. Versuchen Sie eine sichere Reparatur: DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD);
  3. Wenn dies nicht erfolgreich ist, verwenden Sie: DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
  4. Zurück zum Mehrbenutzermodus: ALTER DATABASE [YourDatabaseName] SET MULTI_USER;

7.3 Notfallmodus verwenden, wenn auf die Datenbank nicht zugegriffen werden kann

Der Notfallmodus ist nur erforderlich, wenn die Datenbank bei der Wiederherstellung hängen bleibt und normale DBCC CHECKDB-Versuche ablehnt. Er markiert die Datenbank als READ_ONLY und deaktiviert die Protokollierung. Verwenden Sie diesen Ansatz, wenn der Standardzugriff fehlschlägt:

  1. Notbetrieb einstellen: ALTER DATABASE [YourDatabaseName] SET EMERGENCY;
  2. Einzelbenutzer einstellen: ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
  3. Führen Sie eine Integritätsprüfung durch: DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS;
  4. Wenn eine Beschädigung festgestellt wird, führen Sie zuerst eine sichere Reparatur durch: DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD);
  5. Wenn dies fehlschlägt, verwenden Sie die Reparatur mit Datenverlust:  DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
  6. Mehrbenutzer einrichten: ALTER DATABASE [YourDatabaseName] SET MULTI_USER;
  7. Online einstellen: ALTER DATABASE [YourDatabaseName] SET ONLINE;

Wichtig: Der EMERGENCY-Modus umgeht normale Wiederherstellungsprozesse und sollte nur verwendet werden, wenn die Datenbank vollständig unzugänglich ist. Versuchen Sie immer zuerst den Standardansatz DBCC CHECKDB, bevor Sie in den EMERGENCY-Modus wechseln.

Sie finden das eine umfassendere Anleitung zur Verwendung von DBCC CHECKDB.

8. Lösung Nr. 5: Wiederherstellen aus Backup

Wenn andere Methoden versagen oder die Datenintegrität fraglich ist, ist die Wiederherstellung aus einem sauberen Backup oft die zuverlässigste Lösung zur Behebung des Problems. SQL Server Datenbank bei Wiederherstellungsproblemen.

8.1 Wann ist die Sicherungswiederherstellung sinnvoll?

Erwägen Sie eine Sicherungswiederherstellung, wenn:

  • Die Wiederherstellung läuft seit über 24 Stunden ohne Fortschritt
  • Korruptionsfehler verhindern eine erfolgreiche Reparatur
  • Sie verfügen über aktuelle, verifizierte Backups
  • Datenverlust seit der letzten Sicherung ist akzeptabel

8.2 Schrittweiser Wiederherstellungsprozess

  1. Öffne SQL Server Management-Studio
  2. Der rechten Maustaste auf Datenbanken -> Datenbank wiederherstellen
    Starten Sie einen Wiederherstellungsvorgang für die Datenbank in SQL Server Management-Studio
  3. Wählen Sie Gerät unter Quelle
  4. Gehen Sie auf Speichern und navigieren Sie zu Ihrer Sicherungsdatei
  5. Wählen Sie das Backup aus und klicken Sie auf OK
  6. Wählen Überschreiben der vorhandenen Datenbank ggf.
  7. Gehen Sie auf OK um mit der Wiederherstellung zu beginnen

Datenbank wiederherstellen in SQL Server.

8.3 Wiederherstellung zu einem bestimmten Zeitpunkt

Um Datenverluste zu minimieren, verwenden Sie Transaktionsprotokollsicherungen, um Daten zu einem bestimmten Zeitpunkt wiederherzustellen. Stellen Sie sicher, dass Sie über eine lückenlose Kette von Protokollsicherungen von der vollständigen Sicherung bis zum gewünschten Wiederherstellungspunkt verfügen.

8.4-Referenz

Weitere Informationen erhalten Sie in unserem Umfassender Leitfaden zum Sichern und Wiederherstellen SQL Server Datenbanken.

9. Fix Nr. 6: Deaktivieren Sie die AUTO CLOSE-Eigenschaft

Die Datenbankeigenschaft AUTO CLOSE kann wiederholte Wiederherstellungszyklen verursachen, wodurch der Eindruck entsteht, dass Ihre SQL Server Die Datenbank wird ständig wiederhergestellt. Durch Deaktivieren dieser Eigenschaft wird das Problem behoben.

9.1 AUTO CLOSE-Probleme verstehen

Wenn AUTO CLOSE aktiviert ist, SQL Server schließt die Datenbank nach Beendigung der letzten Verbindung und öffnet sie anschließend für neue Verbindungen. Dieses wiederholte Öffnen löst jedes Mal Wiederherstellungsprozesse aus.

9.2 Deaktivieren von AUTO CLOSE

  1. Öffne SQL Server Management-Studio
  2. Klicken Sie mit der rechten Maustaste auf Ihre Datenbank -> Eigenschaften im Vergleich
  3. Wählen Sie Einstellungen von der linken Seite
  4. Stelle den Automatisch schließen zu falsch
  5. Gehen Sie auf OK Änderungen übernehmen

Deaktivieren Sie die Eigenschaft „Automatisches Schließen“ für SQL Server Datenbank in SQL Server Management-Studio.

Alternativ können Sie T-SQL verwenden:

ALTER DATABASE [YourDatabaseName] SET AUTO_CLOSE OFF;

10. Lösung Nr. 7: Neustart SQL Server Service

Ein Neustart des Dienstes kann festgefahrene Wiederherstellungsprozesse beheben, sollte aber mit Vorsicht angewendet werden, da die Wiederherstellung dadurch von vorn beginnt. Diese Lösung funktioniert, wenn SQL Server in der Genesung erscheint völlig eingefroren.

10.1 Wann ein Neustart des Dienstes hilft

Starten Sie den Dienst neu, wenn:

  • Der Wiederherstellungsfortschritt ist seit mehreren Stunden ins Stocken geraten
  • Fehlerprotokolle zeigen keine neuen Einträge
  • Andere Datenbanken funktionieren normal
  • Sie können sich längere Ausfallzeiten leisten

10.2 Sichere Neustartverfahren

  1. Öffne SQL Server Konfigurationsmanager Externer Link
  2. Navigieren SQL Server Services
  3. Finden Sie SQL Server Klicken Sie mit der rechten Maustaste auf die Instanz, die Sie neu starten möchten. SQL Server (Instanzname)
  4. Wählen Sie Wiederaufnahme
  5. Warten Sie, bis der Dienst vollständig neu gestartet wurde.
  6. Überwachen Sie Fehlerprotokolle für den Wiederherstellungsfortschritt

Starten Sie das neu SQL Server Service in SQL Server Konfigurationsmanager.

Hinweis: Durch einen Neustart beginnt der Wiederherstellungsprozess von vorn, wodurch sich die gesamte Wiederherstellungszeit möglicherweise verlängert.

11. Fix Nr. 8: Reparieren Sie die Datenbank durch Trennen und erneutes Anfügen

In Extremfällen trennen Sie die Datenbank und hängen sie erneut an:

  1. Datenbank trennen: EXEC sp_detach_db 'YourDatabaseName';
  2. Hängen Sie nur die MDF-Datei an: CREATE DATABASE [YourDB] ON (FILENAME = 'C:\Path\YourDB.mdf') FOR ATTACH_REBUILD_LOG;
  3. Dadurch wird ein neues Transaktionsprotokoll erstellt

Warnung: Diese Methode kann zu Datenverlust führen. Verwenden Sie sie nur, wenn alle anderen Optionen ausgeschöpft sind.

12. Fix Nr. 9: Behandeln Sie Probleme mit der Datenbankspiegelung

Datenbankspiegelungskonfigurationen können einzigartige Wiederherstellungsprobleme verursachen. Dieser Fix behebt spiegelungsspezifische Probleme, die Datenbanken im Wiederherstellungszustand halten.

12.1 Spiegelungsspezifische Wiederherstellungsprobleme

Gespiegelte Datenbanken können aufgrund von Partnerverbindungsproblemen oder Endpunktproblemen bei der Wiederherstellung hängen bleiben. Sowohl Haupt- als auch Spiegeldatenbanken können den Wiederherstellungsstatus anzeigen.

12.2 Spiegelungswiederherstellungslösungen

Starten Sie den Spiegelungsendpunkt neu:

  1. Endpunktnamen suchen: SELECT * FROM sys.endpoints WHERE type = 4;
  2. Stopp-Endpunkt: ALTER ENDPOINT [EndpointName] STATE = STOPPED;
  3. Startendpunkt: ALTER ENDPOINT [EndpointName] STATE = STARTED;

Wenn ein Neustart des Endpunkts fehlschlägt, wird die Spiegelungspartnerschaft unterbrochen:

  1. Execute: ALTER DATABASE [DatabaseName] SET PARTNER OFF;
  2. Run: RESTORE DATABASE [DatabaseName] WITH RECOVERY;
  3. Spiegelung neu konfigurieren, sobald die Datenbank online ist

13. Fix Nr. 10: Verwenden Sie professionelle Wiederherstellungstools

Wiederherstellungstools von Drittanbietern bieten erweiterte Reparaturfunktionen, wenn sie integriert sind SQL Server Methoden schlagen fehl. Diese Tools können häufig Daten aus stark beschädigten Datenbanken wiederherstellen.

13.1 DataNumen SQL Recovery

DataNumen SQL Recovery verfügt über eine hohe Rückgewinnungsrate und umfassende Optionen.

Nachfolgend sind die Schritte zur Verwendung aufgeführt:

  1. Stoppen Sie die SQL Server Service.
  2. Erstellen Sie im Wiederherstellungsmodus eine Kopie der Dateien der Datenbank, einschließlich der primären MDF-Datei und der sekundären NDF-Dateien.
  3. Starte das SQL Server Service.
  4. Start DataNumen SQL Recovery.
  5. Wählen Sie als Quelle der wiederherzustellenden Datenbank die Kopie anstelle der Originaldatei.
  6. Klicken Sie auf „Wiederherstellung starten“ und folgen Sie den Anweisungen, um die Datenbank wiederherzustellen.
  7. Nach dem Wiederherstellungsprozess wird eine neue Wiederherstellungsdatenbank angezeigt in SQL Server die alle wiederhergestellten Daten enthält.

Arbeiten jederzeit weiterbearbeiten können. Jede Präsentation und jeder KI-Avatar, den Sie von Grund auf neu erstellen oder hochladen,  DataNumen SQL Recovery zur Reparatur eines einzelnen beschädigten SQL Server MDF-Datei.

13.2 Wann sind Drittanbieter-Tools sinnvoll?

Verwenden Sie professionelle Werkzeuge, wenn:

  • Integrierte Reparaturoptionen schlagen fehl oder melden umfangreiche Beschädigungen
  • Es sind keine aktuellen Backups verfügbar
  • Kritische Daten müssen trotz Beschädigung wiederhergestellt werden
  • Herkömmliche Wiederherstellungsmethoden führen zu erheblichem Datenverlust

14. Best Practices zur Prävention

14.1 Regelmäßige Wartungsarbeiten

Implementieren Sie diese Praktiken, um zu verhindern SQL Server Datenbank bei Wiederherstellungsproblemen:

  • Planen Sie regelmäßige vollständige und Protokollsicherungen: Vollständige Backup-Ketten pflegen
  • VLF-Zählungen überwachen: Halten Sie VLFs unter 100 für optimale Leistung
  • Planen Sie die Größe der Protokolldatei: Passen Sie die Größe der Protokolle vorab an, um übermäßiges automatisches Wachstum zu vermeiden
  • Führen Sie den regulären DBCC CHECKDB aus: Korruption frühzeitig erkennen

14.2 Überwachung und Alarmierung

Richten Sie eine proaktive Überwachung ein:

  1. Konfigurieren von Warnungen für Datenbankstatusänderungen
  2. Überwachen Sie den Speicherplatz auf Protokolldateilaufwerken
  3. Verfolgen Sie lang andauernde Transaktionen
  4. Warnung bei übermäßigen VLF-Zählungen

14.3 Hardware und Infrastruktur

Sorgen Sie für eine zuverlässige Infrastruktur:

  • Verwenden Sie schnellen Speicher für Transaktionsprotokolle (vorzugsweise SSDs).
  • Implementieren Sie redundante Stromversorgungen
  • Separate Daten- und Protokolldateien auf verschiedenen Laufwerken
  • Geht davon Hochverfügbarkeitslösungen Google Trends, Amazons Bestseller Always On-Verfügbarkeitsgruppen

15. Fehlerbehebung bei komplexen Szenarien

15.1 Mehrere Datenbankprobleme

Wenn mehrere Datenbanken bei der Wiederherstellung hängen bleiben:

  1. Überprüfen Sie, ob systemweite Probleme vorliegen (Festplattenspeicher, Arbeitsspeicher).
  2. Priorisieren Sie kritische Datenbanken für die Wiederherstellung
  3. Berücksichtigen Sie Hardwareprobleme, die die gesamte Instanz betreffen
  4. Überprüfen Sie die letzten Systemänderungen oder -aktualisierungen

15.2 Überlegungen zu großen Datenbanken

Für Datenbanken über 1 TB:

  • Rechnen Sie mit längeren Erholungszeiten (möglicherweise Tage)
  • Sorgen Sie für eine ausreichende Speicherzuweisung
  • Berücksichtigen Sie die Einstellungen für die parallele Verarbeitung
  • Überwachen Sie den Tempdb-Speicherplatz während der Wiederherstellung

15.3 Wann Sie den Microsoft-Support kontaktieren sollten

Kontaktieren Sie den Microsoft-Support für:

  • Kritische Produktionssysteme ohne Backup-Optionen
  • Vermutlich SQL Server Softwarefehler
  • Unternehmensumgebungen, die eine garantierte Wiederherstellung erfordern
  • Komplexe Always On- oder Clustering-Szenarien

16. Häufig gestellte Fragen

F: Wie lange sollte SQL Server Wie lange dauert die Datenbankwiederherstellung normalerweise?

A: Die Wiederherstellungszeit hängt von der Datenbankgröße, dem Transaktionsvolumen und der Hardwareleistung ab. Kleine Datenbanken werden in der Regel innerhalb von Minuten wiederhergestellt, während große Datenbanken mit umfangreichen Transaktionsprotokollen mehrere Stunden benötigen können. Die in den Fehlerprotokollen angezeigten Zeitschätzungen sind oft ungenau. Konzentrieren Sie sich daher lieber auf die prozentualen Fortschrittsangaben.

F: Kann ich aufhören SQL Server während der Wiederherstellung ohne Datenverlust?

A: Anhalten SQL Server Die Wiederherstellung ist im Allgemeinen sicher, der Wiederherstellungsprozess wird jedoch beim Neustart des Dienstes von vorn begonnen. Dies verlängert die gesamte Wiederherstellungszeit, verursacht aber keinen zusätzlichen Datenverlust über den ursprünglichen Vorfall hinaus.

F: Was ist der Unterschied zwischen „In Wiederherstellung“ und „Wiederherstellung ausstehend“?

A: „In Genesung“ bedeutet SQL Server Es werden aktiv Wiederherstellungsmaßnahmen durchgeführt. „Wiederherstellung ausstehend“ bedeutet, dass der Wiederherstellungsprozess nicht gestartet werden konnte, in der Regel aufgrund fehlender Dateien, unzureichender Berechtigungen oder Speicherplatzprobleme, die behoben werden müssen, bevor die Wiederherstellung fortgesetzt werden kann.

Weitere detaillierte Informationen zu „Wiederherstellung ausstehend“ finden Sie in unserer umfassende Anleitung.

F: Gehen mir Daten verloren, wenn ich REPAIR_ALLOW_DATA_LOSS verwende?

A: Ja, REPAIR_ALLOW_DATA_LOSS kann beschädigte Daten entfernen, um die Datenbankkonsistenz wiederherzustellen. Versuchen Sie immer zuerst REPAIR_REBUILD, um strukturelle Probleme ohne Datenverlust zu beheben. Verwenden Sie REPAIR_ALLOW_DATA_LOSS nur als letztes Mittel, wenn keine anderen Wiederherstellungsoptionen zur Verfügung stehen.

F: Kann ich auf andere Datenbanken zugreifen, während eine Datenbank wiederhergestellt wird?

A: Ja, andere Datenbanken auf derselben SQL Server Die Instanz bleibt während der Wiederherstellung zugänglich. Nur die wiederherzustellende Datenbank ist nicht verfügbar. Wiederherstellungsvorgänge können jedoch die Gesamtleistung des Servers beeinträchtigen.

F: Was führt dazu, dass eine Datenbank im Wiederherstellungsmodus hängen bleibt?

A: Häufige Ursachen sind unvollständige Wiederherstellungsvorgänge mit NORECOVERY, übermäßige Anzahl virtueller Protokolldateien (VLFs), große nicht festgeschriebene Transaktionen, Datenbankbeschädigungen, unzureichender Speicherplatz und Hardwareprobleme. Es kann auch vorkommen, dass Datenbanken mit aktiviertem AUTO CLOSE ständig in die Wiederherstellung wechseln.

F: Woher weiß ich, ob die Wiederherstellung Fortschritte macht oder stecken bleibt?

A: Monitor SQL Server Fehlerprotokolle mit Fortschrittsmeldungen zur Wiederherstellung zeigen den jeweiligen Fortschritt in Prozent an. Überprüfen Sie mithilfe von sys.dm_exec_requests, ob DB-STARTUP-Befehle aktiv sind. Steigt der Fortschritt in Prozent mit der Zeit, schreitet die Wiederherstellung voran. Fehlen über mehrere Stunden neue Protokolleinträge, kann dies auf einen blockierten Prozess hindeuten.

F: Ist ein Neustart sicher? SQL Server Service während der Wiederherstellung?

A: Ein Neustart ist zwar sicher, sollte aber mit Bedacht erfolgen. Dadurch wird der Wiederherstellungsprozess von vorn begonnen, was die Wiederherstellungszeit unter Umständen verdoppeln kann. Starten Sie den Vorgang nur neu, wenn die Wiederherstellung über viele Stunden hinweg vollständig eingefroren ist und keine Fortschritte erzielt werden, oder wenn Sie vermuten, dass der Prozess tatsächlich festhängt.

F: Was ist der Unterschied zwischen AUTO CLOSE und dem Wiederherstellungsmodus?

A: AUTO CLOSE schließt Datenbanken automatisch, wenn keine Verbindungen bestehen, und öffnet sie anschließend für neue Verbindungen. Dieses wiederholte Öffnen löst jedes Mal kurze Wiederherstellungsprozesse aus, sodass es so aussieht, als würde die Datenbank ständig wiederhergestellt. Das Deaktivieren von AUTO CLOSE behebt dieses Problem.

F: Können Transaktionsprotokollsicherungen bei der Wiederherstellung hilfreich sein?

A: Transaktionsprotokollsicherungen können Speicherplatz freigeben, wenn das Protokolllaufwerk voll ist, und so möglicherweise die Wiederherstellung fortsetzen. Das Protokoll einer Datenbank, die sich aktuell im Wiederherstellungsmodus befindet, kann jedoch nicht gesichert werden. Protokollsicherungen sind eher zur Prävention und für die Wartung nach der Wiederherstellung geeignet.

F: Wann sollte ich den Microsoft-Support kontaktieren?

A: Kontaktieren Sie den Microsoft-Support für kritische Produktionssysteme, bei denen integrierte Wiederherstellungsmethoden fehlschlagen, wenn Sie vermuten SQL Server Softwarefehler, für komplexe Always On- oder Clustering-Szenarien oder wenn Unternehmensumgebungen eine garantierte Datenwiederherstellung mit minimalen Ausfallzeiten erfordern.

F: Wie kann ich verhindern, dass Datenbanken bei der Wiederherstellung hängen bleiben?

A: Führen Sie regelmäßige vollständige und Protokollsicherungen durch, überwachen und verwalten Sie die VLF-Zählung, stellen Sie ausreichend Speicherplatz sicher, verwenden Sie geeignete Herunterfahrverfahren, sorgen Sie für die Zuverlässigkeit der Hardware, deaktivieren Sie AUTO CLOSE in Produktionsdatenbanken und führen Sie regelmäßige DBCC CHECKDB-Vorgänge aus, um Beschädigungen frühzeitig zu erkennen.

F: Was sind VLFs und warum beeinflussen sie die Wiederherstellung?

A: Virtuelle Protokolldateien (VLFs) sind interne Segmente innerhalb von Transaktionsprotokolldateien. Zu viele VLFs (über 1,000) verlangsamen die Wiederherstellung erheblich, weil SQL Server muss jedes einzeln verarbeiten. Die richtige Größe der Protokolldatei und die richtigen Wachstumseinstellungen tragen zur Aufrechterhaltung optimaler VLF-Zählungen bei.

F: Kann ich eine Wiederherstellung aus einer Sicherung durchführen, während eine Datenbank wiederhergestellt wird?

A: Sie können keine Datenbank wiederherstellen, die sich derzeit im Wiederherstellungsmodus befindet. Sie müssen entweder warten, bis die Wiederherstellung abgeschlossen ist, SQL Server Dienst oder stellen Sie die Datenbank unter einem anderen Namen wieder her. In dringenden Fällen sollten Sie die Wiederherstellung unter einem neuen Datenbanknamen durchführen und die Datenbank umbenennen, sobald die Wiederherstellungsprobleme behoben sind.

17. Fazit und nächste Schritte

17.1 Zusammenfassung der wichtigsten Lösungen

Wenn Ihr SQL Server Die Datenbank wird wiederhergestellt. Gehen Sie folgendermaßen vor:

  1. Überprüfen Sie Fehlerprotokolle und überwachen Sie den Fortschritt
  2. Warten Sie auf den natürlichen Abschluss, wenn der Fortschritt stetig ist
  3. Verwenden Sie RESTORE WITH RECOVERY für unvollständige Wiederherstellungen
  4. Beheben Sie Probleme mit dem Transaktionsprotokoll
  5. Führen Sie DBCC CHECKDB oder professionelle Tools zur Schadensbehebung aus
  6. Erwägen Sie in schwerwiegenden Fällen die Wiederherstellung einer Sicherung

Most SQL Server DB-Recovery-Situationen lassen sich mit diesen bewährten Methoden innerhalb weniger Stunden beheben. Bei komplexen Szenarien können Sie auf fortgeschrittene Techniken oder professionelle Tools zurückgreifen.

17.2 Zusätzliche Ressourcen

Für weitere Unterstützung:

Regelmäßige Wartung und Überwachung verhindern die meisten Wiederherstellungsprobleme. Implementieren Sie die in diesem Leitfaden beschriebenen Präventionsmaßnahmen, um zukünftige Wiederherstellungsprobleme von MS SQL zu minimieren.


Über den Autor

Yuan Sheng ist ein erfahrener Datenbankadministrator (DBA) mit über 10 Jahren Erfahrung in SQL Server Umgebungen und Unternehmensdatenbankverwaltung. Er hat Hunderte von Datenbankwiederherstellungsszenarien in Finanzdienstleistungs-, Gesundheits- und Fertigungsunternehmen erfolgreich gelöst.

Yuan ist spezialisiert auf SQL Server Datenbankwiederherstellung, Hochverfügbarkeitslösungen und Leistungsoptimierung. Seine umfangreiche praktische Erfahrung umfasst die Verwaltung von Multi-Terabyte-Datenbanken, die Implementierung von Always On Availability Groups und die Entwicklung automatisierter Backup- und Wiederherstellungsstrategien für unternehmenskritische Geschäftssysteme.

Durch sein technisches Fachwissen und seinen praktischen Ansatz konzentriert sich Yuan auf die Erstellung umfassender Anleitungen, die Datenbankadministratoren und IT-Experten bei der Lösung komplexer SQL Server Herausforderungen effizient. Er bleibt auf dem Laufenden mit den neuesten SQL Server und die sich entwickelnden Datenbanktechnologien von Microsoft und testet regelmäßig Wiederherstellungsszenarien, um sicherzustellen, dass seine Empfehlungen den bewährten Vorgehensweisen der Praxis entsprechen.

Haben Sie Fragen zu SQL Server Wiederherstellung oder benötigen Sie zusätzliche Anleitung zur Datenbank-Fehlerbehebung? Yuan begrüßt Feedback und Vorschläge zur Verbesserung dieser technischen Ressourcen.

Jetzt teilen: