Artikel
09/24/2010

Reagieren auf SQL Server-Wiederherstellungsfehler als Folge von beschädigten Sicherungen

Wiederherstellungsfehler treten auf, wenn das Sicherungsmedium beschädigt ist. Wiederherstellungsfehler können vom Betriebssystem gemeldet oder von Prüfsummen erkannt werden. In beiden Fällen haben Sie drei Möglichkeiten:

Beheben des Fehlers und erneutes Starten des Wiederherstellungsvorgangs.
Fortsetzen der Wiederherstellung trotz Fehlern und Reparieren der Datenbank nach Abschluss der Wiederherstellung.
Abbrechen des Wiederherstellungsvorgangs und Verwenden eines alternativen Wiederherstellungsplans, der die beschädigte Sicherung meidet.

Hinweis
Der Mediensatz oder Sicherungssatz muss eine bestimmte Mindestmenge richtiger Informationen enthalten, damit er als Microsoft Tape Format (MTF) identifiziert werden kann. Falls dies nicht der Fall ist, wird RESTORE beendet und angezeigt, dass das Sicherungsformat ungültig ist.

Beheben des Fehlers und erneutes Starten des Wiederherstellungsvorgangs

Fehler können folgendermaßen behoben werden:

Wenn ein Fehler auf einem Bandmedium aufgetreten ist, können Sie das Bandlaufwerk reinigen oder austauschen.
Für Datenträger können Sie den Medienfehler beseitigen und die beschädigte Datei ersetzen.
Wenn ein Mediensatz gespiegelt ist, können Sie das beschädigte Medium durch das entsprechende Medium aus einer anderen Spiegelkopie ersetzen.

Fortsetzen trotz Fehlern

Vorsicht
Sie können in einer RESTORE-Anweisung WITH CONTINUE_AFTER_ERROR angeben, um zu versuchen, die Datenbank wiederherzustellen. Es gibt jedoch zahlreiche verschiedene Beschädigungen, die das Wiederherstellen einer Datenbank verhindern. Daher wird nachdrücklich empfohlen, die Option CONTINUE_AFTER_ERROR erst zu verwenden, wenn alle anderen Lösungsmöglichkeiten erschöpft sind.

Durch die Option <legacyBold>CONTINUE_AFTER_ERROR</legacyBold> wird ein Wiederherstellungsvorgang nach dem Auftreten von Fehlern fortgesetzt, wobei nur die Daten, die wiederhergestellt werden können, wiederhergestellt werden. Ein Rollforward wird ausgeführt, und daraufhin können Transaktionsprotokollsicherungen angewendet werden. Wenn während des Rollforwards ein Fehler auftritt, der das Erreichen des Zielzeitpunkts verhindert, erfolgt ein Eintrag im Protokoll. Falls möglich, wird die Datenbank am Zielpunkt online geschaltet. Falls die Wiederherstellung jedoch nicht abgeschlossen werden kann, bleibt die Datenbank offline.

Wie viele Daten verloren gehen, hängt vom gefundenen Fehler ab. Beispielsweise wird durch eine fehlerhafte Prüfsumme auf einer Seite nur diese Seite in Frage gestellt. Das Lesen und Verarbeiten des Mediums wird fortgesetzt. Dagegen kann bei einem von einem Bandmedium gemeldeten E/A-Fehler die Wiederherstellung über den Fehler hinaus verhindert werden, weshalb der Rest des Bands nicht wiederhergestellt werden kann.

Wenn eine Wiederherstellung laut Konfiguration nach dem Auftreten von Fehlern fortgesetzt werden soll, werden Seiten, deren Überprüfung Fehler generiert, auf den Datenträger geschrieben und in der suspect_pages-Tabelle mit den fehlerverdächtigen Seiten sowie im Fehlerprotokoll protokolliert.

Bewährte Methoden: Sehen Sie Fehlerdetails in den Fehlerprotokollen ein, wenn Sie bei der Wiederherstellung von Daten die Option WITH CONTINUE_AFTER_ERROR verwenden. Speichern Sie außerdem alle Meldungen, die direkt von der RESTORE-Anweisung ausgegeben werden, um sie später analysieren zu können.

So setzen Sie den Fortgang trotz Fehlern fort

Die grundlegende Syntax der RESTORE-Anweisung lautet:

RESTORE DATABASE database_name FROM backup_device WITH CONTINUE_AFTER_ERROR, [ NORECOVERY ]

Verwalten der Offlinedatenbank

Am Ende einer Wiederherstellungssequenz, die trotz Fehlern fortgesetzt wird, können Sie die Datenbank möglicherweise mit DBCC CHECKDB reparieren. Damit CHECKDB nach der Verwendung von RESTORE CONTINUE_AFTER_ERROR möglichst konsistent ausgeführt wird, empfiehlt es sich, in Ihrem DBCC CHECKDB-Befehl die WITH TABLOCK-Option zu verwenden. Weitere Informationen finden Sie unter DBCC CHECKDB (Transact-SQL). Alle Reparaturoptionen sind verfügbar. Führen Sie DBCC CHECKDB ohne Reparaturoption aus, um die erforderliche minimale Reparaturstufe anzuzeigen. Beachten Sie, dass in extremen Fällen nicht genügend Informationen zum Reparieren der Datenbank vorhanden sein können.

Um beschränkten Zugriff auf die vorliegenden Daten zu erhalten, können Sie mithilfe der Option EMERGENCY der ALTER DATABASE-Anweisung den Notfallmodus für die Datenbank aktivieren.