Warum kann eine differenzielle Sicherung ihre Basis nicht angeben?


18

Dies ist mein erster DBA.SE-Beitrag. Bitte teilen Sie mir etwaige Fehler mit, danke!

Ich bin ein neuer DBA (kein IT-Profi, nur niemand im Unternehmen, der das macht). Je grundlegender die Erklärung, desto besser. Ich habe über Datenbanksicherungsstrategien gelesen (oder, wie ich gelernt habe, "Wiederherstellungsstrategien"). Ich verstehe die Funktionsweise von vollständigen, differenziellen und Transaktionsprotokollsicherungen, möchte jedoch wissen, warum eine differenzielle Sicherung nur auf der neuesten vollständigen Sicherung basieren kann.

Wenn sich bei einer differenziellen Sicherung alles seit der letzten vollständigen Sicherung geändert hat, warum kann die differenzielle Sicherung dann nicht auf einer Sicherung meiner Wahl basieren? Um es klarer zu machen, frage ich Sie, ob Sie die Basis angeben möchten, wenn das Backup erstellt wird, und nicht, wenn Sie es wiederherstellen. Ich gehe davon aus, dass Sie bei der Wiederherstellung die richtige Basis und das entsprechende Differential auswählen würden, um die Wiederherstellung durchzuführen (ohne ein Differential aus Basis B für die Wiederherstellung aus Basis A zu verwenden).

Was ist der Grund, warum diese Funktionalität nicht möglich ist? Ich denke, dass es einen Grund geben muss, ich weiß nur nicht, was es ist.

Hinweis: Ich verstehe, dass die Basis nicht angegeben werden kann, aber meine Frage ist, warum nicht ? (Ich habe auch kein Interesse an Diskussionen über "Warum würdest du?")

Analogie

Hier ist eine Analogie, wie ich eine differenzielle Sicherung verstehe:

Ich habe eine Excel-Datei mit einigen Daten in Zellen.

Am ersten Tag mache ich eine Kopie dieser Datei und speichere sie an einem anderen Ort (die "vollständige Sicherung").

Am zweiten Tag schaue ich mir die Datei an und vergleiche sie mit der Sicherungskopie, die ich am ersten Tag erstellt habe. Dabei stelle ich fest, welche Zellen sich geändert haben und welche neuen Werte sie haben (eine "differenzielle Sicherung"). Ich notiere nicht jede an einer Zelle vorgenommene Änderung, sondern nur deren endgültigen Wert. Wenn Zelle A1 als "Alfred" gestartet und in "Betty", "Charlie" und dann "Dave" geändert würde, würde ich nur feststellen, dass "A1 ist jetzt Dave".

Am dritten Tag vergleiche ich die aktuelle Datei erneut mit der Sicherungsdatei und notiere die Änderungen (eine weitere "differenzielle Sicherung" mit derselben Basis wie am zweiten Tag). Wiederum wurden nur die Endwerte pro Zelle zum beobachteten Zeitpunkt notiert, nicht alle Werte, die die Zelle den ganzen Tag über hatte.

An Tag 4 vergleiche ich erneut und bemerke Änderungen erneut. Fahren Sie mit Zelle A1 fort, und dort steht jetzt "Sarah", auch wenn es den ganzen Tag über 10 andere Namen waren. Ich stelle nur fest, dass "Jetzt ist A1 Sarah".

Am 5. Tag wird meine Akte durcheinander gebracht. Ich schaue mir also die Sicherungskopie an, die ich an Tag 1 erstellt habe, dann die Endzustände, die an Tag 4 notiert wurden, und wende die Änderungen an, die an der Sicherungskopie notiert wurden. Jetzt habe ich die Datei so "wiederhergestellt", wie sie an Tag 4 war Ich schaue mir also die Sicherung an, die am ersten Tag erstellt wurde, und stelle fest, dass die Zelle A1 am vierten Tag als "Sarah" endete, und ändere die Sicherungszelle A1 in "Sarah".

Warum wäre es wichtig, wenn ich am zweiten Tag eine weitere Sicherungskopie ("vollständig") der Datei erstellt hätte? Warum ist es nicht möglich, die Datei am 3. oder 4. Tag mit der am 1. Tag erstellten Kopie zu vergleichen (lesen, "differenziell sichern")? Nach meinem Verständnis würde SQL Server von mir verlangen, dass ich (wenn ich eine andere differenzielle Sicherung mache) mit einer vollständigen Sicherung vergleiche, die am zweiten Tag erstellt wurde (wenn eine erstellt wurde) - keine andere Option.

Antworten:


14

Bei einer differenziellen Sicherung wird mithilfe der so genannten Änderungszuordnung eine Liste der Seiten erstellt , die seit der letzten vollständigen Sicherung geändert wurden. Diese Liste ist eine "differenzielle" Liste, daher der Name des Sicherungstyps und der Grund, warum die Sicherung immer nur über der zugehörigen vollständigen Sicherung wiederhergestellt werden kann.

Durch das Durchführen einer vollständigen Sicherung wird die Änderungszuordnung für das Differential zurückgesetzt. Ab diesem Zeitpunkt wird jede Seite, die geändert wird, in der Karte aufgezeichnet. Wenn Sie dann ein Differential erstellen, enthält diese Sicherung nur Seiten, die seit der letzten vollständigen Sicherung geändert und in der Karte aufgezeichnet wurden.

In Ihrer Analogie haben die beiden vollständigen Sicherungen, die als Grundlage für den gesamten Wiederherstellungsprozess dienen, wahrscheinlich unterschiedliche Inhalte und daher unterschiedliche differenzielle Zuordnungen. Wenn Sie ein Diff basierend auf der ersten Sicherung über der zweiten Sicherung wiederherstellen, ist die Datenbank wahrscheinlich beschädigt. Tatsächlich verhindert SQL Server die Wiederherstellung einer Diff-Sicherung über alles außer der ursprünglichen vollständigen Sicherung, auf der sie basiert.

Wenn Sie SQL Server auffordern, eine differenzielle Sicherung durchzuführen, ist die einzige "Basis" für die differenzielle Sicherung die einzelne Änderungszuordnung für die differenzielle Sicherung, die zum Zeitpunkt des Starts der differenziellen Sicherung in der Datenbank vorhanden ist. Aus diesem Grund können Sie die Basis für die differenzielle Sicherung nicht angeben.


Als Antwort auf einen Kommentar von @MartinSmith können Sie möglicherweise COPY_ONLYSicherungen verwenden , um eine differenzielle Sicherung über eine Reihe von vollständigen Sicherungen wiederherzustellen. Stellen Sie sich das folgende Szenario vor:

  1. BACKUP DATABASE xyz TO DISK = 'path_to_backup.bak';
  2. BACKUP DATABASE xyz TO DISK = 'path_to_backup_2.bak' WITH COPY_ONLY;
  3. BACKUP DATABASE xyz TO DISK = 'path_to_backup_3.bak' WITH COPY_ONLY;
  4. BACKUP DATABASE xyz TO DISK = 'path_to_backup_4.bak' WITH COPY_ONLY;
  5. BACKUP DATABASE xyz TO DISK = 'path_to_backup_diff.bak' WITH DIFFERENTIAL;

Die differenzielle Sicherung in Schritt 5 sollte über alle in den Schritten 1 bis 4 durchgeführten Sicherungen wiederhergestellt werden können, da die differenzielle Änderungszuordnung nur gelöscht wird, wenn die vollständige Sicherung in Schritt 1 ausgeführt wird. Die COPY_ONLYSicherungen in den Schritten 2, 3 und 4 setzen die Änderungszuordnung nicht zurück. Da die Karte differentielle Änderung sammelt Änderungen seit der vollständigen Sicherung vorgenommen, jede der aufeinanderfolgenden COPY_ONLYenthält Sicherungen genügend Informationen für die differenzielle Sicherung an die Arbeit gegen jede der vorangegangenen 4 - Backups.

In der Praxis führt das Wiederherstellen eines Differentials über eine Sicherungskopie nur zu folgendem Fehler:

Meldung 3136, Ebene 16,
Status 1, Zeile 1 Diese differenzielle Sicherung kann nicht wiederhergestellt werden, da die Datenbank nicht im richtigen früheren Status wiederhergestellt wurde.
Meldung 3013, Ebene 16, Status 1, Zeile 1
DATENBANK WIEDERHERSTELLEN wird abnormal beendet.

Ich habe einen SQL Server 2012-Plattform-Repro zum Testen von Differential- und copy_only-Wiederherstellungen erstellt und die Datei auf gist.github.com gespeichert RestoreTest.


Wenn Sie eine vollständige Sicherung durchführen, wird die Änderungszuordnung für das Differential nur zurückgesetzt, wenn dies nicht COPY_ONLYder Fall ist. Wenn das OP an Tag 1 eine regelmäßige vollständige Sicherung und COPY_ONLYan Tag 2 eine vollständige Sicherung durchführen würde, welche Probleme würden durch das Anwenden eines späteren Differentials von derselben Basis verursacht zum tag 2 backup?
Martin Smith

Ich habe es gerade getestet und in der Praxis ist es nicht möglich, das spätere Differential auf einem copy_only wiederherzustellen, obwohl "Dieses Differential-Backup kann nicht wiederhergestellt werden, da die Datenbank nicht in dem korrekten früheren Zustand wiederhergestellt wurde." - Ich bin mir nicht sicher, ob es einen Grund gibt, warum dies nicht funktioniert, oder ob es einfach nicht implementiert ist.
Martin Smith

1
@ MartinSmith - schießen. Ich habe das jetzt auch bestätigt.
Max Vernon

5

Die Funktion , die Sie wollen , könnte im Prinzip existiert. Mit den aktuellen Datenbankstrukturen wäre dies nicht effizient (siehe Max Vernons Antwort). SQL Server muss entweder einen Satz von Diff-Zuordnungen verwalten oder den aktuellen DB-Inhalt mit der vollständigen Sicherung vergleichen, die Sie als Basis angeben.

Es gibt Anwendungen, die große Dateien deduplizieren. Sie können zwei vollständige Sicherungen durchführen und nur die geänderten Daten werden tatsächlich gespeichert. Dies ist wie ein Diff mit einer benutzerdefinierten Basis. exdupezum Beispiel kann das tun.

Das Schöne daran ist, dass es mit jedem Satz von Sicherungsdateien überhaupt funktioniert. Tatsächlich zahlen Sie ab der dritten vollständigen Sicherungsdatei nur noch inkrementellen (nicht differenziellen) Speicherplatz. Der Speicherplatzbedarf ist der Unterschied zur vorherigen Sicherungsdatei (nicht zur ersten). Deduplizierende Speicher weisen ein ähnliches Verhalten auf.

Warum existiert die von Ihnen beschriebene Funktion nicht? Jedes Feature verbraucht Budget, sodass andere Features nicht vorhanden sind. Dieser hat es anscheinend nicht weit genug auf die Prioritätenliste geschafft. Ich bin mir nicht sicher, wofür es gut wäre. Scheint eine ziemlich esoterische Anforderung zu sein, benutzerdefinierte Basen zu verwenden.


3

Verwechseln Sie Transaktionsprotokollsicherungen nicht mit differenziellen Sicherungen, sie haben unterschiedliche Zwecke! Was Sie eine "differenzielle Sicherung" nennen, bei der Sie "alle Änderungen an den Zellen notieren", ist in Wirklichkeit ein Transaktionsprotokoll .

Der Zweck einer differenziellen Sicherung besteht darin, die Größe der resultierenden Sicherungsdatei klein zu halten, indem nur die Informationen aufgezeichnet werden, die sich seit der letzten vollständigen Sicherung geändert haben, und die Wiederherstellungszeit innerhalb Ihres Ziels für die Wiederherstellungszeit (RTO) zu halten.

Eine Transaktionsprotokollsicherung Zweck ist , um die Transaktionen zu einem beliebigen Zeitpunkt wiederholen zu lassen - oft, aber auf jeden Fall nicht unbedingt auf „die letzt etwas passieren“.

Worüber Sie sprechen, ist in der Tat möglich - Sie müssen jedoch die vollständige Sicherung und anschließend die Transaktionsprotokolle wiederherstellen.

Wenn Sie die vollständige Sicherung von Tag 1 und alle Transaktionsprotokollsicherungen zwischen Tag 1 und Tag 5 haben, hindert nichts Sie daran, die Sicherung von Tag 1 wiederherzustellen und das Transaktionsprotokoll erneut abzuspielen, bis Sie die Daten wie am Tag 4 erhalten haben Sie könnten auch mit dem Backup von Tag 2 beginnen, das sich etwas schneller wiederherstellen lässt, da Sie weniger Transaktionen wiedergeben würden. Sie können auch die vollständige Sicherung von Tag 1 und die differenzielle Sicherung von Tag 3 wiederherstellen und anschließend die Transaktionsprotokolle auf Tag 4 wiederherstellen.

Bearbeiten: OK, Ihre bearbeitete Analogie macht etwas mehr Sinn. Die Antwort lautet dann "weil Sie mit Transaktionsprotokollsicherungen bereits das erreichen können, was Sie wollen". Eine differenzielle Sicherung ist lediglich eine kostengünstige und bequeme Möglichkeit, eine ganze Reihe von Transaktionsprotokollaktivitäten aufzuzeichnen. Es bietet keine Granularität für die Datenwiederherstellung, die eine Transaktionsprotokollsicherung nicht bietet. Es gibt nur so viele Funktionen, die "nur Komfort" bieten und es zu einem Produkt machen.


Ich glaube, ich habe die Analogie vielleicht schlecht formuliert, standby für eine Bearbeitung ... sorry
elmer007

Bearbeitet für Ihre neue Analogie.
dpw

1

Eine Analogie zu Excel herzustellen, bedeutet, Äpfel und Orangen zu vergleichen. Warum ? Excel ist keine Datenbank, da die Datenintegrität fehlt. Excel ist eine schöne Tabellenkalkulationsanwendung und kann eine Ergänzung zur Datenbank sein.

SQL Server ist ein relationales Datenbanksystem, mit dem Sie alle Ihre Daten speichern und einen Mechanismus zum Abfragen bereitstellen können. Der wichtige Teil ist "relational", da die Datenbeziehung zusammen mit der Datenintegrität (ACID-Eigenschaften) wichtig ist.

Grundlagen:

Die Daten in der Datenbank sind in logische Komponenten (Tabellen, Ansichten, Prozesse, Trigger usw.) unterteilt, die für den Benutzer sichtbar sind. Zumindest wird eine Datenbank auch physisch als zwei (Daten- und Protokolldatei) oder mehr (sekundäre Datendatei) Dateien auf der Festplatte implementiert.

  • Eine Datenbank enthält eine Seite, die die grundlegende Einheit des Datenspeichers zum Speichern von Datensätzen darstellt .
  • Eine Datenbankseite ist ein 8192-Byte-Block (8 KB) einer Datenbankdatendatei.
  • 8 physikalisch zusammenhängende Seiten (8 * 8 KB = 64 KB) in einer Datenbankdatei bilden eine Ausdehnung .
  • Eine IAM-Seite (Index Allocation Map) zeichnet ungefähr 4 GB Speicherplatz in einer einzelnen Datei auf, die an einer 4 GB-Grenze ausgerichtet ist. Diese 4-GB-Blöcke werden als GAM-Intervalle bezeichnet .

Warum kann eine differenzielle Sicherung nur auf der neuesten vollständigen Sicherung basieren. - oder - Wenn sich bei einer differenziellen Sicherung alles seit der letzten vollständigen Sicherung geändert hat, warum kann die differenzielle Sicherung dann nicht auf einer Sicherung meiner Wahl basieren?

Basierend auf Ihrer Analogie zu Excel wenden Sie nur das an, was sich an ersterem geändert hat. Dies wendet alle festgeschriebenen Transaktionen aus dem Transaktionsprotokoll an with STOP AT(Hinweis: An Tag 5 kommt es zu einem Durcheinander der Datei, und Sie hören an Tag 4 auf).

In jedem 4-GB-Abschnitt (als GAM-Intervall bezeichnet) jeder Datendatei befindet sich eine spezielle Datenbankseite, die als differenzielles Bitmap bezeichnet wird und nachverfolgt , welche Teile (als Extents bezeichnet) dieses 4-GB-Abschnitts sich seit der letzten vollständigen Sicherung geändert haben wurde der Datenbank hinzugefügt.

Eine differenzielle Sicherung durchsucht diese Bitmaps und sichert nur die Datendateibereiche, die als geändert markiert sind. Die Bitmaps werden bei der nächsten vollständigen Sicherung zurückgesetzt (daher kann eine differenzielle Sicherung nur auf der neuesten vollständigen Sicherung basieren) . Sie können also feststellen, dass mehr und mehr Datenbankänderungen in den differenziellen Bitmaps markiert werden und aufeinanderfolgende differenzielle Sicherungen werden immer größer.

Mit diesem Skript können Sie sogar herausfinden, wie viel sich in der Datenbank seit der letzten vollständigen Sicherung geändert hat. .

Die differenziellen Basisinformationen werden in der masterDatenbank gespeichert - sys.database_fileoder ( sys.master_files- nützlich, wenn die Datenbank schreibgeschützt oder offline ist).

Es gibt 3 wichtige Spalten, in denen Informationen zur Differentialbasis gespeichert werden .

  • Dies differential_base_lsnist die Basis für differenzielle Sicherungen. Die Datenbereiche, die später geändert differential_base_lsnwerden, werden in die differenzielle Sicherung einbezogen.
  • Dies differential_base_guidist die eindeutige Kennung der Basissicherung, auf der eine differenzielle Sicherung basiert.
  • Das differential_base_timeist die Zeit, die entsprichtdifferential_base_lsn

Eine differenzielle Sicherung ist hilfreich, um die RTO (Recovery Time Objective = Zeit, die für die Wiederherstellung Ihrer Datenbank benötigt wird) zu beschleunigen, im Gegensatz zu häufigeren vollständigen Sicherungen, die bei großen Datenbanken oder bei der Wiederherstellung des Volumens von Transaktionsprotokollsicherungen ein Problem darstellen, da diese größer werden könnten im Zeitrahmen.

Hinweis: Durch eine vollständige COPY_ONLY-Sicherung wird die differenzielle Basis nicht zurückgesetzt, sodass eine COPY_ONLY-Sicherung nicht als differenzielle Basis dienen kann.

Verweise :



2
@ PaulSRandal schrieb Seiten existieren zum Speichern von Datensätzen. auf seinem blog und so habe ich ihn so wie er ist referenziert. Logische Referenzen aufzunehmen, was Sie erzählen (basierend auf der Referenz), ist ebenfalls wahr!
Kin Shah
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.