Versuchen Sie im Fehlerfall in jedem Fall als ersten Schritt noch eine Sicherung des Transaktionsprotokolls zu erstellen, damit die Wiederherstellung bis zum Fehlerpunkt möglich wird. Diese letzte Sicherung des Transaktionsprotokolls wird auch als Fragmentsicherung bezeichnet. Je nach Ausmaß des Fehlers sind jetzt verschiedene Möglichkeiten der Wiederherstellung vorhanden. Die folgenden Beispiele zeigen die Wiederherstellungsmöglichkeiten mithilfe des Management Studios und mithilfe von Transact-SQL Anweisungen.

Wiederherstellen einer Datenbank im SQL Server Management Studio

Wählen Sie im Kontextmenü der Datenbank den Punkt „Tasks“, „Sichern“ aus. Im Dialogfenster „Datenbank sichern“ kann jetzt der Sicherungstyp „Transaktionsprotokoll“ ausgewählt werden. Legen Sie ein Sicherungsziel für die Sicherung fest.

Wechseln Sie anschließend auf die Seite „Optionen“. Hier muss die Option „Protokollfragment sichern und Datenbank im Wiederherstellungsmodus belassen“ aktiviert werden. Klicken Sie anschließend auf „OK“ um den Sicherungsvorgang zu starten.

Kann die Sicherung des Transaktionsprotokolls gar nicht oder nur teilweise ausgeführt werden, sollten Sie in jedem Fall noch einen Versuch unternehmen das restliche Protokoll zu sichern: Öffnen Sie dazu ein neues Abfragefenster und versuchen Sie das Transaktionsprotokoll mit der Option „NO_TRUNCATE“ zu sichern.

BACKUP LOG [Ostwind] TO DISK = 'E:\SQLBackup\OstwindFragment.bak' WITH NO_TRUNCATE

Listing: Sichern des Transaktionsprotokollfragments

Schlägt auch diese Sicherung fehl, so kann die Datenbank nur bis zur letzten erfolgreichen Sicherung wiederhergestellt werden.

Nachdem die Fragmentsicherung durchgeführt wurde, kann die Datenbank wiederhergestellt werden. Wurde bei der Erstellung der Fragmentsicherung die Option „NO_RECOVERY“ angegeben, befindet sich die Datenbank jetzt bereits im Modus „Wiederherstellen“.

Abbildung: Die Datenbank wird im Management Studio mit „Wird wiederhergestellt“ markiert

Öffnen Sie den Dialog „Datenbank wiederherstellen“ über den Menüpunkt „Tasks“, „Wiederherstellen…“, „Datenbank“ im Kontextmenü der Datenbank.

Alle Einstellungen sollten vom Management Studio bereits richtig erkannt worden sein. Prüfen Sie in der Liste, ob die richtigen Sicherungssätze für die Wiederherstellung ausgewählt worden sind.

Abbildung: Datenbank wiederherstellen Dialog

In diesem Beispiel werden eine vollständige Sicherung, eine folgende differenzielle Sicherung sowie vier Transaktionsprotokollsicherungen wiederhergestellt. Bei der letzten Transaktionsprotokollsicherung handelt es sich um das zuvor gesicherte Protokollfragment.

Auf der Seite „Optionen“ können Sie festlegen, ob die Datenbank nach erfolgter Wiederherstellung wieder Online (betriebsbereit) geschaltet wird. Diese Option für den Wiederherstellungsstatus „Datenbank betriebsbereit belassen, indem für Transaktionen ohne Commit ein Rollback ausgeführt wird.“ ist standardmäßig aktiviert. Da für die Wiederherstellung alle verfügbaren Protokollsicherungen ausgewählt wurde, kann diese Einstellung übernommen werden. Klicken Sie anschließend auf „OK“, um den Wiederherstellungsprozess zu starten.

Falls es nicht möglich war, eine Fragmentsicherung durchzuführen, muss bei der Wiederherstellung explizit die Option „Vorhandene Datenbank überschreiben“ angegeben werden, ansonsten wird der Wiederherstellungsprozess nicht durchgeführt.

Wiederherstellung einer Datenbank bis zu einem bestimmten Zeitpunkt

Bei der Wiederherstellung der Datenbank müssen nicht alle Transaktionsprotokolle vollständig wiederhergestellt werden. Es ist auch möglich, die Wiederherstellung bis zu einem bestimmten Zeitpunkt zu aktivieren. Dabei wird – wie bei der normalen Wiederherstellung – der Dialog „Datenbank wiederherstellen“ geöffnet. Prüfen Sie zunächst in der Liste der Sicherungssätze, welche Zeiträume in welchem Sicherungssatz gesichert sind und markieren Sie nur alle Sicherungen bis zu diesem Zeitpunkt. Anschließend können Sie über die Schaltfläche bei „Bis zu diesem Zeitpunkt“ den Dialog „Zeitpunktwiederherstellung“ öffnen. Hier können Datum und Uhrzeit festgelegt werden.

Abbildung: Festlegen von Datum und Uhrzeit bei der Zeitpunktwiederherstellung

Bei der Version 9.00.1399 des Management Studios gibt es einen Fehler, der auftritt, wenn die Sprache für die Verbindung zum SQL Server auf Deutsch eingestellt ist. Das Management Studio verwendet für die Prüfung der Eingabe und auch beim Generieren des Wiederherstellungsskripts die amerikanische Schreibweise für den Zeitpunkt, also Monat/Tag/Jahr Stunden:Minuten:Sekunden. Bei einem Datum ab dem 13. des jeweiligen Monats erhalten Sie bereits beim Schließen des Fensters eine Fehlermeldung (Artihmetischer Überlauf). Bei einem Datum vor dem 13. wird das Datum falsch interpretiert und Sie erhalten unter Umständen eine Warnung, dass der gewünschte Zeitpunkt nicht in der Sicherung enthalten ist. Um trotz dieses Fehlers eine Zeitpunktwiederherstellung durchführen zu können, gehen Sie folgendermaßen vor:

Stellen Sie den Zeitpunkt wie oben beschrieben ein. Eventuelle Fehlermeldungen können Sie ignorieren. Klicken Sie nicht auf „OK“, um den Wiederherstellungsvorgang zu starten. Wählen Sie stattdessen den Punkt „Skript für Aktion in Fenster „Neue Abfrage“ schreiben“ aus. Anschließend können Sie den „Datenbank wiederherstellen“ Dialog über „Abbrechen“ verlassen. Im Visual Studio Management Studio finden Sie jetzt die generierte Abfrage. Hier muss die Datumsangabe für den STOPAT-Parameter angegeben werden. Verwenden Sie nach Möglichkeit das Internationale Datumsformat (Das hätten auch die Entwickler des Management Studios tun sollen). Also „jjjj-mm-ttThh:nn:ss“, für den 28. Januar 2006 17 Uhr 14 und 34 Sekunden wäre das also: „2006-01-28T17:14:34“.

RESTORE-Anweisung angepasst werden.

RESTORE LOG [Ostwind] FROM DISK = N'E:\SQLBackup\OstwindFragment.bak'
WITH FILE = 2, NOUNLOAD, STATS = 10, STOPAT = N'2006-01-28T17:14:34'
GO

Listing 1.3: Beispiel für eine korrigierte STOPAT-Option.

Nachdem Sie das Datum entsprechend geändert haben, können Sie den Wiederherstellungsprozess starten.

Wiederherstellen einer einzelnen Datei mit dem SQL Server Management Studio

Ist nur eine einzelne Datei beschädigt, so muss nicht die vollständige Datenbanksicherung wiederhergestellt werden, sondern es genügt das Wiederherstellen der jeweiligen Datei. Falls Sie die Enterprise Edition einsetzen, kann die Datenbank während des Wiederherstellungsprozesses sogar Online bleiben.

So gehen Sie vor, um eine einzelne Datei wiederherzustellen

Führen Sie zuerst eine Protokollfragmentsicherung durch. Falls Sie die Enterprise Edition verwenden und die Datenbank Online wiederherstellen möchten, müssen Sie die entsprechende BACKUP-Anweisung in einem Abfragefenster ausführen.

Öffnen Sie den Dialog „Dateien- und Dateigruppen wiederherstellen“ über den Menüpunkt „Tasks“, „Wiederherstellen“, „Dateien und Dateigruppen…“ im Kontextmenü der Datenbank.

Die Liste der Sicherungssätze umfasst jetzt auch Einträge für jede Datei die in einem Sicherungssatz vorhanden ist.

Wählen Sie die gewünschte Datei aus der Liste aus. Die nachfolgend benötigten Sicherungen werden automatisch markiert.

Abbildung: Auswahl einer einzelnen Datei für die Wiederherstellung

In den meisten Fällen macht es Sinn die Datei unter einem anderen Namen und gegebenenfalls auch an einem anderen Ort wiederherzustellen. Auf der Seite „Optionen“ können Sie den neuen Pfad für die Datei festlegen. Anschließend kann die Wiederherstellung gestartet werden.

Abbildung: Festlegen eines neuen Pfads und Dateinamens für eine Datendatei

Online-Wiederherstellung einer einzelnen Datei

Beim Starten der Datenbank Suedwind wurde die Datei „Suedwind_Import“ auf OFFLINE gesetzt. Die Platte auf der die Datei gespeichert war ist defekt. Die Datenbankdatei soll auf einer anderen Platte wieder hergestellt werden. Es existieren eine vollständige Sicherung der Datenbank und zwei Transaktionsprotokollsicherungen.

Zunächst wird eine Protokollfragmentsicherung durchgeführt:

USE MASTER
GO
BACKUP LOG Suedwind TO DISK='E:\SuedwindLog.bak'
WITH NO_TRUNCATE, NORECOVERY

Anschließend wird die “verlorene” Datei aus der Vollsicherung wiederhergestellt (Falls es eine Datei- oder Dateigruppensicherung gibt, kann natürlich auch diese für die Wiederherstellung verwendet werden). Bei der Wiederherstellung wird die Datei nicht am ursprünglichen Ort, sondern im Verzeichnis „L:\Data“ wiederhergestellt.

RESTORE DATABASE Suedwind FILE='Suedwind_Import'
FROM DISK='E:\SuedwindVoll.bak'
WITH MOVE 'Suedwind_Import' TO 'L:\DATA\Suedwind_Import.ndf', NORECOVERY

Unter Umständen kann die Wiederherstellung nicht durchgeführt werden, weil kein exklusiver Zugriff auf die Datenbank möglich ist:

Meldung 3101, Ebene 16, Status 1, Zeile 1Der exklusive Zugriff auf die Datenbank ist nicht möglich, da die Datenbank gerade verwendet wird.
Meldung 4348, Ebene 16, Status 1, Zeile 1
Fehler bei der Onlinewiederherstellung der 'Suedwind'-Datenbank.
Führen Sie stattdessen bei Bedarf eine Offlinewiederherstellung aus. Eine Offlinewiederherstellung wird mit BACKUP LOG WITH NORECOVERY initiiert.
Meldung 3013, Ebene 16, Status 1, Zeile 1
RESTORE DATABASE wird fehlerbedingt beendet.

In diesem Fall sollten alle Benutzerverbindungen beendet und die Datenbank in den Einzelbenutzermodus umgeschaltet werden:

ALTER DATABASE SUEDWIND
SET OFFLINE WITH ROLLBACK IMMEDIATE
ALTER DATABASE SUEDWIND SET ONLINE, SINGLE_USER

Anschließend kann die RESTORE-Anweisung – wie zuvor beschrieben - ausgeführt und direkt anschließend die Datenbank wieder in den Mehrbenutzer-Modus umgeschaltet werden; damit können andere Benutzer wieder auf die Datenbank zugreifen:

ALTER DATABASE SUEDWIND SET MULTI_USER

Wird jetzt auf eine Tabelle zugegriffen, die sich in der gerade wiederhergestellten Dateigruppe befindet, wird eine entsprechende Warnung ausgegeben:

Meldung 8653, Ebene 16, Status 1, Zeile 1
Der Abfrageprozessor kann keinen Plan für die Tabelle oder Sicht 'Bestellungen' erstellen, da sich die Tabelle in einer Dateigruppe befindet, die nicht online ist.

Der Zugriff auf Tabellen in den Datengruppen PRIMARY und DATEN ist weiterhin möglich.

Zur Sicherheit kann nochmals überprüft werden, welche Protokollsicherungen in der Sicherungsdatei vorhanden sind:

RESTORE HEADERONLY FROM DISK='E:\Suedwindlog.bak'

Anschließend werden alle Transaktionsprotokollsicherungen wiederhergestellt:

RESTORE LOG Suedwind FROM DISK='E:\Suedwindlog.bak' WITH NORECOVERY
RESTORE LOG Suedwind FROM DISK='E:\Suedwindlog.bak' WITH NORECOVERY, FILE=2
RESTORE LOG Suedwind FROM DISK='E:\Suedwindlog.bak' WITH RECOVERY, FILE=3

Die Dateigruppe IMPORT ist jetzt wieder Online. Zugriffe auf die Tabellen können durchgeführt werden.

Die Online-Wiederherstellung steht nur in der Enterprise Edition zur Verfügung. In den anderen Ausgaben des SQL Servers muss das Wiederherstellen offline erfolgen; die Wiederherstellungsschritte sind analog, beim Erstellen der Protokollfragmentsicherung kann direkt die NORECOVERY-Option angegeben werden. Während des Wiederherstellungsvorgangs ist in diesem Fall jedoch kein Zugriff auf die Datenbank möglich.

Erstellen Sie nach der Wiederherstellung der Datenbank eine neue vollständige Datenbanksicherung.

Einige zusätzliche Hinweise zu den BACKUP LOG-Optionen

Auch wenn diese Beispiele bereits die wichtigsten Optionen und ihre Verwendung beim Erstellen von Transaktionsprotokollsicherungen gezeigt haben, hier noch eine genauere Gegenüberstellung der Optionen:

Die Option NORECOVERY schaltet die Datenbank in den Wiederherstellungsmodus, d.h. es sind keine Zugriffe auf die Daten mehr möglich, bis die Datenbank wiederhergestellt worden ist.

NO_TRUNCATE sichert das Transaktionsprotokoll ohne auf die Datendateien zuzugreifen. Außerdem wird die Sicherungsaktion selbst nicht im Transaktionsprotokoll vermerkt, d.h. die LSN (Log Sequence Number) wird nicht verändert. Die Option COPY_ONLY läßt ebenfalls die LSN unberührt, aber nur wenn gleichzeitig die Option CONTINUE_AFTER_ERROR angegeben wird.

Haben Sie die vollständige Sicherung und alle nachfolgenden Transaktionsprotokollsicherungen mit der Option NORECOVERY ausgeführt, verbleibt die Datenbank im Status „RESTORING“. Um die Datenbank nun wieder in den Online-Zustand zu bringen, können Sie die Anweisung BACKUP LOG nur mit der WITH RECOVERY Option angeben:

RESTORE LOG Suedwind WITH RECOVERY

Wiederherstellung von Datenbanken, Datenbankdateien und Datenseiten

Durchführen einer Online-Wiederherstellung bei beschädigten Datenseiten

Das folgende Beispiel zeigt welche Schritte notwendig sind, um fehlerhafte Seiten einer Datenbank wiederherzustellen. In der Beispieldatenbank AdventureWorks ist es seit der letzten Vollsicherung zu einem Fehler in einer Datenbankseite gekommen. Anwender berichten, dass bei einer Abfrage der Tabelle „WorkOrder“ in der Datenbank der folgende Fehler auftritt:

Meldung 824, Ebene 24, Status 2, Zeile 1

SQL Server hat einen logischen, konsistenzbasierten E/A-Fehler gefunden: Falsche Prüfsumme (erwartet: 0xb1e2fd6d; tatsächlich: 0x7f60e666). Der Fehler ist beim Lesen von Seite (1:15618) in der Datenbank mit der ID 8 bei Offset 0x00000007a04000 in der Datei 'dateiname.mdf' aufgetreten.
Weitere Informationen finden Sie möglicherweise in anderen Fehlermeldungen im SQL Server-Fehlerprotokoll oder im Systemereignisprotokoll. Dies ist ein schwerer Fehler, der die Datenbankintegrität bedroht und sofort behoben werden muss. Führen Sie eine vollständige Überprüfung der Datenbankkonsistenz aus (DBCC CHECKDB). Dieser Fehler kann durch viele Faktoren verursacht werden.
Weitere Informationen finden Sie in der SQL Server-Onlinedokumentation.

Eine Überprüfung der Datenbank mit DBCC CHECKDB gibt weitere Informationen zum Fehler:

DBCC CHECKDB (Adventureworks)
GO

DBCC gibt folgende Ergebnismeldung aus:

Von CHECKDB wurden 0 Zuordnungsfehler und 2 Konsistenzfehler in der 'AdventureWorks'-Datenbank gefunden.repair_allow_data_loss ist die minimale Reparaturstufe für die Fehler, die mit DBCC CHECKDB (AdventureWorks) gefunden wurden.Die DBCC-Ausführung wurde abgeschlossen. Falls DBCC Fehlermeldungen ausgegeben hat, wenden Sie sich an den Systemadministrator.

In der kompletten Fehlerausgabe von DBCC findet sich die tatsächliche Ursache, also eine genaue Angabe welche Objekte und Seiten von dem Fehler betroffen sind. In diesem Beispiel tritt der Fehler in der Tabelle „Workorder“ auf:

DBCC-Ergebnis für 'Production.WorkOrder'.Meldung 8928, Ebene 16, Status 1, Zeile 1Objekt-ID 414624520, Index-ID 1, Partitions-ID 72057594047365120, Zuordnungseinheits-ID 72057594052804608 (In-row data-Typ): Seite (1:15618) konnte nicht verarbeitet werden. Einzelheiten finden Sie in anderen Fehlermeldungen.Meldung 8939, Ebene 16, Status 98, Zeile 1Tabellenfehler: Objekt-ID 414624520, Index-ID 1, Partitions-ID 72057594047365120, Zuordnungseinheits-ID 72057594052804608 (In-row data-Typ), Seite (1:15618). Fehler bei Test (IS_OFF (BUF_IOERR, pBUF->bstat)). Die Werte sind 29493513 und -4.Es sind 72452 Zeilen auf 523 Seiten für das "Production.WorkOrder"-Objekt vorhanden.Von CHECKDB wurden 0 Zuordnungsfehler und 2 Konsistenzfehler in der 'Production.WorkOrder'-Tabelle (Objekt-ID 414624520) gefunden.

Im einfachen Wiederherstellungsmodell wäre in diesem Fall die Option DBCC CHECKDB mit der Option ALLOW_DATA_LOSS die einzige Möglichkeit den Fehler zu beheben. Diese Methode führt jedoch unter Umständen zum Verlust der Daten in der betroffenen Seite. Da die Beispieldatenbank im vollständigen Wiederherstellungsmodell betrieben wird, kann eine gezielte Wiederherstellung der beschädigten Seite durchgeführt werden.

Die Ausgabe der DBCC-Konsistenzprüfung enthält bereits die notwendigen Informationen, die für die Wiederherstellung einzelner Seiten benötigt werden (Seite 1:15618 ist beschädigt, dass heißt die Seite 15618 in der Datei 1 weist Fehler auf.)

Die Informationen zu fehlerverdächtigen Seiten werden auch in der Tabelle suspect_pages in der Datenbank msdb protokolliert.

Eine Abfrage der Tabelle zeigt folgenden Eintrag für die Datenbank AdventureWorks:

database_id	file_id	page_id	event_type	error_count
8	1	15618	2	3

Der „event_type“ 2 bedeutet, dass eine ungültige Prüfsumme entdeckt wurde.

Weitere Dateiinformationen zu fehlerhaften Seiten ermitteln

Die folgende Abfrage ermittelt alle fehlerverdächtigen Seiten in der aktuellen Datenbank. In der Ausgabe wird der logische und physikalische Dateiname ebenfalls angezeigt.

SELECT DB_NAME(database_id) Datenbank,
df.name [logischer Dateiname],
df.physical_name [physikalischer Dateiname],
df.state_desc Dateistatus,
page_id Seite,
event_type Ereignistyp,
error_count Fehlerzahl
FROM msdb..suspect_pages sp
INNER JOIN sys.database_files df
ON df.file_id = sp.file_id
WHERE database_id = DB_ID()

Nachdem der Fehler eingegrenzt ist, kann jetzt die beschädigte Seite aus der vollständigen Datenbanksicherung wiederhergestellt werden:

-- Sicherstellen, dass der Ausführungskontext nicht die beschädigte
-- Datenbank verwendet:
USE MASTER
GO
-- Die fehlerhafte Seite wiederherstellen
RESTORE DATABASE AdventureWorks
PAGE='1:15618' FROM DISK='E:\AWFULL1.bak' WITH NORECOVERY;

Das Datenbankmodul gibt die folgende Bestätigung der Wiederherstellung aus:

1 Seiten wurden für die 'AdventureWorks'-Datenbank, Datei 'AdventureWorks_Data' für Datei 1, verarbeitet.

RESTORE DATABASE ... FILE=<name> hat erfolgreich 1 Seiten in 5.351 Sekunden verarbeitet (0.001 MB/s).

Damit ist die Seite zwar wiederhergestellt, aber ein Zugriff auf die Tabelle ist noch nicht erfolgreich: Abfragen, die versuchen auf die beschädigte Seite zuzugreifen, erhalten die folgende Fehlermeldung:

Meldung 829, Ebene 21, Status 1, Zeile 1Die Datenbank-ID 8, Seite (1:15618) ist als 'RestorePending' gekennzeichnet, was ein Hinweis auf einen beschädigten Datenträger sein kann. Führen Sie eine Wiederherstellung aus, um diesen Fehler zu beheben.

Damit die Seite wieder zugänglich gemacht werden kann, muss noch eine Sicherung der seit der letzten Sicherung durchgeführten Transaktionen erstellt werden. (Achten Sie bei dieser Sicherung darauf, dass eine sogenannte Protokollfragment-Sicherung ausgeführt wird) Diese Sicherung kann anschließend mit der Option „RECOVERY“ wiederhergestellt werden. Dadurch wird die Seite wieder Online gebracht.

BACKUP LOG AdventureWorks
TO DISK='E:\AWLOG1.BAK' WITH NO_TRUNCATE

Anschließend kann die Transaktionsprotokollsicherung wiederhergestellt werden:

RESTORE LOG AdventureWorks
FROM DISK='E:\AWLOG1.BAK' WITH RECOVERY
GO

Ergebnis

0 Seiten wurden für die 'AdventureWorks'-Datenbank, Datei 'AdventureWorks_Data' für Datei 1, verarbeitet.

RESTORE LOG hat erfolgreich 0 Seiten in 0.017 Sekunden verarbeitet (0.000 MB/s).

Falls Sie sich fragen, warum dieser Wiederherstellungsvorgang notwendig ist, obwohl ja offensichtlich keine Seiten verarbeitet wurden: Es ist durchaus möglich, dass die betroffene Seite im Zeitraum zwischen der vollständigen Datenbanksicherung und dem Auftreten des Fehlers noch geändert wurde. Der Wiederherstellungsprozess ist notwendig, um zu prüfen, ob die Seite seit der Sicherung noch irgendwie verändert wurde. Wären Änderungen im Transaktionsprotokoll vorhanden, hätte der Wiederherstellungsprozess diese Änderungen an der Seite noch nachgezogen. Erst nachdem dieser Prüfprozess durchlaufen wurde, ist sichergestellt, dass die Seite wieder auf einem konsistenten Zustand ist und Online geschaltet werden kann.

Wenn Sie jetzt noch einen Blick in die Tabelle suspect_pages in der Datenbank msdb werfen, werden Sie feststellen, dass der Eintrag der fehlerverdächtigen Seite dort weiterhin vermerkt ist – die Einträge werden also bei erfolgreicher Wiederherstellung nicht automatisch gelöscht. Dadurch können Konsistenzfehler über einen längeren Zeitraum nachverfolgt werden. Sie können die betreffenden Zeilen – wenn gewünscht - manuell löschen.

Natürlich kann es auch vorkommen, dass die fehlerhaften Seiten nicht in der letzten vollständigen Datenbanksicherung enthalten sind, da die Seite erst nach der Sicherung erstellt wurde. In diesem Ausnahmefall kann die Wiederherstellungssequenz auch mit einer differenziellen Datenbanksicherung oder einer Transaktionsprotokollsicherung beginnen.

Die Wiederherstellung von einzelnen Datenbankseiten wird übrigens nicht direkt in der Oberfläche des SQL Server Management Studios unterstützt.

Falls bei der Prüfung der Datenbank eine große Zahl von beschädigten Seiten gefunden wird, so sollte die Datenbank oder betroffene Datei besser vollständig wiederhergestellt werden. Prüfen Sie für diesen Fall im Fehlerprotokoll, ob es Hinweise auf I/O-Fehler bei bestimmten Dateien gegeben hat und verschieben Sie die Dateien bei der Wiederherstellung zur Sicherheit an einen anderen Ort.

Kein Zugriff auf des Transaktionsprotokoll

Alle bisherigen Beispiel gingen davon aus, dass ein Teil des Datenbereichs der Datenbank beschädigt ist. Welche Möglichkeiten bestehen, wenn das Transaktionsprotokoll beschädigt ist?

In diesem Fall ist natürlich keine Sicherung des Transaktionsprotokolls mehr möglich. Das heißt, es ist nur eine Wiederherstellung bis zum Stand der letzten Sicherung möglich.

Wurde das Transaktionsprotokoll beschädigt nachdem die Datenbank Offline geschaltet wurde, versucht der SQL Server das Transaktionsprotokoll selbstständig neu zu erstellen.

Sind alle Datendateien noch vorhanden, gibt es als Notfalllösung noch den sogenannten „Notfallmodus“. Über die ALTER DATABASE-Anweisung kann die Datenbank in den Notfallmodus gesetzt werden. In diesem Modus kann der Systemadministrator lesend auf die Datenbank zugreifen. Damit ist es möglich alle vorhandenen Daten noch zu exportieren. Eine konsistente Wiederherstellung der Datenbank ist über diesen Modus jedoch nicht garantiert.

Wiederherstellen von Datenbanken auf einem anderen Server

Soll eine Datenbank auf einem anderen Rechner wiederhergestellt werden, kann es zu Problemen bei der Zuordnung von Datenbankbenutzern zu Anmeldungen (Logins) kommen. Die Datenbankbenutzer sind in der Datenbank gespeichert, die Verbindung zur Anmeldung (Login) wird über die Spalte sid (Security Identifier) hergestellt. Die Anmeldungen (Logins) selbst sind jedoch in der master-Datenbank gespeichert. Wird die Datenbank auf einem anderen Rechner wiederhergestellt, stimmen die Werte in der sid-Spalte der Datenbank nicht mit den Werten in der master-Datenbank auf dem Zielserver überein. Diese „verwaisten“ Benutzereinträge müssen nach der Wiederherstellung der Datenbank manuell korrigiert werden.

Eine Übersicht der Anmeldungen auf dem Zielserver erhalten Sie mithilfe der Abfrage SELECT * FROM sys.server_principals. Die Liste der Datenbankbenutzer kann über die Systemsicht sys.database_principals gewonnen werden. Für alle SQL Server Benutzer und Windows Benutzer in der Datenbank muss ein entsprechender Eintrag in sys.server_principals zu finden sein.

Für SQL Server Benutzer gibt es die Prozedur sp_change_users_login, die dabei hilft, falsche oder fehlende Benutzerzuordnungen wieder herzustellen.

EXEC sp_change_users_login 'Report'

Erstellt eine Liste aller SQL Server Benutzer, für die keine gültige Zuordnung mehr vorhanden ist. Mithilfe der Optionen „Update_One“ oder „Auto_Fix“ können die Zuordnungen wieder hergestellt werden.

Die folgende Abfrage kann verwendet werden, um alle „verwaisten“ Benutzer (sowohl SQL Server Benutzer als auch Windows-Benutzer) in einer wiederhergestellten Datenbank anzuzeigen:

SELECT name, type_desc, sid
FROM sys.database_principals dp
WHERE sid IS NOT NULL
AND type IN ('U', 'S')
AND name != 'guest'
AND NOT EXISTS ( SELECT * FROM sys.server_principals sp
WHERE sp.sid = dp.sid
´)

Bei Windows-Benutzern tritt dies Problematik nur auf, wenn es sich um lokale Benutzer- oder Gruppenkonten handelt oder um Domänenkonten und der Zielserver keinen Zugriff auf die verwendete Domäne besitzt (keine vertraute Domäne)

Link-Tipp zum Thema "Microsoft SQL Server": www.berndjungbluth.de/sqlfaq/sqlfaq.htm

Die umfangreichste deutsche Site zu MS SQL Server FAQ. Lohnt auf jeden Fall einen Besuch.