Wiederherstellen von Microsoft SQL Server-Datenbanken. Wiederherstellung der Datenbank

Eine der Hauptanforderungen an ein DBMS ist die Zuverlässigkeit der Datenspeicherung im externen Speicher. Speicherzuverlässigkeit bezieht sich auf die Tatsache, dass das DBMS in der Lage sein muss, den letzten konsistenten Zustand der Datenbank nach einem Hardware- oder Softwarefehler wiederherzustellen. Üblicherweise werden zwei mögliche Arten von Hardwareausfällen betrachtet: die sogenannten Soft-Ausfälle, die als plötzlicher Stopp des Computers interpretiert werden können (z. B. eine Notabschaltung), und Hard-Ausfälle, die durch den Verlust von Informationen auf Medien gekennzeichnet sind . Externer Speicher. Beispiele für Softwarefehler könnten sein: ein DBMS-Absturz (aufgrund eines Softwarefehlers oder eines Hardwarefehlers) oder ein Benutzerprogrammabsturz, wodurch einige Transaktionen unvollständig bleiben. Die erste Situation kann man sich als eine spezielle Art von Soft-Hardware-Ausfall vorstellen; im letzteren Fall müssen die Folgen nur einer Transaktion beseitigt werden.

In jedem Fall benötigen Sie zum Wiederherstellen der Datenbank einige zusätzliche Informationen. Mit anderen Worten, die Aufrechterhaltung der Zuverlässigkeit der Datenspeicherung in der Datenbank erfordert eine redundante Speicherung von Daten, und der Teil der Daten, der für die Wiederherstellung verwendet wird, muss besonders zuverlässig gespeichert werden. Die gebräuchlichste Methode zum Verwalten solcher redundanter Informationen besteht darin, ein Protokoll der Datenbankänderungen zu führen.

Das Protokoll ist ein spezieller Teil der Datenbank, der DBMS-Benutzern nicht zur Verfügung steht und mit großer Sorgfalt gepflegt wird (manchmal befinden sich zwei Kopien des Protokolls auf verschiedenen physische Festplatten), die Aufzeichnungen über alle Änderungen im Hauptteil der Datenbank erhält. Beim Protokollieren halten sie sich an die Strategie des "vorbeugenden" Schreibens, die darin besteht, dass ein Datensatz einer Änderung eines beliebigen Datenbankobjekts in den externen Speicher des Protokolls gelangen muss, bevor das geänderte Objekt in den externen Speicher des Hauptspeichers gelangt Teil der Datenbank. Es ist bekannt, dass bei korrekter Beachtung dieser Bedingung im DBMS mit Hilfe des Protokolls alle Probleme der Wiederherstellung der Datenbank nach einem Ausfall gelöst werden können.

Während eines leichten Absturzes kann der externe Speicher des Hauptteils der Datenbank Objekte enthalten, die durch Transaktionen geändert wurden, die zum Zeitpunkt des Absturzes noch nicht beendet waren, und es dürfen keine Objekte vorhanden sein, die durch Transaktionen geändert wurden, die zum Zeitpunkt des Absturzes erfolgreich abgeschlossen wurden abstürzen, aber nicht in den externen Speicher geschrieben wurden. Das Ziel des Wiederherstellungsprozesses nach einem Soft Failure ist der Zustand des externen Speichers des Hauptteils der Datenbank, der sich ergeben würde, wenn die Änderungen aller abgeschlossenen Transaktionen in den externen Speicher geschrieben würden und der keine Spuren von Unfertigem enthalten würde Transaktionen. Um dies zu erreichen, werden zunächst nicht abgeschlossene Transaktionen rückgängig gemacht, und dann werden diejenigen Operationen abgeschlossener Transaktionen wiederholt, deren Ergebnisse nicht im externen Speicher angezeigt werden. Um eine Datenbank nach einem harten Ausfall wiederherzustellen, werden ein Protokoll und eine Archivkopie der Datenbank verwendet. Eine Archivkopie ist eine vollständige Kopie der Datenbank, wenn das Protokoll gefüllt ist. Für eine normale Datenbankwiederherstellung nach einem harten Ausfall ist es erforderlich, dass das Protokoll nicht verloren geht. Dann besteht die Wiederherstellung der Datenbank darin, dass das Protokoll auf der Grundlage der Archivkopie die Arbeit aller Transaktionen wiedergibt, die zum Zeitpunkt des Ausfalls beendet wurden.

Obwohl es besondere Anforderungen an die Zuverlässigkeit des Loggings gibt, kann es prinzipiell auch verloren gehen. Dann besteht die einzige Möglichkeit, die Datenbank wiederherzustellen, darin, zur Sicherungskopie zurückzukehren. Natürlich können Sie in diesem Fall nicht den letzten konsistenten Zustand der Datenbank abrufen, aber das ist besser als nichts.

Der einfachste Weg, eine Datenbank zu archivieren, wenn ein Protokoll voll ist. Im Journal wird die sogenannte „gelbe Zone“ eingeführt, bei deren Erreichen die Bildung neuer Transaktionen vorübergehend gesperrt wird. Wenn alle Transaktionen beendet sind und die Datenbank somit einen konsistenten Zustand erreicht hat, können Sie sie archivieren und dann erneut mit dem Füllen des Protokolls beginnen.

Sie können die Datenbank seltener sichern, als das Protokoll voll ist. Wenn das Protokoll voll ist und alle begonnenen Transaktionen beendet sind, können Sie das Protokoll selbst archivieren. Da ein solches archiviertes Protokoll im Wesentlichen nur benötigt wird, um die archivierte Kopie der Datenbank neu zu erstellen, können die Protokollinformationen während der Archivierung erheblich komprimiert werden.

Sie müssen lernen, wie Sie Daten aus einem Backup wiederherstellen. Eine Wiederherstellung kann im Falle eines Hardwarefehlers erforderlich sein oder wenn Sie eine absolut identische Kopie einer vorhandenen Datenbank auf einem anderen Server erstellen müssen.

Denken Sie daran, wenn Sie eine Datenbank mit dem einfachen Wiederherstellungsmodell wiederherstellen, müssen Sie nur die letzte vollständige Sicherung wiederherstellen. Wenn Sie das vollständige oder Massenwiederherstellungsmodell verwenden, müssen Sie die vollständige Sicherung, dann die letzte differenzielle Sicherung und alle Kopien der Transaktionsprotokolle wiederherstellen. Schauen wir uns den Wiederherstellungsprozess genauer an.

Wiederherstellen einer Datenbank aus einer vollständigen Kopie.

Unabhängig vom Wiederherstellungsmodell besteht der erste Schritt immer darin, die neueste vollständige Sicherung wiederherzustellen. Um eine Datenbank in Enterprise Manager wiederherzustellen, markieren Sie die Datenbank und doppelklicken Sie darauf Rechtsklick Maus und auswählen Kontextmenü„Alle Aufgaben > Datenbank wiederherstellen“, dann öffnet sich das in Abbildung A gezeigte Dialogfeld.

Abbildung A.

Im Dialogfeld „Datenbank wiederherstellen“ können Sie alle zuletzt verwendeten anzeigen Sicherungen in chronologischer Reihenfolge. Dort können Sie auch die Datenbank auswählen, die Sie wiederherstellen möchten. Auf der in Abbildung B gezeigten Registerkarte „Optionen“ können Sie die folgenden Optionen auswählen:

Werfen Sie Bänder nach dem Wiederherstellen jeder Sicherung aus
Aufforderung vor dem Wiederherstellen jedes Backups (geben Sie eine zusätzliche Warnung, bevor Sie mit dem Wiederherstellen jedes Backups beginnen)
Wiederherstellung über vorhandene Datenbank erzwingen, diese Option entspricht Move in T-SQL.

Abbildung B.

Im unteren Teil des Fensters befinden sich drei Schalter, mit denen Sie den Zustand der Datenbank nach dem Wiederherstellen der Sicherung bestimmen können:

Lassen Sie die Datenbank betriebsbereit. Es können keine zusätzlichen Transaktionsprotokolle wiederhergestellt werden.
- Wenn Sie diesen Wert auswählen, wird nach dem Laden der Sicherung der Wiederherstellungsprozess initiiert, der alle ausstehenden Transaktionen rückgängig macht. Es ist nicht mehr möglich, zusätzliche Kopien des Transaktionsprotokolls herunterzuladen. Benutzer können normal mit der Datenbank arbeiten.
Lassen Sie die Datenbank außer Betrieb, können aber zusätzliche Transaktionsprotokolle wiederherstellen.
- Nachdem die Kopie heruntergeladen wurde, bleibt die Datenbank vorübergehend nicht verfügbar. Sie müssen zusätzliche Kopien herunterladen und dann den Wiederherstellungsprozess einleiten.
Lassen Sie die Datenbank schreibgeschützt und können zusätzliche Transaktionsprotokolle wiederherstellen.
- Die Datenbank wird schreibgeschützt. Sie können zusätzliche Transaktionsprotokollsicherungen herunterladen. Diese Option dient zum Erstellen eines Standby-Servers (Standby Server)

Das Wiederherstellen der Datenbank und der Transaktionsprotokolle ist so einfach wie das Klicken auf OK.

Wiederherstellen einer Datenbank mit T-SQL.

Die Datenbankwiederherstellung kann auch mit T-SQL erfolgen, das mehr Optionen bietet als Enterprise Manager. Verwendungssyntax T-SQL-Befehle nächste:

DATENBANK WIEDERHERSTELLEN ( Name der Datenbank | @ Datenbankname_var }
[ VON< backup_device > [ , ...n ] ]
[MIT
[EINGESCHRÄNKTER_BENUTZER]
[ [ , ]DATEI = { Dateinummer | @ Dateinummer } ]
[ [ , ]PASSWORT = { Passwort | @ Passwortvariable } ]
[ [ , ]MEDIENNAME = { Medienname | @ media_name_variable } ]
[ [ , ]MEDIENPASSWORT = { Medienpasswort | @ mediapassword_variable } ]
[ [ , ]BEWEGUNG " Logischer_Dateiname" ZU " Betriebssystem_Dateiname" ]
[ , ...n ]
[ [ , ]KEEP_REPLICATION ]
[ [ , ] ( NORWIEDERHERSTELLUNG | WIEDERHERSTELLUNG | STANDBY = Rückgängig_Dateiname } ]
[ [ , ] ( NORDWIND | RÜCKLAUF ) ]
[ [ , ] ( NOUNLADEN | ENTLADEN ) ]
[ [ , ]ERSETZEN]
[ [ , ]NEUSTART]
[ [ , ]STATISTIKEN[ = Prozentsatz ] ]

Eine ausführliche Beschreibung der einzelnen Optionen finden Sie in der Beschreibung in der SQL Server 2000-Onlinedokumentation.

Abbildung C zeigt die Wiederherstellung der Pubs-Datenbank aus einer vollständigen Sicherung von einem Sicherungsgerät.

Abbildung C.

Wiederherstellen einer Datenbank aus einer differenziellen Kopie.

Wenn Sie das vollständige oder Massenwiederherstellungsmodell verwenden, müssen Sie zuerst die vollständige Sicherung wiederherstellen, dann die letzte differenzielle Sicherung und alle Transaktionsprotokolle. Um eine Datenbankwiederherstellung mit einer differenziellen Kopie durchzuführen, wählen Sie im Enterprise Manager die Datenbank aus, doppelklicken Sie darauf mit der rechten Maustaste und wählen Sie im Kontextmenü „Alle Aufgaben > Datenbank wiederherstellen“, wählen Sie Wiederherstellungen der vollständigen und differenziellen Kopien der Datenbank und klicken Sie dann auf OK. (Abbildung D)

Abbildung D

Die Syntax für den Befehl „Wiederherstellen“ zum Durchführen einer Wiederherstellung mithilfe von Differenzkopien ist in Abbildung E dargestellt.

Abbildung E.

Wiederherstellen des Transaktionsprotokolls.

Bevor Sie mit der Wiederherstellung des Transaktionsprotokolls beginnen, müssen Sie die vollständige und neueste differenzielle Kopie der Datenbank wiederherstellen. Anschließend können Sie die Transaktionsprotokolle in der entsprechenden Reihenfolge wiederherstellen. Wenn Sie Enterprise Manager verwenden, müssen Sie die Datenbank auswählen, mit der rechten Maustaste darauf doppelklicken und im Kontextmenü „Alle Aufgaben > Datenbank wiederherstellen“ auswählen, alle erforderlichen Kopien auswählen und ggf. den Punkt in Time Restore-Option (Wiederherstellung zu einem bestimmten Zeitpunkt) (Abbildung F).

Abbildung F.

Die Syntax für den Restore-Befehl zum Wiederherstellen des Transaktionsprotokolls ist in Abbildung G dargestellt.

Abbildung G.

Fassen wir zusammen. Sicherung und Datenbankwiederherstellung ist eine der wichtigsten Aufgaben eines Datenbankadministrators. Sie müssen jederzeit sicher sein, dass Sie die Datenbank wiederherstellen können SQL Server 2000 gemäß Ihrem Notfallwiederherstellungsplan. Wenn Sie keinen Notfallwiederherstellungsplan haben, empfehle ich Ihnen, mit der Arbeit an einem zu beginnen. Für den Fall, dass etwas passiert und die Daten verloren gehen, kann der nächste Verlust für Sie der Verlust Ihres Arbeitsplatzes sein.

Heute im Unterricht: MySQL.(MySQL ist ein kostenloses Datenbankverwaltungssystem). Das Wiederherstellen der Datenbank ist recht einfach, aber dazu benötigen Sie eine Sicherungskopie der Datenbank. Als ich Probleme mit der Datenbank hatte, konnte ich nicht auf die Seite zugreifen und alle meine Artikel verschwanden. Ich musste mich dringend entscheiden, wie ich die Wordpress-Datenbank wiederherstellen sollte.

Diese Situation ist mir vor ein paar Tagen passiert, als ich Lektion 59 geschrieben habe. Nur wenige Minuten später erhielt ich eine SMS von Yandex-Metrica, dass meine Website nicht verfügbar sei. Wenn Sie schon einmal auf ein solches Problem gestoßen sind, wissen Sie, wie Sie alles wieder in einen funktionsfähigen Zustand versetzen können, und wenn nicht, lesen Sie weiter.

So stellen Sie die WordPress-Datenbank wieder her (Methode 1)

Im Internet schreiben sie hauptsächlich, wie man eine Datenbank sichert, aber nur wenige Leute schreiben So stellen Sie die WordPress-Datenbank wieder her . Nicht unbedingt mit Datenbank Probleme können aufgrund Ihrer Schuld auftreten. Auch aus anderen Gründen können Fehler in der Datenbank auftreten.

Wenn Ihr Blog noch kein Plugin oder ähnliches installiert hat, riskieren Sie, ohne Blog zu bleiben. Stellen Sie sich vor, Sie bloggen lange und dann einmal, und das war's! Amba! Dieses Plugin wird das verhindern. Es hält Ihre Blog-Datenbank dauerhaft in automatischer Modus und ohne Ihre Teilnahme.

Es gibt viele Informationen zur Datenbankwiederherstellung im Internet, aber manchmal schreiben sie solchen Unsinn, für den die Leute auch dankbar sind. Der Autor des Artikels gibt Ratschläge, wie man dies und das richtig macht, aber er selbst versteht nicht einmal, worüber er schreibt. Alle zusammen, es ist Zeit, zur Sache zu kommen 🙂

Um den vorherigen Zustand des Blogs wiederherzustellen, benötigen Sie eine neue Datenbanksicherung. Entpacken Sie die Basisdatei und öffnen Sie die entpackte Datei im Windows Notepad. Kopieren Sie den Inhalt der Datei nach . Gehen Sie in PhpMyAdmin zum Control Panel Ihres Hostings.

Klicken Sie auf den Namen der Datenbank, die Sie wiederherstellen möchten.

Dann müssen Sie auf klicken "SQL" und fügen Sie in das Feld ein, was Sie aus der Datenbankdatei kopiert haben, indem Sie auf " STRG " + "v".Drücken Sie dann " OK ".

Warten auf Abschluss der Datenbankwiederherstellung. Es sollte eine Erfolgsmeldung erscheinen.

Jetzt ist Ihr Blog vollständig wiederhergestellt.

So stellen Sie eine WordPress-Datenbank schnell wieder her (Methode 2)

Also ohne weitere Einführungen. Gehen Sie zu Ihrem Hosting-Kontrollfeld (cPanel). Finden Sie den Link " MySQL" oder " PhpMyAdmin ».

Jetzt müssen Sie sich in das Datenbankverwaltungspanel, d. h. PhpMyAdmin, einloggen. Drücken Sie " Betreten»

Sie werden zu PhpMyAdmin weitergeleitet. Klicken Sie links auf die Datenbank, die Sie wiederherstellen möchten. In meinem Fall ist das die dvpress base.

Nachdem Sie eine Datenbank ausgewählt haben, werden alle Tabellen in dieser Datenbank angezeigt. Damit bei der Wiederherstellung keine Fehler auftreten, muss diese Datenbank vollständig gelöscht werden. Wir gehen nach unten und finden Alles auswählen Auswahl aufheben ". Klicke auf " Wählen Sie Alle “, sodass alle Datenbanktabellen Checkboxen haben. Wählen Sie im Feld rechts aus Löschen", und dann bestätigen " ja". Die Datenbank sollte vollständig von allen Tabellen gelöscht werden.

Ihre Aufgabe ist es nun, diese Datenbank aus einem Backup wiederherzustellen. Klicken Sie oben " Importieren", dann klicken Sie auf die Schaltfläche" Wählen Sie eine Datei aus ". Suchen Sie ein Datenbank-Backup auf Ihrem Computer und klicken Sie auf " Offen". Klicken Sie nun in PhpMyAdmin ganz unten auf „ OK". Die Operation muss erfolgreich sein, was durch die Aufschrift „ SQL-Abfrage erfolgreich beendet ».

Was ich letzte Woche gepostet habe, schien ein gewisses Interesse zu wecken, aber leider enthielt es keine „Übung“. Ja, es sagt, wie Sie Daten speichern können, aber es gibt keine Beispiele.
Ursprünglich wollte ich eine weitere Übersetzung desselben Autors machen, aber nachdem ich nachgedacht hatte, entschied ich mich, einen Beitrag „selbst“ zu schreiben, als ob „basierend auf“. Die Gründe, die mich dazu bewogen haben, beschreibe ich am Ende des Beitrags, in den Anmerkungen.

Wiederherstellen von Datenbanken in SQL Server

Wie im vorherigen Artikel erwähnt, gehen die auf diesen Seiten enthaltenen Daten verloren, wenn Clustered-Index- oder Heap-Seiten beschädigt sind, und die einzige Möglichkeit, sie wiederherzustellen, besteht darin, die Datenbank direkt wiederherzustellen.

SQL Server bietet viele Optionen zum Wiederherstellen von Datenbanken. Erstens ist dies die Wiederherstellung der gesamten Datenbank - es kann ziemlich viel Zeit in Anspruch nehmen (abhängig von der Größe der Datenbank und der Geschwindigkeit Festplatte). Zweitens das Wiederherstellen einzelner Dateigruppen oder Dateien, wenn Ihre Datenbank aus mehreren Dateigruppen (bzw. Dateien) besteht. In diesem Fall ist es möglich, nur beschädigte Teile der Datenbank wiederherzustellen, ohne den Rest zu beeinträchtigen. Diese beiden Arten der Datenbankwiederherstellung werden häufig verwendet und werden nicht weiter erläutert.
Drittens wurde mit SQL Server 2005 die Möglichkeit eingeführt, einzelne Datenbankseiten wiederherzustellen – in diesem Fall werden nur die angegebenen Seiten aus der Sicherung wiederhergestellt. Eine solche Wiederherstellung ist besonders relevant, wenn DBCC CHECKDB mehrere beschädigte Seiten in einer riesigen Tabelle findet, die in einer dicken Datei „liegen“. Dadurch, dass nicht die gesamte Datei und nicht einmal die gesamte Tabelle, sondern nur wenige Seiten wiederhergestellt werden, kann die Ausfallzeit deutlich reduziert werden.

Anforderungen und Einschränkungen

Wiederherstellungsmodell und Verfügbarkeit von Transaktionsprotokollsicherungen

Das Wichtigste, an das Sie sich erinnern sollten, ist, dass die Datenbank zum Wiederherstellen einzelner Seiten das vollständige (vollständige) Wiederherstellungsmodell oder das massenprotokollierte Wiederherstellungsmodell verwenden muss. Wenn sich Ihre Datenbanken in einem einfachen (einfachen) Wiederherstellungsmodell befinden, lesen Sie möglicherweise nicht weiter.
Die zweite Anforderung ist, dass Ihre vollständigen und Transaktionsprotokollsicherungen eine ununterbrechbare Protokollkette bilden müssen. Wenn Sie den Befehl BACKUP LOG WITH TRUNCATE_ONLY (NO_LOG) nie ausführen und zu wechseln einfaches Modell wiederherstellen, um das Transaktionsprotokoll zu reduzieren, und Sie haben ALLE Transaktionsprotokollsicherungen seit der letzten vollständigen Sicherung ohne beschädigte Seiten (einschließlich dieser vollständigsten Sicherung) - Sie müssen sich keine Sorgen um die Protokollkette machen.
Beim massenprotokollierten Wiederherstellungsmodell sollte die Wiederherstellung einzelner Seiten theoretisch gut funktionieren, wenn die oben beschriebenen Bedingungen erfüllt sind und die wiederherzustellenden Seiten nicht durch minimal protokollierte Vorgänge geändert wurden.

Editionen von SQL Server

Die Seitenwiederherstellung ist in jeder Edition von SQL Server möglich, aber für Enterprise Edition und Developer Edition ist es möglich, beschädigte Seiten online wiederherzustellen, d. h. auf die Datenbank kann während der Wiederherstellung zugegriffen werden (und außerdem kann auf die Tabelle zugegriffen werden, zu der die gerade wiederhergestellten Seiten gehören, wenn diese Seiten selbst nicht „betroffen“ sind – sonst schlägt die Anfrage fehl). Bei Editionen „unterhalb“ der Enterprise Edition findet die Seitenwiederherstellung offline statt und die Datenbank ist während des Wiederherstellungszeitraums nicht verfügbar.

Beschädigter Seitentyp

Sollten Indexseiten oder Daten beschädigt werden, ist deren Wiederherstellung in der Enterprise Edition online möglich.
Seiten, die zu kritischen Systemtabellen gehören, können wiederhergestellt werden, aber auf die Datenbank kann nach der Wiederherstellung in keiner Edition von SQL Server zugegriffen werden.
„Location Cards“ können nicht „einzeln“ wiederhergestellt werden. Wenn GAM-, SGAM-, PFS-, ML-, DIFF-Seiten beschädigt sind, müssen Sie die gesamte Datenbank wiederherstellen. Die einzige Ausnahme sind IAM-Seiten. Obwohl sie sich auf "Platzierungskarten" beziehen, beschreiben sie nur eine Tabelle, nicht die gesamte Datenbank, und es ist möglich, sie wiederherzustellen.
Die Datenbank-Startseite (Seite 9 in der 1. Datenbankdatei) und die Dateikopfseite (Seite 0 in jeder Datei) können nicht „separat“ wiederhergestellt werden, wenn sie beschädigt sind, muss die gesamte Datenbank wiederhergestellt werden.

Eigentlich Genesung

Jetzt endlich bewegen wir uns von der Theorie in die Praxis.
Zunächst einmal benötigen Sie für das Training eine beschädigte Datenbank.

Portierung der Datenbank

Zum Experimentieren verwende ich die mit SQL Server gelieferte AdventureWorks-Datenbank. Wenn Sie es nicht installiert haben, können Sie die . Ich übersetze es in ein vollständiges Wiederherstellungsmodell:
ALTER DATABASE AdventureWorks SET RECOVERY FULL stellen Sie sicher, dass noch keine Fehler vorhanden sind:
DBCC CHECKDB("AdventureWorks") WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY und erstellen Sie eine vollständige Sicherung:
BACKUP DATABASE AdventureWorks TO DISK = "D:\tmp\aw_backups\aw_full_ok1.bak"

In dieser Datenbank erstelle ich eine Crash-Tabelle.
CREATE TABLE crash (txt varchar(1000)) Wir werden das Feld varchar type verfälschen, um zu prüfen, was passiert, wenn SQL Server plötzlich darin nicht die Daten findet, die er selbst dort geschrieben hat.
Bevor Sie etwas verderben, müssen Sie es mit etwas füllen. Ich hämmere in die erstellte Tabelle die linken Daten ein.
SETZE NOCOUNT ON DECLARE @i INT SETZE @i = 1 WÄHREND @i<100000 BEGIN INSERT INTO crash SELECT REPLICATE("a", 1000) SET @i = @i + 1 END SET NOCOUNT OFF Теперь делаю резервную копию журнала транзакций:
BACKUP LOG AdventureWorks TO DISK = "D:\tmp\aw_backups\aw_log_ok1.trn"

Jetzt ändern wir die Daten ein wenig:

Also, alles ist bereit. Trennen Sie die Datenbank und öffnen Sie die mdf-Datei mit FAR "om (oder was auch immer für Sie bequemer ist), suchen Sie darin nach der Zeichenfolge "zzzzzzz" und ersetzen Sie mehrere "z" durch beliebige Zeichen:

Jetzt, da die Datenbank beschädigt ist, verbinden wir sie. Und ja, ich erinnere mich, dass im vorherigen Artikel klar gesagt wurde, dass Sie die Datenbank nicht trennen / anhängen sollten. Aber in unserem Fall ist es absolut "sicher" - die Datenbank in "verdächtig" wird nicht fallen.

Suche nach Fehlern

Die beschädigte Datenbank wurde also erfolgreich wieder in Betrieb genommen. Lassen Sie uns die Integritätsprüfung erneut ausführen:
DBCC CHECKDB("AdventureWorks") WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY Das Ergebnis entspricht unseren Erwartungen ( Merken Sie sich unbedingt die Nummern der beschädigten Seiten!):

Nachricht 8928, Ebene 16, Status 1, Zeile 1
Objekt-ID 1883153754, Index-ID 0, Partitions-ID 72057594054246400, Zuordnungseinheits-ID 72057594061651968 (Typ Zeilendaten): Seite (1:20455) konnte nicht verarbeitet werden. Siehe andere Fehler für Details.
Nachricht 8939, Ebene 16, Status 98, Zeile 1
Tabellenfehler: Objekt-ID 1883153754, Index-ID 0, Partitions-ID 72057594054246400, Zuordnungseinheits-ID 72057594061651968 (Typ Zeilendaten), Seite (1:20455). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) fehlgeschlagen. Werte sind 29493257 und -4.
CHECKDB hat 0 Zuordnungsfehler und 2 Konsistenzfehler in Tabelle "crash" (Objekt-ID 1883153754) gefunden.
CHECKDB hat 0 Zuordnungsfehler und 2 Konsistenzfehler in der Datenbank "AdventureWorks" gefunden.
repair_allow_data_loss ist die minimale Reparaturstufe für die von DBCC CHECKDB (AdventureWorks) gefundenen Fehler.
v dieser Fall Die Daten auf dem Heap selbst sind beschädigt (Index-ID = 0), sodass SQL Server diese Daten nicht wiederherstellen kann.
Wir haben jetzt drei Möglichkeiten:

Datenverlust akzeptieren und DBCC CHECKDB("AdventureWorks", REPAIR_ALLOW_DATA_LOSS) ausführen
Erstellen Sie eine Sicherungskopie des aktiven Teils des Transaktionsprotokolls und stellen Sie die gesamte Datenbank wieder her - es tritt dadurch kein Datenverlust auf, aber es dauert lange
Erstellen Sie eine Sicherungskopie des aktiven Teils des Transaktionsprotokolls und stellen Sie nur eine (!) beschädigte Seite wieder her

Mit der zweiten Option sollte alles klar sein, aber was passiert, wenn Sie DBCC CHECKDB ausführen oder wie einzelne Seiten wiederhergestellt werden - ich werde weiter zeigen.

Wiederherstellen einer beschädigten Seite

Zunächst müssen wir ein Backup des letzten Fragments des Transaktionsprotokolls erstellen (Tail-Backup). Wenn Sie die Enterprise Edition haben, können Sie gleichzeitig den Parameter NORECOVERY nicht hinzufügen, der die Datenbank in den Status "Wiederherstellen" versetzt, da diese Edition die Online-Seitenwiederherstellung unterstützt. Wenn Sie außerdem regelmäßig Transaktionsprotokollsicherungen durchführen lassen, können Sie in der Enterprise Edition eine COPY_ONLY-Sicherung erstellen, um die Protokollkette nicht zu unterbrechen.
Ich folge dem Pfad der Offline-Wiederherstellung und führe Folgendes aus:
BACKUP LOG AdventureWorks TO DISK = "D:\tmp\aw_backups\aw_log_fail3.trn" MIT NORECOVERY

Jetzt können Sie die beschädigte Seite reparieren. Zunächst verwenden wir ein vollständiges Backup (aw_full_ok1.bak):

WIEDERHERSTELLEN DER DATENBANK AdventureWorks PAGE = "1:20455" FROM DISK = "D:\tmp\aw_backups\aw_full_ok1.bak" MIT NORECOVERY
Als Ergebnis haben wir:

Bitte beachten Sie, dass Sie die NORECOVERY-Option verwenden müssen, da wir die Transaktionsprotokoll-Backups noch darauf rollen müssen.
RESTORE LOG AdventureWorks FROM DISK = "D:\tmp\aw_backups\aw_log_ok1.trn" MIT NORECOVERY und
WIEDERHERSTELLEN DES PROTOKOLLS AdventureWorks FROM DISK = "D:\tmp\aw_backups\aw_log_fail3.trn" MIT WIEDERHERSTELLUNG

Es scheint, dass alles gut gelaufen ist, wir führen DBCC CHECKDB aus und ...

Die Wiederherstellung war erfolgreich.
Bitte beachten Sie, dass die Ausfallzeit dadurch reduziert wird, dass wir nicht die gesamte Datenbank aus einem vollständigen Backup wiederherstellen, sondern nur beschädigte Seiten (wenn ich das gesamte Backup wiederherstellen würde, wäre das Backup in 8,5 Sekunden wiederhergestellt, aber dann größere Größe DB - desto größer wird der Zeitunterschied sein). Die Glücklichen mit SQL Server Enterprise Edition, die die Online-Wiederherstellung verwenden, sparen auch Zeit bei der Wiederherstellung aus Protokollsicherungen, und bei der Offline-Wiederherstellung werden die Protokolle leider vollständig verarbeitet.
Es ist auch erwähnenswert, dass in SQL Server 2005, 2008, 2008 R2 die Wiederherstellung einer einzelnen Seite nur mit Hilfe von T-SQL möglich ist, Denali die Möglichkeit hat, dies über die GUI zu tun.

Und wenn alle gleich DBCC CHECKDB?

Für alle Fälle entschied ich mich zu prüfen, was SQL Server tun würde, wenn ich DBCC CHECKDB mit der Option REPAIR_ALLOW_DATA_LOSS ausführen würde. Immer noch der gleiche Fehler:

Zuerst versetzen wir die Datenbank in den SINGLE_USER-Modus:
ALTER DATABASE AdventureWorks SET SINGLE_USER Und dann starten Sie die Wiederherstellung:
DBCC CHECKDB("AdventureWorks", REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY Ergebnis:
Reparatur: Die Seite (1:20455) wurde von Objekt-ID 1883153754, Index-ID 0, Partitions-ID 72057594054246400, Zuordnungseinheit-ID 72057594061651968 (Typ In-Row-Daten) aufgehoben.
Ja, SQL Server hat die "beschädigte" Seite gelöscht. Wir überführen die Datenbank in den MULTI_USER-Modus, damit sie für alle verfügbar wird, und prüfen, was fehlt:

Da die Seitengröße im SQL Server 8KB beträgt und etwas weniger für Benutzerdaten zur Verfügung steht, dann ist alles natürlich, die Tabelle hat um 7 Datensätze „abgenommen“ (am Anfang waren es 99999). Da es für diese Tabelle keinen Clustered-Index gab, konnten die Daten in beliebiger Reihenfolge gespeichert werden, d.h. wir konnten nicht einmal wissen, welche Daten verloren gehen würden.

Warum also keine Übersetzung?

Also, warum ist es immer noch keine Übersetzung, sondern ein Beitrag "basierend auf". Tatsache ist, dass es in der Public Domain keinen Artikel „Page Restore“ von Gail Shaw gibt. Es gibt einen solchen Abschnitt im Buch SQL Server MVP Deep Dives vol.2, das für ziemlich viel Geld verkauft wird (aber natürlich leicht im Internet zu finden ist) und ich bin mir nicht sicher, ob es eine Übersetzung gibt ähm ... richtig oder so.
Im Allgemeinen habe ich den Artikel gelesen, die wichtigsten Punkte notiert und dann den Text selbst geschrieben und nebenbei ein Experiment zur Restaurierung durchgeführt. Ich hoffe, diese Erfahrung war für jemanden hilfreich.
Und, meine Herren, ich hoffe aufrichtig, dass Sie äußerst vorsichtig sein werden, wenn Sie sich entscheiden, dieses Experiment zu wiederholen (Sie werden beispielsweise nicht mit der Hauptdatenbank auf einem Produktionsserver experimentieren). Bitte denken Sie daran, dass ich nicht für Ihre Handlungen verantwortlich bin.

Wiederherstellen von Datenbanken in SQL Server

Wie im vorherigen Artikel erwähnt, gehen die auf diesen Seiten enthaltenen Daten verloren, wenn Clustered-Index- oder Heap-Seiten beschädigt sind, und die einzige Möglichkeit, sie wiederherzustellen, besteht darin, die Datenbank direkt wiederherzustellen.

SQL Server bietet viele Optionen zum Wiederherstellen von Datenbanken. Erstens ist dies die Wiederherstellung der gesamten Datenbank - dies kann ziemlich lange dauern (abhängig von der Größe der Datenbank und der Geschwindigkeit der Festplatten). Zweitens das Wiederherstellen einzelner Dateigruppen oder Dateien, wenn Ihre Datenbank aus mehreren Dateigruppen (bzw. Dateien) besteht. In diesem Fall ist es möglich, nur beschädigte Teile der Datenbank wiederherzustellen, ohne den Rest zu beeinträchtigen. Diese beiden Arten der Datenbankwiederherstellung werden häufig verwendet und werden nicht weiter erläutert.
Drittens wurde mit SQL Server 2005 die Möglichkeit eingeführt, einzelne Datenbankseiten wiederherzustellen – in diesem Fall werden nur die angegebenen Seiten aus der Sicherung wiederhergestellt. Eine solche Wiederherstellung ist besonders relevant, wenn DBCC CHECKDB mehrere beschädigte Seiten in einer riesigen Tabelle findet, die in einer dicken Datei „liegen“. Dadurch, dass nicht die gesamte Datei und nicht einmal die gesamte Tabelle, sondern nur wenige Seiten wiederhergestellt werden, kann die Ausfallzeit deutlich reduziert werden.

Anforderungen und Einschränkungen

Wiederherstellungsmodell und Verfügbarkeit von Transaktionsprotokollsicherungen

Das Wichtigste, an das Sie sich erinnern sollten, ist, dass die Datenbank zum Wiederherstellen einzelner Seiten das vollständige (vollständige) Wiederherstellungsmodell oder das massenprotokollierte Wiederherstellungsmodell verwenden muss. Wenn sich Ihre Datenbanken in einem einfachen (einfachen) Wiederherstellungsmodell befinden, lesen Sie möglicherweise nicht weiter.
Die zweite Anforderung ist, dass Ihre vollständigen und Transaktionsprotokollsicherungen eine ununterbrechbare Protokollkette bilden müssen. Wenn Sie den Befehl BACKUP LOG WITH TRUNCATE_ONLY (NO_LOG) nie ausführen und zu einem einfachen Wiederherstellungsmodell wechseln, um das Transaktionsprotokoll zu verkleinern, und Sie ALLE Transaktionsprotokollsicherungen seit der letzten vollständigen Sicherung ohne beschädigte Seiten haben (einschließlich dieser vollständigsten Sicherung ) - Sie müssen sich keine Gedanken über die Protokollkette machen.
Beim massenprotokollierten Wiederherstellungsmodell sollte die Wiederherstellung einzelner Seiten theoretisch gut funktionieren, wenn die oben beschriebenen Bedingungen erfüllt sind und die wiederherzustellenden Seiten nicht durch minimal protokollierte Vorgänge geändert wurden.

Editionen von SQL Server

Beschädigter Seitentyp

Eigentlich Genesung

Jetzt endlich bewegen wir uns von der Theorie in die Praxis.
Zunächst einmal benötigen Sie für das Training eine beschädigte Datenbank.

Portierung der Datenbank

Suche nach Fehlern

Nachricht 8928, Ebene 16, Status 1, Zeile 1
Objekt-ID 1883153754, Index-ID 0, Partitions-ID 72057594054246400, Zuordnungseinheits-ID 72057594061651968 (Typ Zeilendaten): Seite (1:20455) konnte nicht verarbeitet werden. Siehe andere Fehler für Details.
Nachricht 8939, Ebene 16, Status 98, Zeile 1
Tabellenfehler: Objekt-ID 1883153754, Index-ID 0, Partitions-ID 72057594054246400, Zuordnungseinheits-ID 72057594061651968 (Typ Zeilendaten), Seite (1:20455). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) fehlgeschlagen. Werte sind 29493257 und -4.
CHECKDB hat 0 Zuordnungsfehler und 2 Konsistenzfehler in Tabelle "crash" (Objekt-ID 1883153754) gefunden.
CHECKDB hat 0 Zuordnungsfehler und 2 Konsistenzfehler in der Datenbank "AdventureWorks" gefunden.
repair_allow_data_loss ist die minimale Reparaturstufe für die von DBCC CHECKDB (AdventureWorks) gefundenen Fehler.
In diesem Fall sind die Daten auf dem Heap selbst beschädigt (Index-ID = 0), sodass SQL Server diese Daten nicht wiederherstellen kann.
Wir haben jetzt drei Möglichkeiten:

Datenverlust akzeptieren und DBCC CHECKDB("AdventureWorks", REPAIR_ALLOW_DATA_LOSS) ausführen
Erstellen Sie eine Sicherungskopie des aktiven Teils des Transaktionsprotokolls und stellen Sie die gesamte Datenbank wieder her - es tritt dadurch kein Datenverlust auf, aber es dauert lange
Erstellen Sie eine Sicherungskopie des aktiven Teils des Transaktionsprotokolls und stellen Sie nur eine (!) beschädigte Seite wieder her

Mit der zweiten Option sollte alles klar sein, aber was passiert, wenn Sie DBCC CHECKDB ausführen oder wie einzelne Seiten wiederhergestellt werden - ich werde weiter zeigen.

Wiederherstellen einer beschädigten Seite

Jetzt können Sie die beschädigte Seite reparieren. Zunächst verwenden wir ein vollständiges Backup (aw_full_ok1.bak):

WIEDERHERSTELLEN DER DATENBANK AdventureWorks PAGE = "1:20455" FROM DISK = "D:\tmp\aw_backups\aw_full_ok1.bak" MIT NORECOVERY
Als Ergebnis haben wir:

Bitte beachten Sie, dass Sie die NORECOVERY-Option verwenden müssen, da wir die Transaktionsprotokoll-Backups noch darauf rollen müssen.
RESTORE LOG AdventureWorks FROM DISK = "D:\tmp\aw_backups\aw_log_ok1.trn" MIT NORECOVERY und
WIEDERHERSTELLEN DES PROTOKOLLS AdventureWorks FROM DISK = "D:\tmp\aw_backups\aw_log_fail3.trn" MIT WIEDERHERSTELLUNG

Es scheint, dass alles gut gelaufen ist, wir führen DBCC CHECKDB aus und ...

Die Wiederherstellung war erfolgreich.
Bitte beachten Sie, dass die Ausfallzeit dadurch reduziert wird, dass wir nicht die gesamte Datenbank aus einer vollständigen Sicherung wiederherstellen, sondern nur beschädigte Seiten (wenn ich die gesamte Sicherung wiederherstellen würde, wäre die Sicherung in 8,5 Sekunden wiederhergestellt, aber je größer die Datenbankgröße , desto mehr Zeitunterschied wird es geben). Die Glücklichen mit SQL Server Enterprise Edition, die die Online-Wiederherstellung verwenden, sparen auch Zeit bei der Wiederherstellung aus Protokollsicherungen, und bei der Offline-Wiederherstellung werden die Protokolle leider vollständig verarbeitet.
Es ist auch erwähnenswert, dass in SQL Server 2005, 2008, 2008 R2 die Wiederherstellung einer einzelnen Seite nur mit Hilfe von T-SQL möglich ist, Denali die Möglichkeit hat, dies über die GUI zu tun.

Und wenn alle gleich DBCC CHECKDB?

Für alle Fälle entschied ich mich zu prüfen, was SQL Server tun würde, wenn ich DBCC CHECKDB mit der Option REPAIR_ALLOW_DATA_LOSS ausführen würde. Immer noch der gleiche Fehler:

Warum also keine Übersetzung?

Siegel

Auch interessant:

Was ist online und offline im Internet

Wie Sie zu Hause Geld verdienen, indem Sie Ihre eigenen und die Waren anderer Leute verkaufen

Was ist online und offline

Wir empfehlen Lektüre:

2022-01-25 06:47:56

Was können Sie mit PayPal kaufen?

2022-01-25 06:47:56

Wie lösche ich eine WebMoney-Brieftasche?

2022-01-25 06:47:56

Wie viel verdient man mit bitcoins

Fortsetzung des Themas:

Android

So fügen Sie der Yandex-Startseite ein Widget hinzu und passen das Design an

Widgets auf dem Windows 7- oder 10-Desktop bieten Benutzern eine Vielzahl von Optionen, mit denen Sie Ihren Arbeitsbereich rational anpassen können. Grundsätzlich ist das System...