Go to Top

SQL Entmystifiziert 3: Wie kann eine Page-Level Recovery die SQL Wiederherstellungsvorkehrungen verbessern?

Page-Level Recovery

Bei sehr großen Microsoft SQL Server Datenbanken kann eine komplette Wiederherstellung viele Stunden dauern. In dieser Zeit kann die Datenbank nicht genutzt werden, um zu verhindern, dass Daten eingegeben werden und wieder verloren gehen, während die Informationen von Tape oder Festplatten zurückkopiert werden. Es ist also offensichtlich, dass in einer IT-Umgebung, wo eine hohe Verfügbarkeit gefordert ist, jede Ausfallzeit des Systems hohe Kosten verursacht und deshalb auf ein Minimum reduziert werden muss.

Glücklicherweise können die Page-level Wiederherstellungstechniken dazu genutzt werden, die Recovery-Zeiten auf ein Minimum zu begrenzen, dadurch dass die Datenmenge, die vom Backup-Medium zurück kopiert werden muss, reduziert wird. Seit der Veröffentlichung von Microsoft SQL Server 2005 haben Datenbankadministratoren (DBAs) die Möglichkeit einen „Page-level Restore“ durchzuführen, der ihnen erlaubt nur eine „Handvoll“ Seiten, anstatt kompletter Datensätze wiederherzustellen, und die Informationen in die originale Datenbank zurück zu kopieren.

Die Page-level Wiederherstellungsoption ist ideal in Situationen, bei denen Daten während der Schreibvorgänge durch einen fehlerhaften Festplatten-Controller, falsch konfigurierte Antivirus-Software oder einem IO-Subsystem beschädigt wurden. Besser noch: Page-level Wiederherstellungsoperationen für die Enterprise Editionen von Microsoft SQl Servern können auch online ausgeführt werden.

Voraussetzungen

Wie bei jeder Datenbank-Wiederherstellungs-Operation ist man auch bei einer Page-level Recovery auf eine vorhandene vollständige Sicherung angewiesen mit der man arbeiten kann. Wenn eine solche Sicherung nicht verfügbar ist, müssen Sie eine alternative Methode zur Wiederherstellung von Daten direkt von den Server-Festplatten finden (wie z.B. Ontrack PowerControls für SQL Server).

Und obwohl Sie die Page-level Wiederherstellung mit der Datenbank auch online durchführen können, sollten Sie auf Nummer Sicher gehen, indem Sie auf den Einzelnutzermodus (Single User Mode) umschalten, während Sie Daten übertragen:

 

ALTER DATABASE <DBName> SET SINGLE_USER
WITH ROLLBACK AFTER 10 SECONDS
GO

Dieser Befehl stellt sicher, dass jeder aus dem System ausgeloggt ist und dass sie nicht hineinkönnen bis Sie den Modus erneut ändern. Sie wollen außerdem sicherstellen, dass Sie auf jeden Fall das Ende der Protokolldatei (Logdatei) gesichert haben, sodass alle Transaktionen vollständig erfasst sind um weiteren Datenverlust zu vermeiden.

BACKUP LOG DBName
TO DISK = N'X:SQLBackupsDBName_TailEnd.trn'
GO

Herausfinden, welche Seiten korrupt sind…

In der Regel ist das erste Zeichen, dass etwas mit den Seiten nicht stimmt, wenn bei Ausführung eines SELECT-Befehls ein Inkonsistenz-Fehler generiert wird. Das Nachrichtenfenster des Microsoft SQL Servers wird eine Fehlermeldung wie diese zeigen:


Msg 5242, Level 22, State 1, Line 1
An inconsistency was detected during an internal operation in database ‘DBName’(ID:9) on page (1:254).
Please contact technical support. Reference number 4.
As you would expect, the page number referenced, 254, is the corrupt page that needs to be recovered.

Durchführung einer Page-Level SQL Server Wiederherstellung

Der Microsoft SQL Page-level Wiederherstellungsvorgang ist sehr ähnlich zu einer vollständigen Wiederherstellung, der einzige Unterschied ist die Verwendung des Befehls NORECOVERY:


RESTORE DATABASE DBName
PAGE = 'fileid:pageid'  -- e.g. 1:254
FROM DISK = 'X:SQLBackupsDBName_lastFull.BAK'
WITH
NORECOVERY
GO

Dieser Befehl wird die korrupte Seite durch diejenige aus dem Backup ersetzen und wiedereinfügen, ohne dass Sie den zeitraubenden Prozess einer vollständigen SQL Server-Wiederherstellung durchführen müssen. Sie können mehr als eine Seite gleichzeitig wiederherstellen einfach indem Sie zusätzliche fileid:pageid – Kombinationen – getrennt durch Kommata – anhängen.

Sie können testen, ob die Daten erfolgreich auf die betroffene Datenbank wiederhergestellt wurden, indem Sie DBCC CHECKDB ausführen – es sollte ohne Fehleranzeige beenden.

Die Page-Level SQL Server Wiederherstellung abschließen

Obwohl die korrupte Seite erfolgreich wiederhergestellt wurde, müssen Sie die Transaktionsprotokolle anwenden, um sicherzustellen, dass alle Daten vorhanden und korrekt sind. Für jedes Transaktionsprotokoll (transaktion log) das seit Ihrem letzten vollständigen Backup generiert wurde, führen Sie den RESTORE LOG Befehl aus:

RESTORE LOG DBName
FROM DISK = 'X:SQLBackupsDBName_LogFileFrom2PM.TRN'
WITH NORECOVERY
GO
RESTORE LOG DBName
FROM DISK = 'X:SQLBackupsDBName_LogFileFrom215PM.TRN'
WITH NORECOVERY
GO

Beachten Sie, dass die NORECOVERY-Option sicherstellt, dass Sie nichts anderes als die angegebenen Protokolldaten wiederherstellen. Schließlich müssen Sie jetzt das Endteil der Logdatei-Backup, wie bei den Voraussetzungen ausgeführt, anwenden:

RESTORE LOG DBName
FROM DISK = 'X:SQLBackupsDBName_TailEnd.trn
WITH RECOVERY

Dieses Mal wollen Sie die Datenbank wiederherstellen und nutzen deshalb den WITH RECOVERY Befehl.

An dieser Stelle können Sie die Datenbank erneut testen, um sicherzustellen, dass alles so funktioniert, wie es sollte. Sobald Sie zufrieden sind, schalten Sie die Datenbank wieder in den Multi-User-Modus, um den Zugang für die Anwender wiederherzustellen:

ALTER DATABASE AdventureWorks SET MULTI_USER
GO

Und das war es auch schon: Die Korruptionsprobleme wurden gelöst, ohne eine vollständige SQL Server Recovery durchzuführen. Die Page-level Wiederherstellungsoption macht es möglich, dass die Ausfallzeiten und die Beeinträchtigungen für die Nutzer auf ein Minimum begrenzt sind sowie auch die Kosten die mit dem Ausfall der Datenbank verbunden sind.