Oracle Database ist eine beliebte Datenbank der Enterprise-Klasse, die geschäftskritische Anwendungen unterstützt. Auf dieser Seite wird der Sicherungs- und Notfallwiederherstellungsdienst für Oracle-Datenbankumgebungen vorgestellt. Die zugehörige Architektur bietet ein anwendungskonsistentes, inkrementelles, dauerhaftes Back-up in Google Cloudsowie eine sofortige Wiederherstellung und Klonung für Oracle-Datenbanken mit mehreren Terabyte.
So funktioniert es
In den folgenden Abschnitten werden die Datenerfassung und -wiederherstellung beschrieben.
Datenerfassung
Der Sicherungs- und Notfallwiederherstellungs-Agent wird auf dem Oracle-Server bereitgestellt.
Staging-Laufwerk auf dem Datenbankserver bereitstellen.
RMAN-Inkrementelle API aufrufen, um geänderte Blöcke zu kopieren.
Rufen Sie die inkrementelle Zusammenführung von RMAN auf, um eine neue virtuelle Vollsicherung zu erstellen.
Trennen Sie das Staging-Laufwerk vom Datenbankserver.
Für die Sicherung und Notfallwiederherstellung wird ein interner Snapshot erstellt. Die Punkt-in-Zeit-Synthetik-Daten sind verfügbar.
Datenwiederherstellung
Sicherung und Notfallwiederherstellung stellen sofort ein über ISCSI oder NFS wiederbeschreibbares Staging-Laufwerk bereit und stellen die Datenbank online.
Oracle-Sicherungs-APIs
Für Sicherungen und Notfallwiederherstellungen werden die folgenden Oracle APIs verwendet:
RMAN-Image-Kopie: Die Wiederherstellung einer Image-Kopie einer Datendatei ist viel schneller, da die physische Struktur der Datendatei bereits vorhanden ist. Mit der RMAN-Direktive BACKUP AS COPY werden Sicherungskopien für alle Datendateien der gesamten Datenbank erstellt und das Datendateiformat beibehalten.
ASM- und CRS-API: Die ASM-Sicherungslaufwerksgruppe wird mit der ASM- und CRS-API verwaltet.
RMAN-Archivlog-Sicherungs-API: Generierte Archivlogs werden auf dem Staging-Laufwerk gesichert und aus dem Produktionsarchiv gelöscht.
Konflikte bei der Verwendung des Sicherungs- und Notfallwiederherstellungsdienstes mit anderen Sicherungsprodukten minimieren
Der Sicherungs- und Notfallwiederherstellungsdienst kann mit Legacy-Produkten koexistieren, die Daten aus Produktionsdatenbanken erfassen. Mit den folgenden Best Practices können Sie die Nutzung verbessern:
Zeitplan für die Sicherung der Oracle-Datenbank
Best Practices | Planen Sie Datenbanksicherungsjobs für den Backup- und DR-Dienst so, dass sie zu einer Zeit beginnen, zu der die Sicherung mit der bisherigen Sicherungssoftware abgeschlossen sein sollte. Planen Sie die Ausführung der alten Sicherungssoftware nicht direkt nach Abschluss eines Datenbanksicherungsjobs des Sicherungs- und Notfallwiederherstellungsdienstes. |
Grund | Wenn alte Sicherungsjobs und Datenbanksicherungsjobs des Sicherungs- und Notfallwiederherstellungsdiensts 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. Bei Oracle kann dies außerdem zu ungültigen Sicherungs-Images für eine oder beide Lösungen führen. |
Oracle-Archivlogverwaltung
Oracle verwendet Archiv-Logs, die bei einer Datenbanksicherung generiert werden, um für die Konsistenz und Wiederherstellbarkeit dieser Sicherung zu sorgen. Wenn also Archivprotokolle während eines Datenbanksicherungsjobs gelöscht werden, kann diese Sicherungskopie nicht wiederhergestellt werden.
Anforderung | Protokolle können nur von einem System verwaltet (aufgezeichnet und/oder abgeschnitten/gelöscht) werden, entweder von der bisherigen Sicherungssoftware oder vom Backup- und DR-Dienst. |
Best Practice | Oracle-Archivlogs dürfen während eines Sicherungs- und Notfallwiederherstellungsjobs nicht gelöscht werden. Außerdem darf der Sicherungs- und Notfallwiederherstellungsdienst Archivlogs nicht während eines alten RMAN-Sicherungsjobs löschen. Wenn die alte Software das Archivlog verwaltet, deaktivieren Sie zu Beginn des Sicherungs- und Notfallwiederherstellungsjobs die Jobs zum Löschen des Archivlogs in der alten Sicherungssoftware und setzen Sie die Löschjobs am Ende fort oder bewahren Sie das Archivlog mindestens 24 Stunden vor dem Löschen auf. |
Grund | Wenn Archivprotokolle während eines Datenbanksicherungsjobs gelöscht werden, kann das Sicherungsimage der Datenbank möglicherweise nicht wiederhergestellt werden. |
RMAN-Metadatenkonflikt mit älteren Sicherungen, wodurch Sicherungen des Backup- und DR-Dienstes obsolet werden
Standardmäßig ist der Parameter DO NOT UNCATALOG
in den Anwendungsdetails und -einstellungen des Sicherungs- und Notfallwiederherstellungsdienstes auf Nein festgelegt. Eine Sicherungsdatei des Sicherungs- und Notfallwiederherstellungsdienstes wird zu Beginn der Sicherung katalogisiert und am Ende des Jobs wieder dekatalogisiert. Wenn Sie diese Option auf Ja festlegen, wird die Sicherungszeit für Datenbanken mit einer großen Anzahl von Datendateien optimiert, da die RMAN-Datendateisicherung nach jedem Sicherungsjob katalogisiert wird. Es beeinträchtigt jedoch andere Sicherungsprodukte.
Anforderung | Legen Sie den Parameter „Details und Einstellungen der Sicherungs- und Notfallwiederherstellungsanwendung“ Do not uncatalog auf Nein fest. |
Best Practice | Datenbanksicherungen des Sicherungs- und Notfallwiederherstellungsdiensts sind inkrementell und werden fortlaufend ausgeführt. Dazu wird die RMAN-Image-Kopie mit der RMAN-inkrementellen Zusammenführungs-API verwendet.
Die erste RMAN-Sicherung ist eine vollständige Image-Kopie der Datenbankdatendatei auf dem Sicherungslaufwerk mit einem internen Snapshot des Sicherungslaufwerks.
Die nachfolgenden inkrementellen RMAN-Sicherungen werden mit der RMAN-inkrementellen Zusammenführung auf dem Sicherungs- und Notfallwiederherstellungslaufwerk ausgeführt. Dabei wird die letzte Vollsicherung vor dem Snapshot mit den inkrementellen Änderungen aktualisiert. Wenn jedoch eine Datenbanksicherung eines Drittanbieters oder eine Sicherungsüberprüfung nach der Sicherung der Datenbank für Sicherung und Notfallwiederherstellung ausgeführt wird, werden alle Sicherungsdatendateien unter „Sicherung und Notfallwiederherstellung“ in den RMAN-Metadaten als veraltet gekennzeichnet.
Wenn der Parameter „Details und Einstellungen der Sicherungs- und Notfallwiederherstellungsanwendung“ Do not uncatalog auf Ja gesetzt ist, wird der folgende Fehler ausgegeben: Failed to catalog image copies from staging device (Katalogisierung von Sicherungskopien vom Staging-Gerät fehlgeschlagen) und die Sicherung schlägt fehl. Lassen Sie Do not uncatalog auf Nein gesetzt, um die gemeinsame Nutzung mit anderen älteren Sicherungsprodukten zu ermöglichen. |
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.
|
Block Change Tracking (BCT) der Oracle-Datenbank
Das Oracle-Blockänderungs-Tracking ermöglicht schnelle Datenbanksicherungen, da erkannt wird, welche Blöcke sich geändert haben. Nur geänderte Blöcke werden in den Sicherungsvorgang einbezogen.
Der Dienst „Sicherung und Notfallwiederherstellung“ unterstützt die inkrementelle Sicherung für immer für 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.
Das Blockänderungs-Tracking ist auf Datenbankebene aktiviert.
Oracle zeichnet die geänderten Blöcke in jeder Datendatei in einer Trackingdatei auf, einer kleinen 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.
Wenn die Blockänderungsverfolgung in der Datenbank nicht aktiviert ist, sucht RMAN bei einer inkrementellen Sicherung jeden Block in einer Datendatei nach allen Datendateien in der Datenbank.
Oracle-Datenbanken in einer Konsistenzgruppe für Sicherung und Notfallwiederherstellung schützen
In den meisten Konfigurationen kann eine Consistency Group eine einzelne Oracle-Datenbankanwendung und eine beliebige Anzahl von Dateisystemanwendungen vom Oracle-Server enthalten. Eine Consistency Group ist die empfohlene Wahl für Oracle-Datenbanken in Test- und Entwicklungsprojekten sowie anderen Anwendungsfällen für die Geschäftsagilität.
Oracle-Datenbanken mit TDE
Der Sicherungs- und Notfallwiederherstellungsdienst unterstützt eine Vielzahl von Erfassungs- und Darstellungsmethoden für Oracle-Datenbanken in verschiedenen Konfigurationen. Dazu gehören Sicherung, Wiederherstellung und anwendungsspezifische Bereitstellungsvorgänge von Oracle-Datenbanken mit konfigurierter transparenter Datenverschlüsselung (TDE).
Bei Oracle-Datenbanken mit TDE müssen Wallet-Dateien vom Quellsicherungshost für den Zielhost aller anwendungsspezifischen Bereitstellungen verfügbar sein. Dazu gibt es mehrere Möglichkeiten.
- Die Wallet-Dateien können vom Sicherungsquellenserver auf den Ziel-Mount-Server kopiert und Oracle so konfiguriert werden, dass es darauf zugreift.
- Wenn die Oracle Wallet-Dateien auf einem zentralen, freigegebenen Gerät im Netzwerk gespeichert sind, muss die Appaware-Oracle-Instanz für das Bereitstellungsziel so konfiguriert werden, dass sie darauf zugreifen kann.
Wenn die Oracle-Wallet-Dateien bei der Sicherung mit dem Sicherungs- und Notfallwiederherstellungsdienst erfasst wurden, indem die erweiterte Einstellung „Speicherort der Oracle-Konfigurationsdatei“ festgelegt wurde, können die Wallet-Dateien mit den folgenden Schritten abgerufen werden:
- Führen Sie ein Standard-Mounting der Datenbank auf dem Zielhost durch.
- Kopieren Sie die Wallet-Dateien vom Standarddatenbanken-Mount zum Zielhost und konfigurieren Sie Oracle so, dass sie verwendet werden.
- Trennen Sie die Datenbank vom Zielhost.
- Führen Sie eine anwendungsspezifische Bereitstellung der Datenbank auf dem Zielhost aus.
Sicherung und Notfallwiederherstellung mit Oracle Exadata-Datenbank oder Oracle ExaCC
Sicherungs-/Wiederherstellungs-Anwendungen 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 mit dem Netzwerk verbunden (nicht mit dem Datenpfad).
Bei der RMAN-Sicherung wird RMAN verwendet, um direkt in den Kopierdatenspeicher zu schreiben, der von Backup and DR als Dateisystem oder als ASM-Speichergruppe dargestellt wird.
Datenaufnahmeformate: unter ASM-Laufwerksgruppe (nur iSCSI) oder unter Dateisystem (dNFS oder iSCSI).
Für die Sicherung und Notfallwiederherstellung mit der Funktion „Inkrementelle Sicherung für immer“ werden inkrementell aktualisierte RMAN-Sicherungen verwendet, bei denen Sicherungen von Image-Kopien fortlaufend vorwärts kopiert werden.
Sicherung und Notfallwiederherstellung 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 and DR-Agent stellt Sicherungs- und Notfallwiederherstellungslaufwerke als iSCSI-Ziel für den Exadata-Server bereit und ordnet sie ihm zu. Das Datenerfassungsformat kann unter ASM-Laufwerksgruppe oder unter Dateisystem angegeben werden.
Installieren Sie den Sicherungs- und Notfallwiederherstellungs-Agenten auf jedem Exadata-Host im Nutzerbereich, um die Kommunikation mit der Sicherungs-/Wiederherstellungs-Appliance zu erleichtern und die RMAN API für die Datenbanksicherung aufzurufen.
Aufnahmeformat unter ASM-Laufwerksgruppe
Während einer Sicherung führt der Sicherungs- und Notfallwiederherstellungs-Agent folgende Schritte aus:
Ordnen Sie das logische Laufwerk dem Exadata-Server als iSCSI-Ziel zu und stellen Sie es bereit.
Fügen Sie dem ASM-Laufwerkstring den Pfad zum Sicherungs- und Notfallwiederherstellungslaufwerk hinzu.
Der ASM-Dateistring muss der Parameterdatei hinzugefügt werden und darf nicht im CRS-Profil vorhanden sein.
Erstellen Sie eine ASM-Laufwerksgruppe als externe Redundanz mit einem Sicherungs- und Notfallwiederherstellungslaufwerk.
RMAN-Sicherung mit RMAN, um direkt in den Sicherungsdatenspeicher zu schreiben, der von der Sicherungs-/Wiederherstellungs-Appliance als ASM-Speichergruppe oder als Dateisystem bereitgestellt wird.
Dauerhaft inkrementelle Sicherung mit inkrementell aktualisierten RMAN-Sicherungen und fortlaufenden Sicherungen von Sicherungs-Images.
Erfassungsformat unter dem 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 genau wie ASM direkt in den Datenbankkern eingebunden.
Das dNFS-Protokoll kann für die dateisystembasierte Sicherung als NFS-Freigabe verwendet werden.
Der Sicherungs- und Notfallwiederherstellungs-Agent stellt Sicherungs- und Notfallwiederherstellungslaufwerke als NFS-Freigabe bereit und ordnet sie dem Exadata-Server zu.
Voraussetzungen für dNFS auf Exadata-Servern:
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 auf dem Dateisystem einer dNFS-Freigabe zu sichern, die von der Sicherungs-/Wiederherstellungs-Appliance bereitgestellt wird.
ASM-Speichergruppen, die durch Sicherung und Notfallwiederherstellung geschützt sind, nach dem Neustart eines Ziel-Datenbankservers wieder online stellen
Nach einem Neustart des Datenbankservers, bei dem die Sicherungs- und Notfallwiederherstellungskopie bereitgestellt ist, oder wenn zum Zeitpunkt des Neustarts/Absturzes Sicherungen der Sicherungs- und Notfallwiederherstellung für die Datenbank ausgeführt werden, gehen Sie so vor, um die Bereitstellung der Sicherungs- und Notfallwiederherstellungslaufwerksgruppe wiederherzustellen:
Prüfen Sie, ob der Zieldatenbankserver wieder verfügbar ist und ob ASM und das RAC-System ebenfalls aktiv sind.
Starten Sie den Sicherungs- und Notfallwiederherstellungs-Agenten neu (über das Stammverzeichnis).
ASM-Umgebung festlegen
Melden Sie sich bei ASM
sqlplus
an und prüfen Sie den Status der Laufwerkgruppe:select name, state from v$asm_diskgroup where name = '<dg name>';)
Wenn die Bereitstellung aufgehoben wurde, stellen Sie die Laufwerkgruppe bereit:
alter diskgroup <dg name> mount;
Melden Sie sich beim Oracle-Betriebssystem an, legen Sie die Datenbankumgebung fest und starten Sie die Datenbank.
Nächste Schritte
Weitere Informationen zu den Voraussetzungen für die Sicherung einer Oracle-Datenbank
Sonstige Dokumentation für Backup und DR für Oracle
- Sicherung und Notfallwiederherstellung für Oracle-Datenbanken
- Voraussetzungen für den Schutz einer Oracle-Datenbank
- Oracle-Patches und bekannte Probleme
- Oracle-Datenbanken für den Schutz vorbereiten
- Oracle-Datenbanken ermitteln und schützen
- App-Details und -Einstellungen festlegen
- dNFS mit Sicherung und Notfallwiederherstellung verwenden
- Eine erkannte Oracle-Datenbank schützen
- Oracle-Datenbank als Standard-Mount bereitstellen
- Solltest du eine sofortige virtuelle Kopie einer Oracle-Datenbank erstellen?
- Oracle-Datenbank wiederherstellen
- Sofortige Wiederherstellung einer Oracle-Datenbank mithilfe von „Mount and Migrate“
- Umgebung mit einem Sicherungs- und Notfallwiederherstellungs-Workflow bereitstellen