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

Oracle Database ist eine beliebte Datenbank der Enterprise-Klasse, die geschäftskritische Anwendungen unterstützt. Auf dieser Seite wird Backup und DR für Oracle-Datenbankumgebungen vorgestellt. Die zugehörige Architektur bietet anwendungskonsistente, inkrementelle Sicherungen in 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- und DR-Agent wird auf dem Oracle-Server bereitgestellt.

  2. Staging-Laufwerk auf dem Datenbankserver bereitstellen.

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

  4. Rufen Sie die inkrementelle RMAN-Zusammenführung auf, um eine neue virtuelle vollständige Sicherung zu erstellen.

  5. Staging-Laufwerk vom Datenbankserver entfernen.

  6. Backup und DR erstellt einen internen Snapshot. Die synthetische Vollsicherung zu einem bestimmten Zeitpunkt ist bereit.

Datenwiederherstellung

Backup und DR stellt sofort ein wiederbeschreibbares Staging-Laufwerk über ISCSI oder NFS bereit und schaltet die Datenbank online.

Oracle-Sicherungs-APIs

Backup und 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. Die RMAN-Anweisung BACKUP AS COPY erstellt Image-Kopien für alle Datendateien der gesamten Datenbank und behält das Datendateiformat bei.

  • ASM- und CRS-API: Die ASM-Sicherungslaufwerksgruppe wird über die ASM- und CRS-API verwaltet.

  • RMAN-Archivprotokoll-Sicherungs-API: Generierte Archivprotokolle werden auf dem Staging-Laufwerk gesichert und aus dem Produktionsarchivspeicherort gelöscht.

Konflikte minimieren, wenn Sie Backup und DR mit anderen Sicherungsprodukten verwenden

Backup und DR können mit Legacy-Produkten koexistieren, die Daten aus Produktionsdatenbanken erfassen. Die folgenden Best Practices können Ihnen helfen, die Nutzung zu verbessern:

Zeitplan für die Sicherung der Oracle-Datenbank

Best Practice Planen Sie die Sicherungsjobs für die Backup- und DR-Datenbank so, dass sie zu einem Zeitpunkt beginnen, an dem die Legacy-Sicherungssoftware fertig sein sollte. Planen Sie die Ausführung der Legacy-Sicherungssoftware nicht unmittelbar nach dem normalen Abschluss eines Backup- und DR-Datenbanksicherungsjobs.
Grund Wenn Legacy-Sicherungsjobs und Sicherungsjobs für Datenbanken von Backup und DR gleichzeitig ausgeführt werden, kann dies zu erheblichen Leistungseinbußen auf dem Datenbankserver 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-Archivlogs

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

Anforderung Logs können nur von einem System verwaltet (erfasst und/oder gekürzt/gelöscht) werden, entweder von der Legacy-Sicherungssoftware oder von Backup und DR.
Best Practice Lassen Sie nicht zu, dass Oracle-Archivlogs während eines Backup- und DR-Jobs gelöscht werden, und lassen Sie nicht zu, dass Backup und DR Archivlogs während eines Legacy-Backup-RMAN-Jobs löschen.
Wenn die Legacy-Software das Archivlog verwaltet, deaktivieren Sie die Jobs zum Löschen von Archivlogs in der Legacy-Backup-Software zu Beginn des Backup- und DR-Backup-Jobs und setzen Sie die Löschjobs am Ende fort oder bewahren Sie das Archivlog mindestens 24 Stunden lang auf, bevor Sie es löschen.
Grund Wenn Archivlogs während eines Datenbanksicherungsjobs gelöscht werden, kann diese Datenbanksicherung möglicherweise nicht wiederhergestellt werden.

RMAN-Metadatenkonflikt mit Legacy-Sicherungen, die Backup und DR-Sicherungen überflüssig machen

Standardmäßig ist der Parameter DO NOT UNCATALOG in den Anwendungsdetails und -einstellungen für Backup und DR auf Nein festgelegt. Eine Sicherung von Backup- und DR-Datendateien 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, da die RMAN-Datendateisicherung nach jedem Sicherungsjob katalogisiert bleibt. Es beeinträchtigt jedoch andere Sicherungsprodukte.

Anforderung Legen Sie den Parameter Do not uncatalog für die Details und Einstellungen der Backup und DR-Anwendung auf Nein fest.
Best Practice Datenbanksicherungen mit Backup und DR sind inkrementell und dauerhaft. Dies wird durch die Verwendung einer RMAN-Image-Kopie mit der RMAN-API für inkrementelle Zusammenführungen erreicht. Die erste RMAN-Sicherung ist eine vollständige Image-Kopie der Datenbank-Datendatei auf dem Backup und DR-Sicherungslaufwerk mit einem internen Snapshot des Sicherungslaufwerks. Nachfolgende inkrementelle RMAN-Sicherungsläufe mit inkrementeller RMAN-Zusammenführung auf dem Backup und DR-Sicherungslaufwerk, wobei die letzte Vollsicherung vor dem Snapshot mit inkrementellen Änderungen aktualisiert wird. Wenn jedoch nach der Datenbanksicherung von Backup und DR eine Datenbanksicherung eines Drittanbieters oder eine Überprüfung der Sicherung ausgeführt wird, werden alle Sicherungsdatendateien unter der Sicherung von Backup und DR in den RMAN-Metadaten als veraltet markiert. Wenn der Parameter Do not uncatalog für die Details und Einstellungen der Backup und DR-Anwendung auf Ja gesetzt ist, tritt der folgende Fehler auf: Image-Kopien vom Staging-Gerät konnten nicht katalogisiert werden und die Sicherung schlägt fehl. Lassen Sie Do not uncatalog auf Nein festgelegt, damit andere ältere Sicherungsprodukte gleichzeitig verwendet werden können.
Grund 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-Datenbank-Blockänderungsverfolgung (BCT)

Mit der Oracle-Blockänderungsverfolgung können schnelle Datenbanksicherungen erstellt werden, da erkannt wird, welche Blöcke sich geändert haben. Nur geänderte Blöcke werden in den Sicherungsvorgang einbezogen.

  • Backup und DR mit inkrementeller Sicherung unterstützt Datenbanken, die mit aktiviertem oder deaktiviertem BCT ausgeführt werden. Wenn BCT nicht aktiviert ist, erhöht sich die Zeit für die inkrementelle Sicherung.

  • Die Änderungsblockverfolgung ist auf Datenbankebene aktiviert.

  • Oracle zeichnet die geänderten Blöcke in jeder Datendatei in einer Tracking-Datei auf. Dies 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 Wahl für Oracle-Datenbanken in Test-Dev- und anderen geschäftlichen Agilitätsanwendungsfällen.

Oracle-Datenbanken mit TDE

Backup und DR unterstützt eine Vielzahl von Erfassungs- und Präsentationsmethoden für Oracle-Datenbanken in verschiedenen Konfigurationen. Dazu gehören Sicherungs-, Wiederherstellungs- und anwendungsspezifische Bereitstellungsvorgänge der Oracle-Datenbank mit konfigurierter transparenter Datenverschlüsselung (Transparent Data Encryption, TDE).

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

  • Die Wallet-Dateien können vom Sicherungsquellserver auf den Ziel-Mount-Server kopiert werden. Oracle kann dann so konfiguriert werden, dass darauf zugegriffen werden kann.
  • Wenn die Oracle-Wallet-Dateien auf einem zentralen, freigegebenen Gerät im Netzwerk gespeichert sind, sollte die Oracle-Instanz des Appaware-Bereitstellungsziels so konfiguriert werden, dass sie darauf zugreifen kann.

  • Wenn die Oracle-Wallet-Dateien während der Sicherung mit Backup und DR durch Festlegen der erweiterten Einstellung „Speicherort der Oracle-Konfigurationsdatei“ erfasst wurden, 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 aus der Standarddatenbank-Bereitstellung auf den Zielhost und konfigurieren Sie Oracle so, dass diese verwendet werden.
    3. Heben Sie die Bereitstellung der Datenbank auf dem Zielhost auf.
    4. Führen Sie eine anwendungsspezifische Bereitstellung der Datenbank auf dem Zielhost durch.

Backup und DR mit Oracle Exadata-Datenbank oder Oracle ExaCC

Sicherungs-/Wiederherstellungs-Appliances unterstützen die Erfassung und Darstellung von Exadata-Daten über iSCSI- oder Oracle dNFS-Protokolle.

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

  • Bei der RMAN-Sicherung wird RMAN verwendet, um direkt in einen Kopiedatenspeicher zu schreiben, der von Backup und DR als Dateisystem oder als ASM-Laufwerksgruppe dargestellt wird.

  • Datenerfassungsformate: unter ASM-Laufwerksgruppe (nur iSCSI) oder unter Dateisystem (dNFS oder iSCSI).

  • Für die inkrementelle Sicherung von Backup und DR werden inkrementell aktualisierte RMAN-Sicherungen verwendet, wobei Image-Kopien-Sicherungen weitergeführt werden.

Backup und DR-Erfassung von Exadata-Daten und ExaCC

Der Backup und 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 und DR-Agent stellt Backup und DR-Laufwerke bereit und ordnet sie dem Exadata-Server als iSCSI-Ziel zu. Das Datenerfassungsformat kann unter ASM-Laufwerksgruppe oder unter Dateisystem angegeben werden.

Installieren Sie den Backup und DR-Agenten 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 und DR-Agent Folgendes aus:

  1. Ordnen Sie das logische Laufwerk dem Exadata-Server als iSCSI-Ziel zu und stellen Sie es bereit.

  2. Fügen Sie den Backup und DR-Laufwerkspfad zum ASM-Laufwerksstring hinzu.

  3. Achten Sie darauf, dass der ASM-Laufwerkstring der Parameterdatei hinzugefügt wurde und nicht im CRS-Profil vorhanden ist.

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

    • RMAN-Sicherung mit RMAN, um direkt in einen Kopierdatenspeicher zu schreiben, der von der Sicherungs-/Wiederherstellungs-Appliance als ASM-Laufwerksgruppe oder als Dateisystem bereitgestellt wird.

    • Dauerhaft inkrementelle Sicherung mit inkrementell aktualisierten RMAN-Sicherungen, wobei Image-Kopien-Sicherungen vorwärtsgerollt werden.

Erfassungsformat im Dateisystem mit dNFS

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

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

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

Voraussetzungen für dNFS auf dem Exadata-Server:

  • Aktivieren Sie dNFS auf dem Exadata-Server:

    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 in einem Dateisystem auf einer dNFS-Freigabe zu sichern, die von der Sicherungs-/Wiederherstellungs-Appliance bereitgestellt wird.

Backup and DR-geschützte ASM-Laufwerksgruppen nach dem Neustart eines Ziel-DB-Servers wieder online schalten

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

  1. Prüfen Sie, ob der Zieldatenbankserver wieder verfügbar ist und ob das ASM- und das RAC-System ebenfalls verfügbar sind.

  2. Starten Sie den Backup und DR-Agenten (vom Root-Verzeichnis aus) neu.

  3. ASM-Umgebung festlegen

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

    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