Notfallwiederherstellung bei SQL Server

  • Artikel

SQL Server: Wiederherstellen von Daten mithilfe von Datensicherungen

Paul S. Randal

T hier nicht viel Sinn, wobei SQL Server-Sicherungen, es sei denn, Sie wissen, wie Sie diese wiederherstellen können. Wenn Sie etwas komplizierter als nur eine vollständige Datenbanksicherung verfügen, können Sie ihm müssen wissen, einige Optionen RESTORE die Datenbank erfolgreich auf den gewünschten Punkt rechtzeitig wiederherstellen können.

Dies ist sogar noch mehr der Fall, wenn Sie eine komplizierte Datenbanklayout oder eine komplexe Sicherungsstrategie und in der Lage wiederherzustellen, z. B. eine einzelne Datei oder Dateigruppe, oder partielle Datenbankverfügbarkeit nutzen möchten.
Solange Sie über eine effektive Sicherungsstrategie verfügen, und die Sicherungen gültig sind, sollten Sie zur Wiederherstellung nach eines Notfalls Ihre Recovery Time Objective (RTO) und Ihre RPO (Recovery Point Objective) können. Im ersten Artikel dieser dreiteiligen Serie erörtert die verschiedenen Typen von Sicherungen und zum Formulieren einer Sicherungsstrategie (Siehe "Grundlegendes zu SQL Server-Sicherungen" in der Ausgabe Juli 2009).

In diesem Artikel werde ich erläutern, wie Wiederherstellung funktioniert und wie Sie einige der häufigeren Wiederherstellungsoperationen durchführen. Es wird hilfreich sein, wenn Sie gelesen haben, im backup-Artikel und die Hintergrundinformationen in diesem Artikel Einführung erwähnt. Ich werde Erläutern Sie einigen weitere knifflig Operationen, wie das Durchführen einer Point-in-Time-Wiederherstellung und eine Onlinewiederherstellung piecemeal mit partiellen Datenbankverfügbarkeit.

Genau wie im vorherigen Artikel auf BACKUP werde ich nicht erklären, wie die RESTORE-Syntax funktioniert oder die entsprechenden Schritte für alle Wiederherstellungsoperationen durchlaufen. SQL Server-Onlinedokumentation ist eine hervorragende Auftrag. Weitere Informationen finden Sie unter""RESTORE (Transact-SQL)" klicken Sie für Weitere Informationen im Thema verteilt insbesondere in den Beispielen. Es sind tatsächlich so viele Optionen, um RESTORE, dass es ein ganze andere Thema erläutern Sie, diese ist! " Sichern und Wiederherstellen von Gewusst-wie-Themen (SQL Server Management Studio)"erläutert, wie die Tools verwenden, um Wiederherstellungen durchführen.

Die vier Phasen des wiederherstellen

Beginnen wir mit der Wiederherstellung tatsächlich Funktionsweise. Ein Wiederherstellungsvorgang hat bis zu vier Phasen:

  1. Dateierstellung und Initialisierung
  2. Kopieren von Daten und/oder Transaktion Protokoll
  3. Wiederholen Sie die Phase der Wiederherstellung
  4. UNDO-Phase der Wiederherstellung

Eine der wichtigsten Ziele der Notfallwiederherstellung besteht darin, möglichst schnell die Datenbank online zu schalten. Wenn Ihr Plan zur Wiederherstellung umfasst das Wiederherstellen von Sicherungen (statt, z. B. Failover zu einer Datenbank Spiegelung), Sie nun den Wiederherstellungsvorgang so schnell wie möglich sein soll. Mit jedem der vier Wiederherstellung Schritte beachten ist alles, was Sie tun können, um diese beschleunigen?

Die erste Schritt kann im Wesentlichen übersprungen werden, wenn die Daten- und Protokolldateien Dateien bereits vorhanden sind. Dies bedeutet, wenn Sie eine vorhandene Datenbank überschreiben die Datenbank löschen nicht vor dem Ausführen der Wiederherstellung. Verwenden Sie stattdessen auf der ersten Wiederherstellungsvorgang die Option WITH REPLACE, um SQL Server die vorhandenen Dateien verwenden. Wenn die Dateien nicht vorhanden sind, werden Sie erstellt und anschließend initialisiert werden. Erstellen der Datei ist sehr schnell, aber der Prozess der Sie NULL-Initialisierung kann sehr langsam sein.

Aus Sicherheitsgründen und in der Standardeinstellung sind alle Datenbankdateien 0 (null) initialisiert. Sie können die sofortige Dateiinitialisierung für die SQL Server-Instanz, welche überspringt die genullt für Datendatei erstellen und wachsen Operationen, einschließlich der während einer Wiederherstellung--Stunden Ausfallzeit, möglicherweise zu speichern, selbst wenn die Datendateien nur Gigabyte groß sind erforderlich. Transaktionsprotokolldateien sind immer 0 (null) initialisiert aufgrund der zirkulären des Transaktionsprotokolls selbst.

Lesen Sie mehr über alle diese durch Verweise auf Books Online, in meinem "Instant Initialization" Blog-Beitrag-Kategorie.

Werden Sie vielleicht über die zweite Phase--warum, dass das Element "und/oder Transaktionsprotokoll"? Wenn Sie im vorangegangenen Artikel gelesen haben, werden Sie daran denken, dass alle vollständige und differenzielle Sicherungen auch einige Datensätze im Transaktionsprotokoll, damit die Datenbank um bis zu einem transaktionell konsistent wiederhergestellt werden angegeben. Phase zwei ist eine reine Kopiervorgang--keine Verarbeitung der Daten erfolgt--daher ist die wichtigste Möglichkeit, dies beschleunigen, einem better-performing e/a-Teilsystem. Hierbei handelt es sich um eine die Male es akzeptabel, "Hardware an das Problem lösen." ist

Die andere Möglichkeit zum Beschleunigen der Kopierphase ist eine Art von Sicherung Komprimierungstechnologie, entweder systemeigen oder über eine der verschiedenen Lösungen von Drittanbietern mit SQL Server 2008 verwenden. Die zwei Teile der Kopierphase sind von den Sicherungsmedien lesen und in die Dateien Daten und/oder Protokolldateien geschrieben. Wenn Sie weniger Lesevorgänge (mit komprimierte Sicherungsmedien) tun können, können Sie den Gesamtprozess zu Lasten des eine kleine Menge an CPU-Ressourcen beschleunigen.

Drei und vier Phasen sind zum Ausführen der Wiederherstellung auf das Transaktionsprotokoll, um die Datenbank bis zu einem transaktionell konsistent rechtzeitig zu schalten. Ich erläutert die Details der Wiederherstellung im Februar 2009 Artikel "Grundlegendes zur Protokollierung und Wiederherstellung in SQL Server". Beachten Sie, dass die phase vier ist optional, wie ich später eingehen werde.

Reicht es zu sagen, dass weitere Transaktionsprotokoll, muss bei einer Wiederherstellung wiederhergestellt werden, desto längere die Wiederherstellung dauert. Dies bedeutet, die wiedergeben, wenn, z. B. eine vollständige Datenbanksicherung von vor einer Woche erfolgte und stündlich Transaktionsprotokollsicherungen seit dann den Wiederherstellungsvorgang im Wesentlichen wird die Buchungen aus der letzten Woche vor dem abschließen. Ich behandelt eine Lösung dafür im vorherigen Artikel--differenzielle Sicherungen in einer Sicherungsstrategie full und Protokoll hinzufügen.

Eine differenzielle Datenbanksicherung enthält alle die Datendatei, die seit der letzten vollständigen Datenbanksicherung geändert haben, und kann in einem Wiederherstellungsvorgang verwendet werden, um zu vermeiden, dass die Transaktionen wiedergeben, die in dem Zeitraum zwischen der vollständigen Datenbanksicherung und einer differenziellen Datenbanksicherung aufgetreten. Dies kann der Zeitaufwand für die Wiederherstellung der Datenbank erheblich verringern jedoch zu Lasten des eine etwas komplizierter Sicherungsstrategie.

Weitere Informationen finden Sie in der Onlinedokumentation unter dem Thema "Optimieren der Sicherungs- und Wiederherstellungsleistung in SQL Server".

Was sollte wiederherstellen?

Notfall wird als Erstes müssen Sie tun, was beschädigt wurde, funktionieren, wie dies geschieht, um die Aktionen zu diktieren, die Sie ausführen müssen, um die Wiederherstellung nach dem Datenverlust. Für Medien Speicherausfalls schließen Sie die Möglichkeiten:

  • Schaden für die gesamte Datenbank (beispielsweise wurde zerstört, was die Datenbank gespeichert wurde, oder die Datenbank eine einzelne Datendatei wurde und Sie beschädigt wurde).
  • Beschädigung von einer einzigen Dateigruppe einer Datenbank Multi-Dateigruppe.
  • In einer Datei von einer multi-file Dateigruppe beschädigen.
  • Für eine einzelne Seite in der Datenbank beschädigen.
  • Schäden, die über die Datenbank verbreitet werden.

Sie können den Schaden anhand über SQL Server-Fehlerprotokoll für Benachrichtigungen, die Datei(en) nicht mehr zugegriffen werden kann, sind ermitteln, die Seite Lese-(für Instanz Seite Prüfsumme Fehler oder einen Fehler Erkennung zerrissener Seiten) sind Fehler aufgetreten, oder, dass allgemeine Beschädigung gefunden wurde. Wenn Schaden aufgetreten ist, ist es normalerweise empfehlenswert, zum Ausführen des DBCC CHECKDB Konsistenzüberprüfung Vorgangs um eine Vorstellung davon, wie weit verbreitet beschädigt ist.

Eine Erläuterung der Konsistenzüberprüfung würde den Rahmen dieses Artikels sprengen, aber Sie können ein Video einer Präsentation, die ich auf der Tech-Ed IT Forum im November 2008 mit dem Titel vorgenommen. "Beschädigung Survival Techniken", und hören Sie ein TechNet-Radio Gespräch aus weiter oben in diesem Jahr, in dem eine Beschädigung der Datenbank (direktes Herunterladen eingegangen Verknüpfungen sind, hier).

Verlorener Daten sind nicht beschränkt auf e/a-Subsystem oder Server-Fehler--Es ist auch menschlichem Versagen zu berücksichtigen. Datenbanktabellen (oder Daten aus diesen) werden durch schlecht programmierten Anwendungen oder unvorsichtig Transact-SQL-Anweisungen (Szenario "Ich nicht bewusst war auf dem Produktionsserver"), die häufig versehentlich gelöscht. In solchen Fällen kann es sehr schwierig sein zu ermitteln, was wiederhergestellt werden muss und von welcher in der Zeit Stelle, insbesondere dann, wenn niemand einrichten, dass des Fehlers besitzt. Sie könnten Glück mit Standardberichten von der Standardablaufverfolgung, in denen der DDL-Vorgang weiterhin verfügbar ist oder die DELETE-Anweisung wurde aufgefangen durch eigene Protokollierung-- jedoch häufig kein Datensatz vorhanden ist, der, was in die Datenbank hat. Erörtert in dieser Situation ausführlicher später wiederherstellen. Unabhängig davon, wer die versehentliche Datenlöschung durchgeführt oder wenn geschehen ist, desto länger warten Sie zur Wiederherstellung-- oder mehr Zeit, die vergeht, bis Sie das Problem--der komplexeren aufmerksam gemacht werden, die Sie wiederhergestellt werden kann.

Folglich als eine erste Schritt, wenn die Datenbank in das VOLLSTÄNDIGE Wiederherstellungsmodell ausgeführt wird und das Transaktionsprotokoll nicht beschädigt ist, ist eine Sicherung Tail von Protokoll um sicherzustellen, dass alle Transaktionen bis zum Zeitpunkt des Notfalls gesichert werden. Diese "final" Transaktionsprotokollsicherung muss alles nach oben bis zum Zeitpunkt des dem Datenverlust und kann verwendet werden, um die Datenbank wiederhergestellt wird, soweit möglich, möglicherweise minutengenaue zu schalten.

Kurz gesagt, müssen Sie ausarbeiten, was Sie wiederherstellen müssen. Dann wird es eine Frage, was Sie wiederherstellen können.

Was sind Sie, das Wiederherstellen?

Das Ziel einen Wiederherstellungsvorgang ist die wenigsten möglichen Sicherungen wiederherstellen, damit der Wiederherstellungsvorgang so schnell wie möglich ist und innerhalb Ihrer RTO abgeschlossen, ist und auch Sie können Ihren freigegebenen FERTIGUNGSAUFTRAG zu erfüllen.

Die wichtigste Frage hier ist "welche Sicherungen muss ich?" Wenn die einzige Sicherung Ihnen eine vollständige Datenbanksicherung von vor einer Woche erfolgte ist und die gesamte Datenbank unterbrochen wurde, ist es nur eine Wiederherstellungsoption--zu einem bestimmten Zeitpunkt eine Woche vor Datenverlusten alle seit dann. Einfach ausgedrückt, sollten Ihre Sicherungsstrategie immer sicherstellen, dass Sie wiederherstellen, um im Falle eines einem Notfall, benötigen Sie, wie im vorherigen Artikel erwähnt sind.

Wie Sie feststellen können, welche Sicherungen müssen Sie zur Verfügung? Erstens können Sie Abfragen, verschiedene Verlaufstabellen in der Msdb-Datenbank sichern. Diese Tabellen enthalten einen Datensatz aller Sicherungen, die in SQL Server-Instanz, die seit dem letzten genommen wurden die Tabellen mit Sicherungsverläufen gelöscht wurden.

Soweit die Sicherungen selbst betrifft sind, ist es empfehlenswert, benennen die Sicherungsdateien die Datenbank enthalten, geben Sie der Sicherung, Datum und Zeit, so dass die Sicherung auf einen Blick identifiziert werden kann. Wenn Sie dies nicht getan haben, können Sie ermitteln, welche eine Sicherungsdatei enthält, mit dem Befehl RESTORE HEADERONLY. Dies zeigt den Inhalt des Headers für die Sicherungsdatei, im Wesentlichen die Metadaten, die die Sicherung selbst beschreibt. Lesen Sie in der Onlinedokumentation unter dem Thema "Anzeigen von Informationen über Sicherungen".

Mit beiden Methoden an, möchten Sie die Wiederherstellungssequenz zu verwenden, um die beschädigten oder gelöschten Daten wiederherstellen zu arbeiten. Eine Wiederherstellungssequenz ist ein Satz von Sicherungen, die wiederhergestellt werden müssen und der richtigen Reihenfolge, in dem Sie diese wiederherstellen. Die Wiederherstellungssequenz möglicherweise so einfach wie nur eine vollständige Sicherung (einer Datenbank, Dateigruppe oder Datei), oder eine komplizierte Reihe von vollständig, differenzielle und Transaktionsprotokollsicherungen.

Stellen Sie sich beispielsweise vor, ein Szenario, in dem die Sicherungs Strategie der vollständigen Datenbank-, differenziellen Datenbank- und Transaktionsprotokollsicherungen umfasst. Wenn ein Systemabsturz auftritt, und die Datendateien beschädigt sind, was ist die Wiederherstellungssequenz? Abbildung 1 veranschaulicht dieses Beispiel.

In diesem Fall ist die schnellste und einfachste kürzesten Wiederherstellungssequenz der letzten vollständigen Datenbanksicherung (F), der letzten differenziellen Datenbanksicherung (D2) und dann alle nachfolgenden Sicherungen des Transaktionsprotokolls, bis einschliesslich der Wert bei einseitigem Test des Protokoll-Sicherung (L7 und L8).

Eines der schwierige Probleme bei der Planung einer Wiederherstellungssequenz ist die früheste erforderlichen Transaktionsprotokollsicherung wiederherstellen suchen (manchmal auch suchen, die "Minimum-LSN" oder "Minimum-Log Sequence Number" genannt). Im Beispiel im Abbildung 1 sind nur Sicherungen des Transaktionsprotokolls L7 und L8 erforderlich, da die differenzielle Datenbanksicherung D2 die Datenbank bis zu einem neueren in Zeit als die vorherigen Buchung Protokollsicherungen bringt.

Abbildung 1: Beispiel wiederherstellen Sequence

Lässt SQL Server vorherigen, wiederhergestellt werden, Transaktionsprotokollsicherungen nicht benötigte, aber nicht werden verwendet, und wurde im Wesentlichen nur Sondermüll Notfallwiederherstellung time.Continuing mein Beispiel, was geschehen würde, wenn die differenzielle Datenbank, D2 sichern, fehlt oder beschädigt? Abbildung 2 zeigt in diesem Fall.

Abbildung 2: Wiederherstellen der Sequenz mit einer differenziellen Datenbanksicherung von Beschädigungen

In diesem Szenario ist die schnellste und einfachste kürzesten Wiederherstellungssequenz der letzten vollständigen Datenbanksicherung (F), der nächsten letzten differenziellen Datenbanksicherung (D1) und dann alle nachfolgenden Sicherungen des Transaktionsprotokolls (L4, L5, L6, L7 und L8). Dies ist möglich, nur so lange, wie Sicherungen D1, L4, L5 und L6 noch verfügbar sind. Es ist wichtig, dass Sie nicht Sicherungen zu früh löschen; andernfalls Sie Probleme bei einem Notfall treten konnte.

Beispielsweise wenn die vollständigen Datenbanksicherung F beschädigt ist, es sei denn, die vorherige vollständige Sicherung der Datenbank noch verfügbar ist, wird die Datenbank nicht wiederhergestellt werden. Wenn die differenzielle Datenbanksicherung D1 gelöscht wird, sobald D2 abgeschlossen ist, dann das Szenario im Abbildung 2 ist nicht möglich, und die Wiederherstellungssequenz umfasst alle Transaktionsprotokollsicherungen seit der vollständigen Datenbanksicherung--eine potenziell sehr lange Wiederherstellungssequenz.

Dies löst die Frage "Wann sollten Sie löschen die früheren Sicherungen?" Die Antwort ist definitiv "IT abhängt!" Wenn Sie nicht über eine rechtliche Verpflichtung, behalten ihre Sicherungen, um für eine bestimmte Zeitdauer zu verfügen, anschließend müssen Sie und hängt die Sicherungsstrategie, die Sie haben, und wie viel Speicherplatz erforderlich ist. Unabhängig davon, nicht sofort löschen vorherige Sicherungen, sobald eine neue ausgeführt wird; es ist empfehlenswert, mindestens ein oder zwei vollständige Zyklen von Sicherungen vor dem Entfernen Sie älterer Sicherungen abrufen. Im Idealfall sollten Sie Ihre Sicherungen testen, bevor Sie ältere Dateien entfernen.

Für Sicherungen des Transaktionsprotokolls benötigen im Allgemeinen Sie alle seit die letzte vollständigen Datenbanksicherung verfügbar gemacht wurde, da dies die endgültige Herbst Back Wiederherstellungssequenz ist. Wenn eine einzelne Transaktion Sicherung protokollieren aus dem Transaktionsprotokoll Sicherung "Vertrauenskette" fehlt oder ist beschädigt, der Wiederherstellungsvorgang kann nicht hinter die Lücke fortgesetzt. Wie im vorherigen Artikel erwähnt, ist das Überprüfen der Integrität von Sicherungen ein wichtiger Bestandteil erfolgreich wiederherstellen können.

Sie können weitere Details zu herauszufinden, was Sie in der Onlinedokumentation im Thema umfassende wiederherstellen können, suchen "Arbeiten mit Sequenzen wiederherstellen für SQL Server-Datenbanken".

Beispiel-Wiederherstellungsszenarien

Das häufigste Szenario für die Wiederherstellung umfasst eine vollständige Datenbanksicherung und dann eine oder mehrere Transaktionsprotokollsicherungen die Datenbank einen Rollforward rechtzeitig zu schalten. Dazu können Sie über SQL Server Management Studio (SSMS) oder über Transact-SQL zwar etwas müssen Sie der beachten, wenn Sie RESTORE Befehle direkt verwenden.

Wenn eine Sicherung wiederhergestellt wird, es sind drei Optionen verfügbar, für wie der Wiederherstellungsvorgang abgeschlossen ist und Sie alle in Zusammenhang mit der rückgängig-Phase der Wiederherstellung. Wie jede aufeinander folgende Sicherung in die Wiederherstellungssequenz wiederhergestellt wird, wird die REDO-Phase der Wiederherstellung wird immer ausgeführt, aber die rückgängig-Phase kann nicht ausgeführt werden, bis die letzte Sicherung in der Transaktion Protokollsicherungskette wiederhergestellt wurde. Dies liegt daran, dass, sobald die Wiederherstellung abgeschlossen ist, keine weiteren Transaktionsprotokollsicherungen angewendet werden können, damit alle in wiederherstellt muss die Wiederherstellungssequenz nicht zum Ausführen der rückgängig-Phase der Wiederherstellung angeben.

Der Standardwert ist leider die rückgängig-Phase der Wiederherstellung--das Äquivalent mit der Option WITH RECOVERY die RESTORE-Anweisung ausführen. Wenn Sie mehrere Sicherungen wiederherstellen, müssen Sie vorsichtig sein, dass jeweils WITH NORECOVERY angibt. Verwenden Sie die Option WITH NORECOVERY für alle Wiederherstellungen in die Wiederherstellungssequenz, und dann manuell abschließen Wiederherstellung später, in der Tat ist die sicherste Methode. Einige Beispiel-Transact-SQL-Code um eine vollständige Datenbanksicherung und zwei Transaktionsprotokollsicherungen wiederherstellen, und führen Sie dann manuell wiederherstellen, um die Datenbank online zu schalten sieht wie folgt aus:

RESTORE DATABASE DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Full_051709_0000.bak'
MIT ERSETZEN, PRÜFSUMME, NORECOVERY;
START

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0100.bak'
MIT NORECOVERY;
START

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0200.bak'
MIT NORECOVERY;
START

RESTORE DATABASE DBMaint2008 WITH RECOVERY;
START

Beachten Sie, dass ich außerdem verwendet die CHECKSUM-Option für die Wiederherstellung der vollständigen Datenbanksicherung um sicherzustellen, dass alle Seitenprüfsummen vorhanden, in der wiederhergestellten Datenbank überprüft werden, wie Sie wiederhergestellt werden.

Auf die erste Anweisung RESTORE WITH NORECOVERY angegeben wurde, wird der folgende Fehler zurückgegeben:

Msg 3117, Ebene 16, Status 1, Zeile 1
Das Protokoll oder eine differenzielle Sicherung kann nicht wiederhergestellt werden, weil keine Dateien für den Rollforward bereitstehen.
Msg 3013, Ebene 16, Status 1, Zeile 1
RESTORE LOG wird nicht normal beendet.

Achten Sie sehr um die richtige Option zu verwenden, andernfalls besteht die Gefahr einer langen Wiederherstellungssequenz erneut starten zu müssen – besteht keine Möglichkeit, um die Wiederherstellung rückgängig zu machen, sobald er abgeschlossen ist.

Es ist jedoch eine interessante Option Art der hat,--, die Option WITH STANDBY. Dies ist die letzte der drei Optionen bereits erwähnt. Es funktioniert, indem Sie die rückgängig-Phase der Wiederherstellung ausführen, aber es hält eine Notiz von was dies (in einer "Rückgängig"-Datei) der Fall war, deren Namen und Pfad angeben und dann nur-Lese-Zugriff auf die Datenbank ermöglicht. Die Datenbank transaktionell konsistent ist, aber Sie haben die Möglichkeit, um die Wiederherstellungssequenz fortzusetzen. Wenn Sie sich, entscheiden um den Vorgang fortzusetzen, den Schritt Rückgängig rückgängig gemacht (mit dem Inhalt des Rückgängig-Datei) und anschließend die nächste Transaktionsprotokolldatei wird wiederhergestellt. Dies ist in zwei Szenarios hilfreich: Nur-Lese-Zugriff in einer sekundären Datenbank Protokollversand und für den Inhalt der Datenbank betrachten, während die Wiederherstellungssequenz zulässt.

Wenn der Notfall-Wiederherstellung sind das versehentliche Löschen einer Tabelle beinhaltet, beispielsweise können Sie eine Point-in-Time-Wiederherstellung durchführen. Es gibt mehrere Möglichkeiten zur Verfügung, aber am häufigsten ist, in dem Sie die Datenbank wiederherstellen, aber stellen Sie sicher, dass Wiederherstellung nach einem bestimmten Zeitpunkt nicht fortgesetzt möchten. In diesem Fall können Sie die WITH STOPAT-Option, um zu verhindern, dass die Wiederherstellung des Transaktionsprotokolls verhindern, Vergangenheit die Zeit, die Sie, in der Tabelle wissen gelöscht wurde. Beispielsweise können mithilfe das Transact-SQL-Beispiel oben, wenn ich, um zu verhindern, dass die Datenbank, die nach 1: 45: 00 Uhr wiederhergestellt wird wollte, ich konnte verwenden Sie die folgende Syntax auf die zweite RESTORE LOG-Anweisung:

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0200.bak'
MIT NORECOVERY STOPAT = ' 2009 - 05 - 17 01:45:00.000 ';
START

Ich könnte sogar STOPAT und STANDBY finden Sie, ob, der richtige Punkt befand sich rechtzeitig und, ist dies nicht der Fall, Wiederherstellen der gleichen Transaktionsprotokoll-Sicherungskopie mit einem Zeitpunkt ein paar Sekunden später usw. kombinieren. Diese Art von Operation wird sehr mühsam, aber es möglicherweise die einzige Lösung, wenn Sie nicht wissen, welcher Uhrzeit eine Operation durchgeführt wurde.

Eine umfassende Erläuterung diese und weitere Optionen für die RESTORE-Anweisung finden Sie in der Onlinedokumentation unter dem Thema "RESTORE Argumente (Transact-SQL)".

Eines der coolsten neue Features in SQL Server 2005 Enterprise Edition eingeführt wurde partielle Datenbankverfügbarkeit. Dieses Feature ermöglicht eine Multi-Dateigruppe Datenbank online sein und als lange mindestens so verfügbar die primäre Dateigruppe online ist. Natürlich werden Daten in alle offline Dateigruppen können nicht zugegriffen werden, aber dieses Feature ermöglicht eine sehr große Datenbank separaten Dateigruppen für einfacher und schneller Wiederherstellbarkeit aufgeteilt werden soll. Ein weiteres nur Enterprise-Feature, das hinzugefügt wurde, ist die Möglichkeit piecemeal (z. B. eine einzige Dateigruppe aus einer Datenbank Multi-Dateigruppe) wiederherstellen online, während der Rest der Datenbank für die Verarbeitung verwendet wird.

Diese beiden Features kombiniert aktivieren einige Szenarios sehr anspruchsvolle und effiziente Wiederherstellung, solange die Datenbank auf diese Weise konzipiert wurde hat und die richtigen Sicherungen vorhanden sind.

Sie finden eine ausgezeichnete und umfassenden technischer Artikel zu SQL Server mit dem Titel "Microsoft SQL Server 2005 teilweise Datenbank Verfügbarkeit" zusammen mit einigen ausführlichen Beispielen finden Sie unter tinyurl.com/mbpa65. Es gibt auch eine 75-Minuten-Aufzeichnung von Nurhan l. Tripp Übermitteln einer Tech-Ed EMEA-Sitzung mit dem Titel "SQL Server 2005 Very Large Databases, VLDB Dienstverfügbarkeit und Strategien für die Wiederherstellung", lohnt ansehen.

Überlegungen zur an einen anderen Pfad wiederherstellen

Das einfachste Szenario für die Wiederherstellung ist, wenn die Datenbank, auf die gleiche SQL Server-Instanz wiederhergestellt wird, dem in der Regel zugeordnet ist, und klicken Sie mit dem gleichen Namen. Wenn Sie sofort weiter aus diesem Szenario bewegen, wird die Aftermath des Wiederherstellungsvorgangs komplizierter.

Wenn die Datenbank auf dieselbe Instanz, sondern mit einem anderen Namen wiederhergestellt wird, müssen Sie möglicherweise Änderungen an Elementen wie DTS/SSIS-Pakete, Datenbank-Wartungspläne, Zeichenfolgen der Anwendung und alle Elemente, die auf einen Namen für die Datenbank stützt.

Wenn die Datenbank in einer anderen Instanz auf demselben Server wiederhergestellt wird, Sache viel komplizierter:

  • Die SQL Server-Anmeldungen unterschiedlich oder existiert nicht.
  • SQL-Agent-Aufträge und DTS/SSIS-Pakete unterschiedlich oder existiert nicht.
  • Die master-Datenbank ist unterschiedlich, daher keine benutzerdefinierten gespeicherten Prozeduren fehlt möglicherweise.
  • Der Name der SQL Server-Instanz wird unterschiedlich sein, wodurch Client Verbindungsprobleme sein kann.
  • Wenn die Datenbank auf eine Instanz auf einem anderen Server wiederhergestellt wird, alles aufgeführten angewendet wird, aber es möglicherweise hinzugefügt Sicherheitsprobleme wie Windows-Konten abweichen können, und in einer anderen Windows-Domäne sein können.
  • Ein anderer Aspekt ist die Edition von SQL Server auf die Datenbank wiederhergestellt wird. Es gibt einige Features, die in der Datenbank verwendet die Datenbank "Enterprise-only" achten--es kann nicht auf einem Standard Edition wiederhergestellten (oder niedrigeren) SQL Server-Instanz.
  • In SQL Server 2000 und früheren Versionen ist dies kein Problem. In SQL Server 2005, wenn die Tabelle oder Indexpartitionierung verwendet wird, die Datenbank ist "Enterprise-only." In SQL Server 2008 ist die Feature-Liste:
  • Änderungsdatenerfassung
  • Transparente Datenverschlüsselung
  • Datenkomprimierung
  • Partitionieren

Alle diese benötigen Systemadministratorberechtigungen außer der Datenkomprimierung aktivieren der Besitzer einer Tabelle, somit potenziell beschädigen einen Plan zur Wiederherstellung im Zusammenhang mit einer Standard Edition-Instanz wiederherstellen aktiviert werden kann. Sie können feststellen, ob eines dieser Features in der Datenbank unter Verwendung der DMV sys.dm_db_persisted_sku_features verwendet werden, und Ihr Plan zur Wiederherstellung entsprechend anpassen.

Untersuchen tieferer Einblick

Genau wie bei der ersten Artikel dieser Reihe von Sicherungen, gibt es viele Aspekte der Wiederherstellungsoperationen, die ich Speicherplatz zur Deckung mussten. Nun, da Sie die Grundlagen kennen, jedoch können Sie in einige der Onlinedokumentation sowie im Blog Verknüpfungen tiefer Informationen eintauchen. Der beste Ausgangspunkt in der Onlinedokumentation ist das Thema "Wiederherstellung und Wiederherstellung (Übersicht) (SQL Server)". Sie können auch eine Vielzahl von Informationen suchen meinem Blog, beginnend mit der Kategorie sichern/wiederherstellen.

Die wichtigsten Takeaway, die ich Sie aus diesem Artikel gerne, ist erfolgreich eine Datenbank mithilfe von Sicherungen wiederherstellen, für das Übungsbeispiel müssen Sie stellen Sie sicher, dass Sie wissen, was zu tun. Sie möchten die Syntax für den Befehl RESTORE während einer Situation hierfür Notfallwiederherstellung lernen werden. Möglicherweise finden Sie auch, dass Ihre Sicherungsstrategie nicht innerhalb der Unternehmensanforderungen wiederherstellen kann. Vielleicht die Sicherungen zu lange dauert, so dass wiederherstellen, vielleicht Ihre Protokollsicherungen werden versehentlich gegenseitig überschreiben, oder vielleicht vergessen, die zum Aktivieren der transparenten Datenbank Verschlüsselung in SQL Server 2008 verwendet Serverzertifikat sichern.

Bei weitem lässt sich am besten zur Vorbereitung der Notfall um einen Wiederherstellungsplan zu verfügen, der Listet die Schritte durchlaufen, und klicken Sie auf eine Gruppe von Skripts haben, die bestimmen, welche Sicherungen vorhanden sind und die Reihenfolge, in der zur Wiederherstellung helfen. Ich möchte immer sagen, dass dies von der meisten erfahrenen DBA im Team geschrieben und von der am häufigsten stellvertretenden DBA--um sicherzustellen, dass alle Benutzer die Schritte problemlos folgen kann getestet werden sollten. Jedoch, wenn Sie eine unfreiwillige DBAS sind, können Sie ihm müssen Sie selber einen Plan zusammen und stellen Sie sicher, dass Sie es folgen können.

Im nächsten Artikel erkläre ich aus einer Beschädigung der Datenbank wiederherstellen, wenn Sie über Sicherungskopien verfügen, und warum Sie möglicherweise, einen Reparaturvorgang auszuführen, selbst wenn Sie Sicherungen verfügen.
In der Mean Time, und wie immer wenn Sie Feedback oder Fragen haben, legen Sie mir eine Linie ab-- Paul@SQLskills.com.

Dank an Kimberly L. Tripp für die Bereitstellung einer technischen Überprüfung dieses Artikels.

Paul S. Randal ist die Verwaltung von Director der leitende SQLskills.com, eine SQL Server-MVP und Microsoft regionale Leiter. Er gearbeitet, die SQL Server-Datenbankspeichermodul Team bei Microsoft von 1999 auf 2007. Randal schrieb DBCC CHECKDB/Repair für SQL Server 2005 und war verantwortlich für das Kernspeichermodul während der Entwicklung von SQL Server 2008. Randal ist Experte für Notfallwiederherstellung, hohe Verfügbarkeit und Datenbankwartung und ist ein regelmäßiger Referent bei Konferenzen weltweit. He Blogs unter SQLskills.com/blogs/paul und auf Twitter als @ PaulRandal ist.