Backup and DR für Oracle auf einer Sicherungs-/Wiederherstellungs-Appliance

Die Oracle-Datenbank ist eine beliebte Datenbank der Enterprise-Klasse, die geschäftskritische Anwendungen unterstützt. Auf dieser Seite wird Backup and DR für Oracle-Datenbankumgebungen vorgestellt. Die zugehörige Architektur bietet anwendungskonsistente, inkrementelle Sicherungen für immer für Google Cloudsowie sofortige Wiederherstellung und Klonen für Oracle-Datenbanken mit mehreren Terabyte.

Funktionsweise

In den folgenden Abschnitten wird der Prozess der Datenerfassung und Datenwiederherstellung beschrieben.

Datenerfassung

  1. Der Backup and DR-Agent wird auf dem Oracle-Server bereitgestellt.

  2. Stellen Sie das Staging-Laufwerk auf dem Datenbankserver bereit.

  3. Rufen Sie die inkrementelle RMAN-API auf, um geänderte Blöcke zu kopieren.

  4. Rufen Sie RMAN Incremental Merge auf, um ein neues virtuelles Full-Backup zu erstellen.

  5. Staging-Festplatte vom Datenbankserver unmounten.

  6. Backup and DR erstellt einen internen Snapshot. Die synthetische vollständige Sicherung zu einem bestimmten Zeitpunkt ist bereit.

Datenwiederherstellung

Backup and DR stellt sofort ein beschreibbares Staging-Laufwerk über ISCSI oder NFS bereit und bringt die Datenbank online.

Oracle-Sicherungs-APIs

Backup and DR verwendet die folgenden Oracle-APIs:

  • RMAN-Image-Kopie: Eine Image-Kopie einer Datendatei lässt sich viel schneller wiederherstellen, da die physische Struktur der Datendatei bereits vorhanden ist. Mit der RMAN-Anweisung BACKUP AS COPY werden Image-Kopien für alle Datendateien der gesamten Datenbank erstellt und das Datendateiformat beibehalten.

  • ASM- und CRS-API: Die ASM-Sicherungs-Laufwerksgruppe wird mit der ASM- und CRS-API verwaltet.

  • RMAN-API für die Sicherung von Archivlogs: Generierte Archivlogs werden auf der Staging-Festplatte gesichert und aus dem Produktionsarchiv entfernt.

Konflikte bei der Verwendung von Backup und DR mit anderen Sicherungsprodukten minimieren

Backup and DR kann parallel zu Legacy-Produkten verwendet werden, die Daten aus Produktionsdatenbanken erfassen. Die folgenden Best Practices können Ihnen helfen, die Nutzung zu optimieren:

Zeitplan für Oracle-Datenbanksicherungen

Best Practice Planen Sie Backup- und DR-Datenbanksicherungsjobs so, dass sie zu einem Zeitpunkt beginnen, zu dem die alte Sicherungssoftware abgeschlossen sein sollte. Planen Sie die Ausführung der alten Sicherungssoftware nicht unmittelbar nach Abschluss eines Backup- und DR-Datenbanksicherungsjobs.
Begründung Wenn alte Sicherungsjobs und Backup and DR-Datenbanksicherungsjobs gleichzeitig ausgeführt werden, kann dies zu einer erheblichen Beeinträchtigung der Leistung des Datenbankservers führen, was zu Instabilität und möglicherweise zu einem Ausfall führen kann. Außerdem kann dies bei Oracle zu ungültigen Sicherungen für eine oder beide Lösungen führen.

Verwaltung von Oracle-Archivprotokollen

Oracle verwendet Archivprotokolle, die während einer Datenbanksicherung generiert werden, um die Konsistenz und Wiederherstellbarkeit dieser Sicherung zu gewährleisten. Wenn Archivierungsprotokolle während eines Datenbank-Sicherungsjobs gelöscht werden, kann diese Sicherungskopie nicht wiederhergestellt werden.

Anforderung Nur ein System kann Protokolle verwalten (erfassen und/oder kürzen/löschen), entweder die alte Sicherungssoftware oder Backup and DR.
Best Practice Lassen Sie nicht zu, dass Oracle-Archivprotokolle während eines Backup und DR-Jobs bereinigt werden, und lassen Sie nicht zu, dass Backup und DR Archivprotokolle während eines RMAN-Jobs für die alte Sicherung bereinigt.
Wenn die alte Software das Archivprotokoll verwaltet, deaktivieren Sie die Bereinigungsjobs für Archivprotokolle in der alten Sicherungssoftware zu Beginn des Backup und DR-Sicherungsjobs und setzen Sie die Bereinigungsjobs am Ende fort oder behalten Sie das Archivprotokoll mindestens 24 Stunden lang bei, bevor Sie es bereinigen.
Begründung Wenn Archivierungsprotokolle während eines Datenbank-Sicherungsjobs gelöscht werden, kann die Datenbank-Sicherung möglicherweise nicht wiederhergestellt werden.

RMAN-Metadaten stehen im Konflikt mit alten Sicherungen, wodurch Backup and DR-Sicherungen überflüssig werden

Standardmäßig ist der Parameter DO NOT UNCATALOG in den Anwendungsdetails und ‑einstellungen für Backup und DR auf Nein festgelegt. Eine Backup und DR-Datendateisicherung wird zu Beginn der Sicherung katalogisiert und am Ende des Jobs aus dem Katalog entfernt. Wenn Sie diese Option auf Ja setzen, wird die Sicherungszeit für Datenbanken mit einer großen Anzahl von Datendateien optimiert, indem der RMAN-Datendatei-Sicherungskatalog nach jedem Sicherungsjob katalogisiert wird. Allerdings beeinträchtigt es andere Sicherungsprodukte.

Anforderung Legen Sie den Parameter für die Anwendungsdetails und ‑einstellungen für Backup und DR Do not uncatalog auf Nein fest.
Best Practice Datenbanksicherungen in Backup and DR sind dauerhaft inkrementell. Dies wird durch die Verwendung von RMAN-Image-Kopien mit der RMAN-API für inkrementelles Zusammenführen erreicht. Die erste RMAN-Sicherung ist eine vollständige Imagekopie der Datenbankdatendatei auf der Backup- und DR-Sicherungsdisk mit internem Snapshot der Sicherungsdisk. Nachfolgende inkrementelle RMAN-Sicherungsvorgänge mit RMAN-Merge auf der Backup-Festplatte von Backup and DR aktualisieren die letzte vollständige Sicherung mit inkrementellen Änderungen vor dem Snapshot. Wenn jedoch nach der Backup- und DR-Datenbanksicherung eine Sicherung durch einen Drittanbieter oder ein Crosscheck von Sicherungsläufen erfolgt, werden alle Sicherungsdateien unter der Backup- und DR-Sicherung in den RMAN-Metadaten als veraltet markiert. Wenn der Parameter „Details und Einstellungen für Backup und DR-Anwendungen“ Do not uncatalog auf Ja gesetzt ist, führt dies zum folgenden Fehler: Imagekopien vom Staging-Gerät konnten nicht katalogisiert werden und zu einem Sicherungsfehler. Lassen Sie Do not uncatalog auf Nein eingestellt, damit es mit anderen alten Sicherungsprodukten verwendet werden kann.
Begründung Standardmäßig ist der Parameter Do not uncatalog> in Backup and DR application details & settings is set to No. Setting this to Yes interferes with other backup products.

Oracle-Datenbankblock-Änderungsnachverfolgung (Block Change Tracking, BCT)

Mit der Oracle-Blockänderungsnachverfolgung können Datenbanken schnell gesichert werden, da ermittelt wird, welche Blöcke sich geändert haben. Nur geänderte Blöcke werden in die Sicherung aufgenommen.

  • Die inkrementelle Sicherung von Backup und DR unterstützt Datenbanken, die mit aktivierter oder deaktivierter BCT ausgeführt werden. Wenn BCT nicht aktiviert ist, verlängert sich die Zeit für die inkrementelle Sicherung.

  • Die Änderungsblock-Erfassung ist auf Datenbankebene aktiviert.

  • Oracle zeichnet die geänderten Blöcke in jeder Datendatei in einer Tracking-Datei auf. Das ist eine kleine Binärdatei, die im Datenbankbereich gespeichert wird.

  • Wenn BCT aktiviert ist, verwendet RMAN die BCT-Datei, um die geänderten Blöcke für die inkrementelle Sicherung abzurufen.

  • RMAN scannt jeden Block in einer Datendatei für alle Datendateien in der Datenbank während der inkrementellen Sicherung, wenn die Änderungsblockverfolgung für die Datenbank nicht aktiviert ist.

Oracle-Datenbanken in einer Backup und DR-Konsistenzgruppe schützen

In den meisten Konfigurationen kann eine Konsistenzgruppe eine einzelne Oracle-Datenbankanwendung und eine beliebige Anzahl von Dateisystemanwendungen vom Oracle-Server enthalten. Eine Konsistenzgruppe ist die empfohlene Option für Oracle-Datenbanken in Test- und Entwicklungs- sowie anderen Anwendungsfällen für geschäftliche Agilität.

Oracle-Datenbanken mit TDE

Backup and DR unterstützt eine Vielzahl von Erfassungs- und Präsentationsmethoden für Oracle-Datenbanken in verschiedenen Konfigurationen. Dazu gehören Sicherungs-, Wiederherstellungs- und anwendungsbezogene Mount-Vorgänge von Oracle-Datenbanken, für die Transparent Data Encryption (TDE) konfiguriert ist.

Bei Oracle-Datenbanken mit TDE müssen Wallet-Dateien vom Quellsicherungshost für den Zielhost aller anwendungsbezogenen Mounts verfügbar sein. Dafür gibt es mehrere Möglichkeiten.

  • Die Wallet-Dateien können vom Sicherungsquellserver auf den Ziel-Mount-Server kopiert und Oracle für den Zugriff auf sie konfiguriert werden.
  • Wenn die Oracle-Wallet-Dateien auf einem zentralen, gemeinsam verwendeten Gerät im Netzwerk gespeichert sind, muss die Appaware-Bereitstellungsziel-Oracle-Instanz so konfiguriert werden, dass sie darauf zugreifen kann.

  • Wenn die Oracle-Wallet-Dateien während der Backup- und DR-Sicherung erfasst wurden, indem die erweiterte Einstellung „Speicherort der Oracle-Konfigurationsdatei“ festgelegt wurde, können die Wallet-Dateien mit den folgenden Schritten abgerufen werden:

    1. Führen Sie eine Standardbereitstellung der Datenbank auf dem Zielhost durch.
    2. Kopieren Sie die Wallet-Dateien vom Standard-Datenbankmount auf den Zielhost und konfigurieren Sie Oracle für die Verwendung dieser Dateien.
    3. Heben Sie die Bereitstellung der Datenbank auf dem Zielhost auf.
    4. Führen Sie eine anwendungsbezogene Bereitstellung der Datenbank auf dem Zielhost durch.

Backup und DR mit Oracle Exadata-Datenbank oder Oracle ExaCC

Sicherungs-/Wiederherstellungs-Appliances unterstützen das Erfassen und Präsentieren von Exadata-Daten über iSCSI- oder Oracle dNFS-Protokolle.

  • Die Sicherungs-/Wiederherstellungs-Appliance ist über iSCSI oder Oracle dNFS mit dem Netzwerk verbunden (nicht im Datenpfad).

  • Bei der RMAN-Sicherung wird RMAN verwendet, um direkt in einen Kopie-Datenspeicher zu schreiben, der von Backup and DR als Dateisystem oder als ASM-Festplattengruppe dargestellt wird.

  • Formate für die Datenerfassung: unter ASM-Laufwerksgruppe (nur iSCSI) oder unter Dateisystem (dNFS oder iSCSI).

  • Bei der inkrementellen Sicherung von Backup and DR werden RMAN-Sicherungen verwendet, die inkrementell aktualisiert werden, wobei Image-Copy-Sicherungen fortlaufend aktualisiert werden.

Backup and DR-Erfassung von Exadata-Daten und ExaCC

Der Backup and DR-Agent muss auf dem Exadata-Server installiert sein, um die Kommunikation mit der Sicherungs-/Wiederherstellungs-Appliance zu ermöglichen und die RMAN API für die Datenbanksicherung aufzurufen.

Der Backup and DR-Agent stellt Backup and DR-Festplatten auf dem Exadata-Server als iSCSI-Ziel bereit und ordnet sie zu. Das Datenerfassungsformat kann sich unter ASM-Laufwerksgruppe oder im Dateisystem befinden.

Installieren Sie den Backup and DR-Agent auf jedem Exadata-Host im Nutzerbereich, um die Kommunikation mit der Sicherungs-/Wiederherstellungs-Appliance zu ermöglichen und die RMAN-API für die Datenbanksicherung aufzurufen.

Erfassungsformat unter ASM-Laufwerksgruppe

Während einer Sicherung führt der Backup and DR-Agent folgende Aktionen aus:

  1. Ordnen Sie die logische Festplatte dem Exadata-Server als iSCSI-Ziel zu und stellen Sie sie bereit.

  2. Fügen Sie den Pfad des Backup and DR-Laufwerks dem ASM-Laufwerkstring hinzu.

  3. Prüfen Sie, ob der ASM-Datenträgerstring der Parameterdatei hinzugefügt wurde und nicht im CRS-Profil vorhanden ist.

  4. Erstellen Sie eine ASM-Laufwerksgruppe als externe Redundanz mit einem Backup and DR-Laufwerk.

    • RMAN-Sicherung mit RMAN zum direkten Schreiben in einen Kopierdatenspeicher, der von der Sicherungs-/Wiederherstellungs-Appliance als ASM-Laufwerksgruppe oder als Dateisystem bereitgestellt wird.

    • Dauerhaft inkrementelle Sicherung mit inkrementell aktualisierten RMAN-Sicherungen, die Image-Copy-Sicherungen vorwärts rollen.

Erfassungsformat im Dateisystem mit dNFS

Oracle Direct NFS (dNFS) ist ein optimierter NFS-Client (Network File System), der einen schnelleren und besser skalierbaren Zugriff auf NFS-Speicher auf NAS-Speichergeräten (über TCP/IP zugänglich) ermöglicht. Direct NFS ist wie ASM direkt in den Datenbankkernel integriert.

Das dNFS-Protokoll kann für die dateisystembasierte Sicherung als NFS-Freigabe verwendet werden.

Der Backup and DR-Agent stellt Backup and DR-Festplatten als NFS-Freigabe auf dem Exadata-Server bereit und ordnet sie zu.

Voraussetzungen für dNFS auf Exadata-Server:

  • dNFS auf dem Exadata-Server aktivieren:

    cd $ORACLE_HOME/rdbms/lib make -f ins_rdbms.mk nfs on

  • Starten Sie die Datenbank neu.

    Verwenden Sie die RMAN API, um die Datenbank im Dateisystem auf der dNFS-Freigabe zu sichern, die von der Sicherungs-/Wiederherstellungs-Appliance bereitgestellt wird.

Durch Backup and DR geschützte ASM-Festplattengruppen nach dem Neustart eines Zieldatenbankservers wieder online schalten

Nach einem Neustart des Datenbankservers, bei dem die Backup- und DR-Kopie eingebunden ist, oder wenn Backup- und DR-Sicherungen für die Datenbank zum Zeitpunkt des Neustarts/Absturzes ausgeführt werden, gehen Sie so vor, um die Einbindung der Backup- und DR-Festplattengruppe wiederherzustellen:

  1. Prüfen Sie, ob der Zieldatenbankserver wieder betriebsbereit ist und ob auch ASM und das RAC-System betriebsbereit sind.

  2. Starten Sie den Backup and DR-Agent neu (über das Stammverzeichnis).

  3. ASM-Umgebung festlegen

  4. Melden Sie sich bei ASM sqlplus an und prüfen Sie den Status der Datenträgergruppe:

    select name, state from v$asm_diskgroup where name = '<dg name>';)

  5. Wenn die Bereitstellung aufgehoben wurde, stellen Sie die Laufwerksgruppe bereit: alter diskgroup <dg name> mount;

  6. Melden Sie sich beim Oracle-Betriebssystem an, legen Sie die Datenbankumgebung fest und starten Sie dann die Datenbank.

Nächste Schritte

Voraussetzungen für das Sichern einer Oracle-Datenbank

Weitere Dokumentation zu Backup und DR für Oracle