SQLServer

Grundlegendes zu SQL Server-Sicherungen

Paul S. Randal

Auf einen Blick:

• Vollständige Sicherungen
• Sicherungen des Transaktionsprotokolls
• Differenzielle Sicherungen
• Planung der Sicherungsstrategie und Integrität von Sicherungen

Inhalt

Vollständige Sicherungen
Differenzielle Sicherungen
Transaktionsprotokollsicherungen
Sicherungs Strategie planen
Sicherung Integrität
Zusammenfassung

Tatsächlich müssen Sie SQL Server-Sicherungen dauern?ja.Sofern Sie nicht Ihre Daten interessiert oder nicht Sie mind, Ihre Datenbank ein Notfall vollständig neu erstellen müssen, benötigen Sie einige Möglichkeit der Wiederherstellung der Datenbank zu einem verwendbar.Argumentieren einige Personen, dass mit eine redundante Kopie der Datenbank an anderer Stelle erübrigt sich die Notwendigkeit für Sicherungen müssen, aber beschädigt oder nicht zugreifbar, was geschieht, wenn kopieren ist?Sicherungen sind weiterhin erforderlich, um sicherzustellen, dass Sie immer wiederherstellen können.

Aber welche Sicherungen sollten Sie ergreifen?Wie oft sollten Sie Sie ausführen?Welche Auswirkungen haben Sie auf die Datenbank und die Arbeitsauslastung?Und wie Vergewissern Sie sich diese gültig sind?

Zusammenstellen einer Sicherungsstrategie ist tatsächlich einfacher, als Sie denken möglicherweise, obwohl die Backup- und RESTORE-Befehle eine Fülle von Optionen haben.Und wird Ihnen bei es alle out Abbildung helfen.

Dies ist der erste Artikel einer dreiteiligen Reihe.In Teil 1 behandelt ich hier Sicherungen.In Teil 2 (September 2009 Abgang) werde ich erläutern eines Notfalls mit Sicherungen wiederherstellen.Und in Teil 3 (November 2009 Abgang), betrachten ich werde einem Notfall ohne Sicherungen wiederherstellen.Werde ich etwas tiefer als gewohnt in diesen Artikeln wechseln sollten, aber Sie damit zusammen mit Hilfe der Hintergrundinformationen folgen Sie.

In Artikel dieses Monats wird erläutert, die Grundlagen der Verwendung der verschiedenen Typen von Sicherung arbeiten und wie sollten Sie diese in einer Sicherungsstrategie verwenden.Es hilft, wenn Sie über Kenntnisse der Funktionsweise des Transaktionsprotokolls (Siehe meinen Artikel"Grundlegendes zur Protokollierung und Wiederherstellung in SQLServer." Es ist sinnlos Sicherungen müssen, wenn diese beschädigt werden, wenn Sie versuchen, diese zu verwenden, damit ich auch erläutern, werden das Hinzufügen einiger Integrität überprüft aus aktivieren.Entlang der werde ich einige häufige Missverständnisse debunk und Links zu weiteren Informationen.

Was ich nicht dazu werde ist erläutern Funktionsweise die Syntax der BACKUP und wie die verschiedenen Sicherungsarten durchführen.Hat SQL Server-Onlinedokumentation hervorragende Abschnitte, die diese also warum hier duplizieren Platz verschwenden?Finden Sie unter dem Thema"Sicherung (Transact-SQL)"für Weitere Informationen, insbesondere die Beispiele Abschnitt am Ende.Das Thema"Sichern und Wiederherstellen von Gewusst-wie-Themen (SQL Server Management Studio)"erläutert, wie die Tools zum Durchführen von Sicherungen verwenden.Es empfiehlt sich die Vorgehensweise nach dem Lesen dieses Artikels überprüfen, wie hier ich das was und warum erläutern werde.

Die Implementierung der Sicherungsstrategie ist relativ einfach Teil.Entwerfen eine effektive Strategie ist die sehr wichtig, obwohl häufig übersehen, Teil.

Vollständige Sicherungen

Die einfachste Art der Sicherung ist eine vollständige Datenbanksicherung.Es ist auch eine vollständige Sicherung einer einzelnen Datendatei oder Dateigruppe möglich.Jedoch werden diese nicht häufig verwendet, und wie alle beschriebenen Prinzipien angewendet, auch ich werde den Fokus auf Datenbankebene Sicherungen.Aber als von SQL Server 2005 arbeiten jeder präzisere Sicherungsarten genau (Dies galt nicht in SQL Server 2000).Dasselbe gilt für differenzielle Sicherungen – auf Datei, Dateigruppe oder Datenbankebene ausgeführt werden können, aber diese gesamte Arbeit in der gleichen Weise, sowie, unabhängig von der Komponente gesichert.

Eine vollständige Datenbanksicherung enthält eine vollständige Kopie der Datenbank und bietet einen einzelnen Punkt Just-in-Time, die Datenbank wiederhergestellt werden kann.Obwohl es viele Stunden für den Sicherungsvorgang ausführen dauern kann, Sie können weiterhin nur wiederherstellen die Sicherung auf einen einzelnen Punkt (effektiv am Ende der Sicherung, aber erörtert genau, dass Punkt weiter unten in diesem Artikel ist).Eine vollständige Sicherung lässt Wiederherstellung bis zu einem beliebigen Zeitpunkt nicht rechtzeitig während die Sicherung ausgeführt wurde.Dies ist auch für differenzielle Sicherungen identisch.

Es ist ein verbreitetes Missverständnis dazu, jedoch durch die Tatsache, dass Sie die WITH STOPAT verwenden können, fuelled < eine sequenznummer zeit oder protokolldateien > = auf eine Wiederherstellung von vollständigen und differenziellen Sicherungen die Option.Obwohl die Syntax für die es zulässt, wird die Option hat keine Auswirkungen und gibt es nur zur Vereinfachung ist.

Ein weiteres verbreitetes Missverständnis über vollständige Sicherungen ist, dass Sie nur Daten enthalten.Vollständige Sicherungen und differenzielle Sicherungen enthalten auch einige Transaktionsprotokoll-Datensätze, so dass die wiederhergestellte Komponente (Datenbank, Datei oder Dateigruppe) transaktionell konsistent gemacht werden kann.

Erwägen Sie eine Beispiel-Transaktion, die einen Datensatz in einer Tabelle mit einem einzelnen nicht gruppierten Index einfügt.Die Seiten der Tabellen- und Indexdaten werden durch die Datendatei verteilt.Die Transaktion ist intern in zwei Teile unterteilt: ein Datensatz einfügen in einer Datenzugriffsseite in der Tabelle, die Einfügung der erforderliche Datensatz in eine Indexseite in den nicht gruppierten Index.Wenn der Sicherungsvorgang nur Auswirkungen auf die Seite nicht gruppierten Index vor der Einfügemarke Datensatz gelesen, aber die Datenseite Tabelle nach dem Datensatz einfügen liest, ist die Datenbank nur die Daten in der Sicherung vom Transaktionsmodus inkonsistent.

Hier kommt das Transaktionsprotokoll ins Spiel.Von auch einschließlich einige Datensätze im Transaktionsprotokoll der Sicherung kann Wiederherstellung der wiederhergestellte Kopie der Datenbank, wodurch es transaktionell konsistent ausgeführt werden.Für diese Transaktion wird abhängig von der Sie ein Commit, der Wiederherstellung Teil der Wiederherstellung möglicherweise Rollforward es (d. h. es wird angezeigt, wie Commit in der wiederhergestellte Kopie der Datenbank) oder setzen ihn zurück (d. h. es überhaupt nicht in die wiederhergestellte Kopie der Datenbank angezeigt wird).In beiden Fällen wird die Transaktionskonsistenz, ist entscheidend verwaltet.

Eine vollständige Sicherung geschieht Folgendes:

1. Erzwingen Sie eine Datenbank Prüfpunkt und notieren Sie der Protokoll-Sequenznummer an diesem Punkt.Diese Leert alle aktualisiert-in-Memory-Seiten auf der Festplatte bevor nichts, von der Sicherung gelesen wird um den Umfang der Arbeit zu minimieren, die hat der Wiederherstellung Teil der Wiederherstellung zu tun.
2. Starten Sie von den Datendateien in der Datenbank lesen.
3. Halten Sie beim Lesen von Datendateien und stellen eine Notiz die Protokollsequenznummer des Beginns der ältesten aktiven Transaktion zu diesem Zeitpunkt (Siehe meinen Artikel "Understanding Protokollierung und Wiederherstellung in SQL Server" eine Erläuterung dieser Begriffe).
4. Lesen Sie, wie viele Transaktionsprotokolleinträge wie erforderlich ist.

Erläutert, wie viele Transaktionsprotokolleinträge erforderlich ist erfolgt am besten, wenn das visuelle Hilfsmittel in Abbildung 1 ist.Die roten Zahlen auf der Zeitachse werden in dieser Liste beschrieben:

1. Prüfpunkt und das Lesen aus der Datenbank beginnen.
2. Der Lesevorgang liest Seite X.
3. Transaktion A wird gestartet.
4. Transaktion A nimmt eine Änderung auf Seite X.Die Kopie in die Sicherung ist jetzt veraltet.Beachten Sie, dass die Sicherung nicht Seite X erneut gelesen werden – es ist bereits diesem Punkt in der Datenbank übergeben.
5. Transaktion B beginnt.Es wird nicht vor dem die Daten lesen Vorgang abgeschlossen ist abgeschlossen.
6. Transaktion A übernimmt.Übernimmt diese Änderungen auf Seite X.
7. Die Sicherungsdaten lesen Vorgang abgeschlossen ist und Transaktionsprotokoll lesen beginnt.

Abbildung 1 Beispiel Zeitplan von Änderungen während einer vollständigen Sicherung

Genügend das Transaktionsprotokoll sichern ist erforderlich, so dass Wiederherstellung während der Wiederherstellung erfolgreich ausführen kann und so dass alle Seiten in der Datenbank am gleichen Punkt in Mal sind – die Zeit an dem die Daten lesen Teil des Sicherungsvorgangs (7 zeigen) abgeschlossen.Ende der Sicherung (Point-7), das Transaktionsprotokoll vom Anfang der ältesten aktiven (oder für die kein Commit ausgeführt wurde) Transaktion (Point-5, Transaktion B) ist erforderlich, um Wiederherstellung ausführen zu ermöglichen.Das Transaktionsprotokoll von Sicherung Prüfpunkt (Point 1) zurück an das Ende der Sicherung (Point-7) ist erforderlich, um alle Seiten, die zum gleichen Zeitpunkt im Zeitraum geschaltet werden können.

Wenn das Transaktionsprotokoll nur aus eingeschlossen wurde würde den Anfang der ältesten aktiven Transaktion (Point-5) und dann die Kopie von Seite X, die aus der Sicherung wiederhergestellt wurde unter Punkt 2 Lesen nicht mit den Änderungen von Transaktion A aktualisiert werden, bei Punkt 4 aufgetreten ist.Dies bedeutet, dass es nicht mit dem Rest der Datenbank als der Zeit transaktionell konsistent würde das Lesen von Daten (Point-7) abgeschlossen.

Also die minimale Protokollsequenznummer (log Sequence Number, LSN) des Transaktionsprotokolls, die in der vollständigen Sicherung enthalten ist ist MIN (LSN des Sicherung Prüfpunkt, LSN der ältesten aktiven Transaktion), und er konnte für eine Transaktion, die begann noch vor Beginn die Sicherung werden.Stellt dies sicher, dass die wiederhergestellte Kopie der Datenbank (oder was Sie wiederhergestellt, Seite, Datei, Dateigruppe, Datenbank) ist vollständig konsistent.

Dieser Mechanismus bedeutet, dass Transaktionen nicht in irgendeiner Weise durch Sicherungsvorgänge, angehalten werden, obwohl zusätzliche e/a-Auslastung der Datenbank diese geringfügig verlangsamen kann.Der Nachteil dieser Mechanismus ist, dass das Transaktionsprotokoll für die Dauer der vollständigen Sicherung gelöscht werden kann nicht, da erforderlich ist.Wenn es zahlreiche Aktualisierungsaktivität gibt und die vollständige Sicherung sehr lange dauert um abzuschließen, dies könnte zur Vergrößerung der Transaktionsprotokolle führen – ein Problem, das ich bereits in mehrere früheren Artikeln und in der Spalte SQL Fragen besprochen haben.

Die Daten in eine vollständige Sicherung ist nicht unbedingt mit den Inhalt aller Datendateien.Die Sicherung wird nur die reservierten Seiten von den Datendateien enthalten.Beispielsweise kann eine einzige Dateidatenbank 100 GB werden jedoch nur 15 GB zugewiesenen Daten enthalten.In diesem Fall wird die vollständige Sicherung nur 15 GB von zugeordneten Daten sowie das erforderliche Transaktionsprotokoll enthalten.(Allerdings die wiederhergestellte Datenbank werden immer die gleiche Größe wie die ursprüngliche – in diesem Fall 100 GB.)

Ein weiteres verbreitetes Missverständnis ist, dass der Sicherungsvorgang überprüft oder ändert die Daten gesichert ist.Dies ist unwahre, außer in einem einzigen Fall, wenn Sicherung Prüfsummen aktiviert sind, die ich in Kürze eingehen werde.

Differenzielle Sicherungen

Der andere Typ der Datensicherung ist bei einer differenziellen Sicherung.Eine differenzielle Sicherung führt dieselben Operationen wie eine vollständige Sicherung, doch nur enthält alle Daten, die geändert oder hinzugefügt wurden, seit der vorherigen vollständigen Sicherung.Ein weit verbreitetes Missverständnis hier darin, dass differenzielle Sicherungen inkrementell sind.Sie sind tatsächlich kumulative und nachfolgende differenzielle Sicherungen nach einer vollständigen Sicherung und erhöht die Größe, weitere Daten geändert oder hinzugefügt werden.

In jeder 4 GB ist Abschnitt (ein GAM-Intervall genannt) jeder Datendatei eine spezielle Datenbankseite aufgerufen, eine differenzielle Bitmap, die verfolgt, welche Teile (Blöcke bezeichnet), Abschnitt 4 GB geändert haben, seit der letzten vollständigen Sicherung, der Daten, die geändert oder der Datenbank hinzugefügt wurden anzeigt.(Es gibt mehrere andere Zuordnung Bitmaps zu, und finden Sie weitere Informationen über diese in meinem Blog-Artikel"Innerhalb der Speichermodul: GAM SGAM, PFS und andere Zuordnungstabellen").

Bei einer differenzielle Sicherung durch diese Bitmaps überprüft und nur die Daten gesichert Datei Blöcke, die als geändert gekennzeichnet sind.Die Bitmaps werden von der nächsten vollständigen Sicherung zurückgesetzt, so dass Sie, mehr und mehr der Datenbankänderungen, mehr davon werden markiert im differenzielle Bitmaps und nachfolgende differenzielle Sicherungen werden größere und größere sehen können.Wenn die meisten der Datenbank geändert hat, kann bei einer differenzielle Sicherung schließlich so groß wie der vollständigen Sicherung werden.Sie können herausfinden, wie groß Ihre nächste differenzielle Sicherung ein mir geschriebenen Skript verwenden werden, die in meinem Blog Artikel verfügbar ist"Neues Skript: wie viel von der Datenbank seit der letzten vollständigen Sicherung geändert hat?." Übrigens dieses Skript kann außerdem werden verwendet, um eine Vorstellung von Anzahl die Änderung einer Datenbank abzurufen, z. B. auf einer SharePoint-Inhalt-Datenbank.

Einer Notiz Seite sollte Wenn Sie eine vollständige Sicherung Ad-hoc- und nicht es, die differenzielle Bitmaps zurücksetzen haben Sie die Option WITH COPY_ONLY auf die BACKUP-Anweisung verwenden.Dies ist sehr nützlich, als andernfalls nächsten differenziellen Sicherungen würden werden basierend auf der Ad-Hoc vollständige Sicherung Sie dauerte, anstatt auf die regulären (wahrscheinlich geplante) vollständige Sicherung.Dies kann zu großen Problemen führen, wenn Sie versuchen, in einer Situation Notfall wiederherzustellen.

Warum unterscheiden sich differenzielle Sicherungen hilfreich?Wie ich im Abschnitt Sicherungsstrategie erläutert wird, können differenzielle Sicherungen wirklich Wiederherstellung beschleunigen, indem ermöglicht viele Transaktionsprotokollsicherungen in der Wiederherstellungsvorgang übersprungen werden.Es ist viel schneller im Wesentlichen Vorwärts springen, in Mal mit eine differenzielle Sicherung als zum wiedergeben, zahlreiche Transaktionsprotokoll-Datensätze um Zeit zu der gleichen Stelle zu gelangen.

Transaktionsprotokollsicherungen

Sicherungen des Transaktionsprotokolls sind nur möglich, in den Wiederherstellungsmodellen FULL oder BULK_LOGGED während vollständige und differenzielle Sicherungen auch in das Wiederherstellungsmodell SIMPLE möglich sind.

Eine Sicherung des Transaktionsprotokolls enthält alle Transaktionsprotokolleinträge, die seit der letzten Protokollsicherung generiert (oder vollständige Sicherung, startet eine Protokollsicherungskette) und zum ermöglichen der Datenbank zu einem bestimmten Zeitpunkt (normalerweise der Zeit, rechts, bevor ein Notfall) wiederhergestellt werden.Dies bedeutet diese inkrementelle, anders als bei differenziellen Sicherungen sind kumulativ sind.Da diese sind inkrementell, wenn Sie die Datenbank auf einem bestimmten Punkt in Zeit wiederherstellen möchten müssen Sie damit alle die Transaktionsprotokolleinträge zum Wiedergeben von Datenbankänderungen bis zu Zeitpunkt.Diese sind in die Protokollsicherungskette enthalten.

Eine Protokollsicherungskette ist ein ununterbrochener Folge von Protokollsicherungen, die alle die Transaktionsprotokolleinträge zum Wiederherstellen einer Datenbank auf einen Punkt in Mal enthalten.Eine Kette beginnt mit einer vollständigen Datenbanksicherung und wird fortgesetzt, bis etwas unterbricht die Kette, so dass weitere Sicherungen durchgeführt werden, bis ein anderes vollständigen (oder differenziell) Sicherung ist.

Vorgänge, die die Protokollsicherungskette unterbrochen gehören das Wiederherstellungsmodell SIMPLE wechseln, über einen Datenbanksnapshot-wiederherstellen und zwangsweise Löschen des Protokolls mit den Optionen WITH NO_LOG oder TRUNCATE_ONLY (die nicht in SQL Server 2008 verfügbar sind).Es ist inadvisable die Protokollsicherungskette unterbrochen, da es zwingt anderen (potenziell große) vollständige Sicherung ausgeführt werden.

Obwohl eine Protokollsicherungskette an einer vollständigen Sicherung wird gestreckt, müssen Sie nicht unbedingt die Protokollsicherungen während der Wiederherstellung wiederherzustellen.Wenn Sie eine vollständige Sicherung, z. B. auf Nacht von Sonntag und Mittwoch Abend mit Transaktionsprotokollsicherungen jede halbe Stunde seit Sonntag Nacht dauerte dann Wiederherstellen der Datenbank nach einem Notfall am Freitag könnte verwenden werden, Mittwoch der vollständigen Sicherung sowie alle Protokollsicherungen seit Mittwoch Abend anstatt ganz wechseln zurück zum Sonntag Nacht vollständige Sicherung.(Der zweite Artikel in unserer Reihe tiefer in diesem Thema gehen.)

Protokollsicherungen sind auch erforderlich, um die Größe des Transaktionsprotokolls zu verwalten.In den Wiederherstellungsmodellen FULL oder BULK_LOGGED wird das Protokoll nicht deaktivieren, bis eine Protokollsicherung (Siehe Artikel Februar Einzelheiten von Was bedeutet Protokoll löschen), ausgeführt wurde, regelmäßige Transaktionsprotokollsicherungen verhindern, dass die Protokolldatei außerhalb des Steuerelements größer durchgeführt werden müssen.Wenn das Protokoll kann nicht zu löschen, kann das Protokoll vergrößert, bis der Speicherplatz ausreicht.Wenn Sie keine in-Wiederherstellung einem bestimmten Zeitpunkt mit Transaktionsprotokollsicherungen durchführen möchten, ist die einfachste Option, zum das Wiederherstellungsmodell SIMPLE wechseln und die Wiederherstellungsmodellen FULL oder BULK_LOGGED nicht verwenden.Erörtert diese ausführlicher in den Blogbeitrag „Bedeutung der richtigen Protokoll Größe Transaktionsverwaltung."

Es ist ein Sonderfall in die Protokollierung, die die Leistung, verbessert indem einige Vorgänge als minimal protokollierter Operationen ausführen, werden nur die Seitenzuweisungen protokolliert, nicht das tatsächliche Einfügen von Daten.Dies kann die Leistung der Vorgänge wie Massenkopieren lädt verbessern und Index neu erstellt.In diesen Fällen nicht alles über die Operation wird protokolliert, damit die Protokolldateien gesichert Datensätze nicht genügend Informationen zum wiedergeben, des Vorgangs vollständig enthalten.In diesem Fall können Wiederherstellen Wiederherstellung möglicherweise Funktionsweise und wenn nicht genügend Informationen vorhanden ist?

Die Antwort lautet, dass die erste Protokollsicherung folgenden einen Vorgang nur minimal protokolliert auch einige Daten enthält.Genau wie die differenzielle Bitmaps bereits erwähnt, besteht ein anderes Bitmap bezeichnet die Bitmap minimal protokolliert (auch als die Zuordnung Massenkopieren geändert bezeichnet).Diese Bitmap wird verfolgt, welche Blöcke einer Datendatei wegen eines Vorgangs nur minimal protokolliert geändert wurden.

Die Protokollsicherung, die eine Operation minimal protokolliert folgenden wird diese Bitmaps durchsuchen und diese Daten-Blöcke, die als geändert gekennzeichnet sind auch sichern.Die Bitmaps werden nach der überprüften gelöscht.Dies bedeutet, dass die Protokollsicherung genügend Informationen, um vollständig die Auswirkungen der Minimal protokolliert Vorgang in der Datenbank wiederzugeben, wenn die Protokollsicherung wiederhergestellt wird.Es ist jedoch einen Haken: Es gibt nichts in die Protokollsicherung, die bei jeder Block bestimmte Daten geändert wurde.So eine Protokollsicherung, die auch Daten aus einer minimal protokollierte Operation enthält in einer beliebigen Stelle in Zeit, außer am Ende der Zeit Periode behandelt wiederhergestellt werden kann (oder Beyond, wenn die Protokollsicherung Teil eine Protokollsicherungskette ist, die Sie aus wiederherstellen sind).Während Sie Leistungsverbesserungen beim Wechsel zum massenprotokollierten Wiederherstellungsmodell erhalten können, müssen Sie berücksichtigen als temporäre Vorgang ändern, nur um die Stapelverarbeitung zu verbessern und nachdem die Stapelverarbeitung abgeschlossen ist, sollten Sie wechseln Sie zurück zu voll und so bald wie möglich eine Protokollsicherung durchführen.

Es gibt auch eine besondere Fall Protokollsicherung damit das Protokoll nach einem Notfall gesichert werden, die die Datendateien beschädigt.Dies wird als eine Ende der Protokolldatei (oder Tail-Protokoll) Sicherung bezeichnet, die Datendateien beschädigt oder zerstört werden können, wobei das bis zu dem Notfall Punkt Transaktionsprotokoll gesichert werden kann.Dadurch minimalem Aufwand Verlust (minutengenaue Wiederherstellung bezeichnet) Wenn anschließend die Datenbank wiederhergestellt, jedoch wird unterstützt nur, wenn die Datenbank in das Modell der VOLLSTÄNDIGEN Wiederherstellung ausgeführt wird.Weitere Informationen dazu und Einschränkungen mit minimal protokollierte Operationen finden Sie in der Onlinedokumentation im Thema"Schweif-Protokoll-Sicherungen." Der erste Bildschirm umgewandelt, die diesen Artikel begleitet zeigt mich Ende der Protokolldatei Sicherungen veranschaulichen.

In Versionen von SQL Server vor SQL Server 2005 konnte Sicherungen des Transaktionsprotokolls nicht gleichzeitig mit vollständigen Datenbanksicherung oder differenzielle Datenbanksicherungen ausgeführt werden – Sie würden blockieren, bis die Datenbankebene Sicherung abgeschlossen.Datei und Dateigruppe basierten Sicherungen Protokollsicherungen zum Blockieren nicht verursachen.Gegeben während dieser den Wiederherstellungsprozess für Datei-und Dateigruppensicherungen kompliziert, haben es diese einen Vorteil durch nicht blockieren Transaktionsprotokollsicherungen.In SQL Server 2005 arbeiten alle vollständige und differenzielle Sicherungen (unabhängig von Komponente) auf die gleiche Weise.Jetzt ist das Verhalten, dass der gleichzeitige Transaktionsprotokoll-Sicherungskopie abgeschlossen ist, aber das Transaktionsprotokoll erst die vollständige nicht gelöscht wird oder differenzielle Sicherung (die das Protokoll erfordert) auch abgeschlossen ist.

Sicherungs Strategie planen

Nun, Sie über die drei Typen von Sicherungen und deren Funktionsweise wissen, zeige ich Ihnen wie Sie Sie zusammen in einer Sicherungsstrategie platzieren können.

Eine allgemeine Frage ich ist wie So starten Sie über eine Sicherungsstrategie nachzudenken.Ich möchte immer sagen, dass Sie eine Sicherungsstrategie entwerfen sollten nicht.Sie sollten eine Wiederherstellungsstrategie entwerfen –, können Sie im Falle eines einem Notfall so wenig wie möglich wiederherstellen, sodass Ihre Ausfallzeit so klein wie möglich, ist Beibehaltung noch Ihre Daten.Nach dem Sie gearbeitet haben, aus, und welche Sicherungen erarbeiten müssen Sie so dass Sie die Wiederherstellung ausführen können.Mit anderen Worten, sollte Ihre Sicherungsstrategie Ihre Recovery Time Objective (RTO) und RPO (Recovery Point Objective) erfüllen können.

Mit einer Strategie, die nur vollständige Sicherungen enthält haben Sie etwas in mit Wiederherstellungen Verwendungsmöglichkeiten begrenzt.Grundsätzlich können Sie nur zum Zeitpunkt der jedem vollständigen Sicherung, wie in Abbildung 2 wiederherstellen.Wenn Notfall auf 23: 59 am Samstag unmittelbar vor die nächste vollständige Sicherung geplant ist, kann dann die Arbeit seit der letzten vollständigen Sicherung verloren.Aus diesem Grund sind wenn Datenverlust vermieden werden muss und die Daten können nicht wiederhergestellt werden, Protokollsicherungen ebenfalls enthalten, wie in Abbildung 3 dargestellt.

Abbildung 2 Sicherungsstrategie mit nur vollständige Sicherungen

Abbildung 3 Sicherungsstrategie mit vollständig und Protokoll-Sicherungen

Genommen Sie an, dass die Protokollsicherungen alle 30 Minuten entnommen wurden.Solange die Sicherungen verfügbar sind, bedeutet dies, dass die Datenbank zu einem beliebigen Punkt wiederhergestellt werden kann.Allerdings dies immer noch die beste Strategie möglicherweise nicht.Was geschieht, wenn am 23: 59 am Samstag mit dieser Strategie Stelle Notfall?Zuerst wäre nutzen ein Tail-des-des-Protokoll Sichern und starten anschließend wiederherstellen.

Zum Wiederherstellen der Datenbank bis zu bedeutet der Punkt der Notfall letzten Sonntag vollständige Sicherung und dann 336 Transaktionsprotokollsicherungen (das sechs Tage 48 Protokollsicherungen pro Tag, plus 47 samstags plus Tail des Protokoll-Sicherung) wiederherstellen.Je nachdem, wie viel Änderung gab es in der Datenbank in der Woche, die eine große Menge von Transaktionsprotokolleinträgen werden könnten, die zum Wiedergeben einer sehr lange Zeit benötigen wird.Ist eindeutig keine optimale Wiederherstellungsstrategie, aber es ist eine verbreitete Strategie im Feld sehe.Wenn Sie eine Strategie Aussehen haben, stellen Sie sicher, dass Sie geübt haben eine Wiederherstellung durchführen, damit Sie wissen, ob Sie Ihre RTO im Falle eines eines Notfalls treffen können.

Um dieses Problem zu verringern, einige Strategien häufigere vollständige Sicherungen verwenden, aber diese möglicherweise unbezahlbar groß, um jeden Tag, z. B. in Anspruch nehmen.Die Alternative ist die Verwendung differenzielle Sicherungen die nur die Daten enthalten, die seit der vorherigen vollständigen Sicherung geändert wurden.Sie unser Beispiel fortfahren, wird die Strategie in Abbildung 4 dargestellt.

Abbildung 4 Sicherungsstrategie mit voll, protokollieren, und differenzielle Sicherungen

Mit dieser Strategie ist die Wiederherstellung von einer Katastrophe am 23: 59 am Samstag viel schneller.Beachten Sie, dass eine differenzielle Sicherung kumulative ist – daher der Wiederherstellungsstrategie ist der Sonntag vollständigen Sicherung, die 00: 00 Samstag differenzielle Sicherung sowie alle Protokollsicherungen Samstag.Müssen die differenzielle Sicherung von 00: 00 bedeutet, dass Samstag, dass alle Protokollsicherungen vor können übersprungen werden, wie die differenzielle Sicherung enthält werden der gleiche wie der Net-Ergebnis wiederherstellen alle Protokollsicherungen.

Zeigt deutlich die Vorteile von jeder Sicherungstyp, aber dies war ein ziemlich einfaches und erfundene Beispiel.Nachdem Sie Ihre Sicherungsstrategie entworfen haben, überprüfen Sie, um sicherzustellen, dass Sie die gewünschten Wiederherstellungen durchführen können.

Hier ist ein Beispiel für ich ein Gesicht Kunden wieder ein paar Jahren erhalte.Ein Kunde hat eine beschädigte Datenbank und mit NULL Datenverlust wiederherstellen möchten.Sie wurden zögern, mit deren Sicherungen und versucht Reparieren auf eine Kopie der Datenbank ausgeführt, aber es hatte, Löschen von Daten, in deren Sicherungen mit zu erzwingen.Herausstellte, dass eine vollständige Sicherung von Januar plus eine Protokollsicherung jede halbstündigen bis zum April mussten – über 5.000 Sicherungen insgesamt und alle auf Band!Ich bin sicher, Sie parallelen Ihre Augen und aber tatsächlich hat; es dauerte jedoch drei Tage dafür denken, "Ich natürlich, Sie funktioniert nicht,"!Der Kunde betrachtet eine gute Sicherungsstrategie mussten – VOLLSTÄNDIGE Wiederherstellung Modell plus Protokoll Sicherungen – Ihre Sicherungsstrategie hat können jedoch die Wiederherstellungen durchführen, die Sie wollten.

Sicherung Integrität

Es gibt kein Punkt im Sicherungen müssen, wenn Sie feststellen, dass Sie beschädigt, sind Wenn Sie versuchen, Sie wiederherzustellen.Natürlich überprüft am besten überprüfen die Gültigkeit der Sicherungen wird diese auf einem anderen Server wiederherstellen, jedoch in SQL Server 2005 ein neues Feature wurde eingeführt, die einige Integrität von Sicherungen durchgeführt werden, ohne Sie tatsächlich wiederherzustellen.Sie können die Option WITH CHECKSUM verwenden, bei eine Sicherung (alle verschiedenen).

Auf diese Weise eine Prüfsumme erstellt, über den gesamten Sicherung Stream, der in der Sicherung selbst gespeichert wird.Wenn die Sicherung eine vollständige oder differenzielle ist und die Datenbank Seitenprüfsummen aktiviert hat, dann verursacht diese Option außerdem alle vorhandenen Seitenprüfsummen getestet werden, als der Sicherungsvorgang die Seiten liest.Wenn eine Prüfsumme beschädigte Seite gefunden wird, schlägt der Sicherungsvorgang fehl.Dies bietet hervorragende Schutz gegen versehentlich Sichern einer Datenbank, die bereits in irgendeiner Weise beschädigt ist.(Sie können Informationen Seitenprüfsummen "Top-Tipps für effektive Datenbankwartung" finden im Artikel vom August 2008.)

Sobald die Sicherung abgeschlossen wurde, kann es mit einem Befehl wie folgt überprüft werden:

RESTORE VERIFYONLY FROM <backup device(s)> WITH CHECKSUM

Neu berechnet die Prüfsumme über die gesamte Sicherung Stream wird und mit der Sicherung gespeichert vergleichen. Für vollständigen und differenziellen Sicherungen wird es auch in der Sicherung alle Seitenprüfsummen auf Seiten testen. Wenn Probleme gefunden werden, dann wissen Sie, dass die Sicherung in irgendeiner Weise beschädigt wurde.

Natürlich sind gibt es die Ausnahmen für die Regel, in denen Sie möglicherweise eine beschädigte Datenbank sichern möchten (falls es die einzige Kopie der Datenbank haben und Sie bei Abwesenheit ausführen, z. B. Reparatur). In diesem Fall können Sie erzwingen, die Sicherung mit der Option WITH CONTINUE_AFTER_ERROR abgeschlossen wird.

Finden Sie weitere Informationen zur Sicherung Überprüfung auf Informationen zur Sicherung Validierung in meinem blogein, woraufhin auch mir einige Aspekte der Sicherung Validierung im zweiten Bildschirm umgewandelt zu veranschaulichen, die diesen Artikel begleitet.

Zusammenfassung

Wie bei jedem komplexen Thema viele Bereiche von Sicherungen, die ich Speicherplatz Deckblatt verfügen, um nicht vorhanden sind, aber jetzt, dass die Grundlagen behandelt werden, können Sie in einige der Onlinedokumentation und Blog Verknüpfungen tiefer Informationen eintauchen. Der beste Ausgangspunkt in der Onlinedokumentation ist dem Thema" Sicherung (Übersicht) (SQLServer)." In meinem Blog Sie beginnen mit der Sichern/Wiederherstellen-Kategorie.

Ein Bereich, die möglicherweise Ihrer Meinung nach ist deutliche in dessen Abwesenheit Sicherungskomprimierung ist. Dies ist absichtliche, wie ich später im Jahr in einem Artikel auf alle neuen Komprimierung-Technologien in SQL Server 2008 verdeckt werden müssen. In der Zwischenzeit können Sie die Onlinedokumentation Auschecken" Sicherung Komprimierung (SQLServer)"und auch auf meinem blog.

Wenn ich in diesem Artikel in drei Aufzählungspunkte summieren musste, würden Sie sein:

• Stellen Sie sicher Sie Sicherungen verfügen.
• Überprüfen Sie Sicherungen gültige.
• Überprüfen Sie die richtigen Sicherungen.

Mit anderen Worten, nehmen Sicherungen Wenn Sie Ihre Datenbank wiederherstellen können möchten etwas damit Sie wissen die Sicherungen funktionieren, wenn Sie werden benötigt, und stellen Sie sicher, die Sie aus den Sicherungen wiederherstellen können und Ihre RTO und freigegebenen FERTIGUNGSAUFTRAG zu erfüllen.

Im nächsten Artikel werde ich erläutern alles Wiederherstellen von Sicherungen, einschließlich verschiedenen Arten von Wiederherstellungen und deren Funktionsweise, Wiederherstellen von mehreren Sicherungen und partielle Datenbankverfügbarkeit.

Löschen Sie in der Zwischenzeit und wie immer, wenn Sie Feedback oder Fragen haben, mir eine Zeile am Paul@SQLskills.com.

Paul S. Randal ist der leitende Direktor von SQLskills.com, SQL Server-MVP und Microsoft Regional Director. Er wird im SQL Server-Speichermodul Team bei Microsoft von 1999 zu 2007 gearbeitet. Paul schrieb DBCC CHECKDB/Repair für SQL Server 2005 und SQL Server 2008-Entwicklung für das Kernspeichermodul zuständig war. Paul ist Experte für Notfallwiederherstellung, hohe Verfügbarkeit und Datenbankwartung und ein regelmäßiger Referent bei Konferenzen weltweit. Er Blogs an SQLskills.com/blogs/paul.