Das einfachste Layout ist in der folgenden Abbildung dargestellt.

Dies ist der häufigste Ansatz. Aus der Perspektive eines DBAs mag es ungewöhnlich erscheinen, alle Kopien der Wiederherstellungs- und Archivprotokolle auf demselben Volume zu vermengen. Allerdings bietet Trennung keinen besonderen Schutz, wenn die Dateien und LUNs sich alle noch auf derselben zugrunde liegenden Laufwerkgruppe befinden.

Gelegentlich ist eine Trennung von Wiederherstellungsprotokollen erforderlich, da Bedenken hinsichtlich der Datensicherung bestehen oder Redo-Log-I/O über Controller verteilt werden müssen. In diesem Fall wird das in der Abbildung unten abgebildete Layout mit drei Volumes für die Replikation verwendet, während gleichzeitig die Notwendigkeit einer unvollständigen Wiederherstellung vermieden oder auf Backup-Controller-Dateien angewiesen ist.

Dies ermöglicht das Striping der Redo-Protokolle und Steuerdateien über unabhängige Sätze von Spindeln und Controllern auf der Quelle. Die Archivprotokolle und ein Satz von Steuerdateien und Wiederherstellungsprotokollen können jedoch weiterhin in einem synchronisierten Zustand mit den Archivprotokollen repliziert werden.

In diesem Modell wird das Redo-Protokoll-B-Volume nicht repliziert.

Gehen Sie wie folgt vor, um eine Disaster Recovery mithilfe von Hot Backups durchzuführen:

Die Wiederherstellung von Snapshot-optimierten Backups ist mit dem Hot-Backup-Recovery-Verfahren mit den folgenden Änderungen fast identisch:

Diese Unterschiede vereinfachen das gesamte Recovery-Verfahren, da nicht sichergestellt werden muss, dass ein Snapshot ordnungsgemäß auf der Quelle erstellt wurde, während sich die Datenbank im Hot Backup-Modus befand. Das Disaster-Recovery-Verfahren basiert auf den Zeitstempeln der Snapshots auf dem Disaster-Recovery-Standort. Der Zustand der Datenbank, zu dem die Snapshots erstellt wurden, ist nicht wichtig.

Dies ist ein Beispiel für eine Disaster-Recovery-Strategie, die auf der Replizierung von Hot-Backup-Snapshots basiert. Er ist auch ein Beispiel für eine einfache und skalierbare lokale Backup-Strategie.

Die Beispieldatenbank befindet sich in einer grundlegenden Architektur mit zwei Volumes. /oradata Enthält Datendateien und /oralogs Wird für kombinierte Redo-Logs, Archivprotokolle und Steuerdateien verwendet.

Es sind zwei Zeitpläne erforderlich, einer für die nächtlichen Datendatei-Backups und einer für die Protokolldatei-Backups. Diese werden Mitternacht bzw. 15 Minuten genannt.

Diese Zeitpläne werden dann innerhalb der Snapshot-Richtlinien verwendet NTAP-datafile-backups Und NTAP-log-backups, Wie unten gezeigt:

Diese Snapshot-Richtlinien werden schließlich auf die Volumes angewendet.

Dadurch wird der Backup-Zeitplan der Volumes definiert. Datendatei-Snapshots werden um Mitternacht erstellt und für 60 Tage aufbewahrt. Das Protokollvolumen enthält 72 Snapshots, die in 15-Minuten-Intervallen erstellt wurden, was bis zu 18 Stunden Abdeckung ergibt.

Stellen Sie dann sicher, dass sich die Datenbank im Hot-Backup-Modus befindet, wenn ein Datendatei-Snapshot erstellt wird. Dies wird mit einem kleinen Skript gemacht, das einige grundlegende Argumente akzeptiert, die den Backup-Modus auf der angegebenen SID starten und stoppen.

Dieser Schritt stellt sicher, dass sich die Datenbank während eines vierminütigen Fensters um den Mitternacht-Snapshot im Hot Backup-Modus befindet.

Die Replikation zum Disaster Recovery-Standort ist wie folgt konfiguriert:

Das Ziel des Protokollvolumes wird alle 15 Minuten aktualisiert. Somit wird eine RPO von etwa 15 Minuten erzielt. Das genaue Update-Intervall variiert ein wenig abhängig vom Gesamtvolumen der Daten, die während der Aktualisierung übertragen werden müssen.

Das Ziel des Datendatei-Volumes wird alle sechs Stunden aktualisiert. Dies hat keine Auswirkung auf RPO oder RTO. Wenn eine Disaster-Recovery erforderlich ist, besteht einer der ersten Schritte darin, das Datendateivolume wieder auf einen Hot-Backup-Snapshot wiederherzustellen. Der Zweck des häufigeren Aktualisierungsintervalls besteht darin, die Übertragungsrate dieses Volumens zu glätten. Wenn die Aktualisierung einmal pro Tag geplant ist, müssen alle Änderungen, die während des Tages angesammelt wurden, gleichzeitig übertragen werden. Bei häufigeren Updates werden die Änderungen schrittweise im Laufe des Tages repliziert.

Im Falle eines Ausfalls besteht der erste Schritt darin, die Spiegelungen für beide Volumes zu unterbrechen:

Die Replikate sind jetzt Lese-/Schreibzugriff. Im nächsten Schritt wird der Zeitstempel des Protokoll-Volumes überprüft.

Die neueste Kopie des Logvolumens ist der 14. März um 13:30:00.

Identifizieren Sie als Nächstes den Hot-Backup-Snapshot, der unmittelbar vor dem Status des Protokollvolumes erstellt wurde. Dies ist erforderlich, da die Protokollwiedergabe alle Archivprotokolle erfordert, die im Hot Backup-Modus erstellt wurden. Das Replikat des Protokollvolumes muss daher älter als die Hot-Backup-Images sein, da sonst die erforderlichen Protokolle nicht enthalten wären.

Der zuletzt erstellte Snapshot ist midnight.2017-03-14_0000. Hierbei handelt es sich um das neueste Hot-Backup-Image der Datendateien, das wie folgt wiederhergestellt wird:

In dieser Phase kann die Datenbank nun wiederhergestellt werden. Wenn es sich um eine SAN-Umgebung handelt, würde der nächste Schritt die Aktivierung von Volume-Gruppen und das Mounten von Dateisystemen umfassen, ein einfach automatisierter Prozess. Da in diesem Beispiel NFS verwendet wird, sind die Dateisysteme bereits gemountet und wurden in Schreib- und Lesezugriff eingebunden, ohne dass in dem Moment, in dem die Spiegelungen beschädigt wurden, eine weitere Bereitstellung oder Aktivierung erforderlich war.

Die Datenbank kann jetzt bis zum gewünschten Zeitpunkt wiederhergestellt werden, oder sie kann in Bezug auf die Kopie der replizierten Wiederherstellungsprotokolle vollständig wiederhergestellt werden. Dieses Beispiel zeigt den Wert des kombinierten Archivprotokolls, der Steuerdatei und des Wiederherstellungsprotokolls. Der Recovery-Prozess ist drastisch einfacher, da es keine Notwendigkeit, auf Backup-Steuerdateien oder Reset-Protokolldateien verlassen.

Der Disaster-Recovery-Vorgang mithilfe von Snapshot optimierten Backups ist nahezu identisch mit dem Disaster-Recovery-Verfahren für Hot Backups. Wie beim Hot Backup Snapshot Verfahren ist es auch im Grunde eine Erweiterung einer lokalen Backup-Architektur, in der die Backups für die Disaster Recovery repliziert werden. Das folgende Beispiel zeigt das detaillierte Konfigurations- und Wiederherstellungsverfahren. Dieses Beispiel nennt auch die wichtigsten Unterschiede zwischen Hot Backups und Snapshot optimierten Backups.

Die Beispieldatenbank befindet sich in einer grundlegenden Architektur mit zwei Volumes. /oradata Enthält Datendateien, und /oralogs Wird für kombinierte Redo-Logs, Archivprotokolle und Steuerdateien verwendet.

Es sind zwei Zeitpläne erforderlich: Eine für die nächtlichen Datendatei-Backups und eine für die Protokolldatei-Backups. Diese werden Mitternacht bzw. 15 Minuten genannt.

Diese Zeitpläne werden dann innerhalb der Snapshot-Richtlinien verwendet NTAP-datafile-backups Und NTAP-log-backups, Wie unten gezeigt:

Diese Snapshot-Richtlinien werden schließlich auf die Volumes angewendet.

Dadurch wird der ultimative Backup-Plan der Volumes gesteuert. Snapshots werden um Mitternacht erstellt und 60 Tage aufbewahrt. Das Protokollvolumen enthält 72 Snapshots, die in 15-Minuten-Intervallen erstellt wurden, was bis zu 18 Stunden Abdeckung ergibt.

Die Replikation zum Disaster Recovery-Standort ist wie folgt konfiguriert:

Das Ziel des Protokollvolumes wird alle 15 Minuten aktualisiert. Dadurch wird ein RPO von ca. 15 Minuten erreicht, wobei das genaue Update-Intervall etwas variiert, je nach dem Gesamtvolumen der Daten, die während der Aktualisierung übertragen werden müssen.

Das Datendatei-Volume-Ziel wird alle 6 Stunden aktualisiert. Dies hat keine Auswirkung auf RPO oder RTO. Wenn eine Disaster Recovery erforderlich ist, müssen Sie das Datendatei-Volume zunächst auf einem Hot-Backup-Snapshot wiederherstellen. Der Zweck des häufigeren Aktualisierungsintervalls besteht darin, die Übertragungsrate dieses Volumens zu glätten. Wenn die Aktualisierung einmal pro Tag geplant wurde, müssen alle Änderungen, die sich während des Tages angesammelt haben, gleichzeitig übertragen werden. Bei häufigeren Updates werden die Änderungen schrittweise im Laufe des Tages repliziert.

Im Falle eines Ausfalls besteht der erste Schritt darin, die Spiegelungen für alle Volumes zu unterbrechen:

Die Replikate sind jetzt Lese-/Schreibzugriff. Im nächsten Schritt wird der Zeitstempel des Protokoll-Volumes überprüft.

Die neueste Kopie des Logvolumens ist der 14. März um 13:30. Identifizieren Sie als nächstes den Datendatei-Snapshot, der unmittelbar vor dem Status des Protokoll-Volumes erstellt wurde. Dies ist erforderlich, da für die Protokollwiedergabe alle Archivprotokolle von kurz vor dem Snapshot zum gewünschten Wiederherstellungspunkt erforderlich sind.

Der zuletzt erstellte Snapshot ist midnight.2017-03-14_0000. Diesen Snapshot wiederherstellen.

Die Datenbank kann nun wiederhergestellt werden. Wenn es sich um eine SAN-Umgebung handelt, würden Sie dann Volume-Gruppen aktivieren und Filesysteme mounten, ein einfach automatisierter Prozess. In diesem Beispiel wird jedoch NFS verwendet, d. h. die Dateisysteme sind bereits gemountet und wurden in Lese- und Schreibzugriff überführt. In dem Moment, in dem die Spiegelungen beschädigt wurden, ist keine weitere Bereitstellung oder Aktivierung erforderlich.

Die Datenbank kann jetzt bis zum gewünschten Zeitpunkt wiederhergestellt werden, oder sie kann in Bezug auf die Kopie der replizierten Wiederherstellungsprotokolle vollständig wiederhergestellt werden. Dieses Beispiel zeigt den Wert des kombinierten Archivprotokolls, der Steuerdatei und des Wiederherstellungsprotokolls. Der Wiederherstellungsvorgang ist wesentlich einfacher, da keine Notwendigkeit besteht, sich auf Backup-Steuerdateien oder Reset-Protokolldateien zu verlassen.