Automatisieren Sie Datenbankrollenänderungen für manuell konfiguriertes Oracle Data Guard in OCI Database Services mit OCI Full Stack DR und benutzerdefinierten Skripten

Einführung

Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) orchestriert den Übergang von Compute-, Datenbank- und Anwendungen zwischen Oracle Cloud Infrastructure-(OCI-)Regionen aus der ganzen Welt mit einem einzigen Klick. Kunden können die erforderlichen Schritte zur Wiederherstellung eines oder mehrerer Geschäftssysteme automatisieren, ohne die vorhandene Infrastruktur, Datenbanken oder Anwendungen neu zu entwerfen oder zu strukturieren und ohne spezielle Verwaltungs- oder Konvertierungsserver zu benötigen.

OCI Full Stack DR bietet vollständig integrierten Support für verschiedene Oracle Database-Services auf OCI. Diese Datenbanken können als Mitglieder einer OCI Full Stack DR-Schutzgruppe hinzugefügt werden, um koordinierte Disaster Recovery-Vorgänge zu ermöglichen.

Für verwaltete Oracle Databases-Services in OCI wird dringend empfohlen, Oracle Data Guard über die OCI-Konsole, die Oracle Cloud Infrastructure-Befehlszeilenschnittstelle (OCI-CLI) oder OCI-SDKs zu konfigurieren. Dadurch wird sichergestellt, dass OCI Full Stack DR die Data Guard-Konfiguration automatisch erkennen und integrierte Plangruppen für Rollenübergänge als Teil Ihres DR-Plans generieren kann.

Es gibt jedoch Szenarien, in denen eine manuelle Oracle Data Guard-Konfiguration (außerhalb der nativen Schnittstellen von OCI) aufgrund spezifischer technischer oder betrieblicher Anforderungen erforderlich wird, wie z. B.:

Anwendungsspezifische Constraints.
Kaskadierte Standbykonfigurationen.
Verwendung älterer Datenbankversionen aufgrund der Anwendungskompatibilität.

In solchen Fällen kann es sein, dass die Control Plane der OCI Database-Services das Oracle Data Guard-Setup nicht erkennt. OCI Full Stack DR bietet jedoch weiterhin Flexibilität. Sie können Rollenübergänge verarbeiten, indem Sie benutzerdefinierte Skripte erstellen und in benutzerdefinierte Plangruppen innerhalb Ihrer DR-Pläne integrieren.

Beachten Sie, dass diese Lösung nicht mit Oracle Database Cloud-Services kompatibel ist, bei denen Data Guard-Konfigurationen über die OCI-Konsole, SDKs oder APIs verwaltet werden.

In diesem Tutorial wird ein standardisierter Ansatz zur Verwaltung von Oracle Data Guard-Rollenübergängen mit benutzerdefinierten Datenbank-Handler-Skripten für OCI Database-Services beschrieben, bei denen Oracle Data Guard manuell konfiguriert wurde.

Hinweis: Diese benutzerdefinierte Skriptlösung gilt für die folgenden OCI Database-Services:

Oracle Base Database Service

Oracle Exadata Database Service on Dedicated Infrastructure

Oracle Exadata Database Service auf Exascale-Infrastruktur

Oracle Exadata Database Service on Cloud@Customer

Architekturbeschreibung

In diesem Tutorial verwenden wir Oracle Base Database Service mit zwei DB-Systemen, die in zwei OCI-Regionen bereitgestellt werden, in denen Oracle Data Guard manuell konfiguriert wurde.

custom-data-guard-konfiguration
Abbildung A: Benutzerdefinierte Data Guard-Konfiguration mit Oracle Base Database Service

Definitionen und Annahmen im gesamten Tutorial

Bereiche:
- Region 1 (Ashburn): Ashburn dient zunächst als primäre Region.
- Region 2 (Phoenix): Phoenix fungiert zunächst als Standbyregion.
Compartments: Sie können dieses Deployment und OCI Full Stack DR in jedem Compartment-Schema organisieren, das gemäß Ihren Standards für IT-Governance funktioniert. Wir haben uns entschieden, alle OCI-Ressourcen für dieses Tutorial in einem einzigen Compartment zu organisieren.

Ziele

In diesem Tutorial werden die folgenden Aufgaben behandelt:

Aufgabe 1: Prüfen Sie die Oracle Data Guard-Konfiguration, und aktualisieren Sie die Tags.
Aufgabe 2: Erstellen und verknüpfen Sie DR-Schutzgruppen.
Aufgabe 3: Fügen Sie den DR-Schutzgruppen Elemente hinzu.
Aufgabe 4: Erstellen und ändern Sie die DR-Pläne in Region 2.
Aufgabe 5: Führen Sie Vorabprüfungen für die DR-Pläne in Region 2 aus.
Aufgabe 6: Führen Sie den Switchover-Plan in Region 2 aus.
Aufgabe 7: Erstellen und ändern Sie die DR-Pläne in Region 2.

Voraussetzungen

Wir werden die folgenden Ressourcen verwenden, um mit dem Tutorial zu beginnen.

Ressourcen	Region 1 - Ashburn	Region 2 - Phoenix
Compartment	app	app
DB-System	adghol-12345	adghol-12345
DB-Name	Adghol	Adghol
Eindeutiger DB-Name	adghol-site0	adghol-site1
DB-Rolle	Primär	Standby
Compute-VM	Skript-Iad	Skript-Phx
Zeitraum	IAD	PHX

Hinweis: Schließen Sie alle erforderlichen Voraussetzungen ab, bevor Sie fortfahren. Diese Schritte bilden die Grundlage für ein reibungsloses und erfolgreiches OCI Full Stack DR-Setup.

Admin-Zugriff oder erforderliche Oracle Cloud Infrastructure Identity and Access Management-(OCI IAM-)Policys.

Stellen Sie sicher, dass Sie über Administratorberechtigungen verfügen, oder konfigurieren Sie die erforderlichen OCI IAM-Policys und dynamischen Gruppen, um OCI Full Stack DR zu verwenden. In dieser Lösung startet das Datenbank-Handler-Skript intern eine OCI-Containerinstanz, sodass Sie Policys entsprechend hinzufügen müssen.

Hinweis: Ersetzen Sie alle Vorkommen von <compartment_ocid> und <compartment_name> durch Ihre tatsächliche OCI-Compartment-OCID und Ihren tatsächlichen Namen.

Dynamische Gruppe erstellen: Erstellen Sie eine dynamische Gruppe mit dem Beispielnamen (FullStackDR_Database_DG), und fügen Sie die folgenden Vergleichsregeln hinzu:

 Any {instance.compartment.id = '<compartment_ocid>'}
 Any {resource.type = 'instance', resource.compartment.id = '<compartment_ocid>'}
 Any {resource.type = 'computecontainerinstance', resource.compartment.id = '<compartment_ocid>'}
 Any {resource.type = 'drprotectiongroup', resource.compartment.id = '<compartment_ocid>'}

OCI-IAM-Policy erstellen: Erstellen Sie eine Policy mit dem Beispielnamen (FullStackDR_Database_Group_Policies), und fügen Sie die folgenden Zulassungsanweisungen hinzu:

 Allow dynamic-group FullStackDR_Database_DG to read secret-family in compartment <compartment_name>
 Allow dynamic-group FullStackDR_Database_DG to manage virtual-network-family in compartment <compartment_name>
 Allow dynamic-group FullStackDR_Database_DG to manage instance-agent-command-family in compartment <compartment_name>
 Allow dynamic-group FullStackDR_Database_DG to manage instance-agent-command-execution-family in compartment <compartment_name>
 Allow dynamic-group FullStackDR_Database_DG to manage objects in compartment <compartment_name>
 Allow dynamic-group FullStackDR_Database_DG to manage database-family in compartment <compartment_name>
 Allow dynamic-group FullStackDR_Database_DG to manage compute-container-family in compartment <compartment_name>

Weitere Informationen finden Sie unter OCI Disaster Recovery Policys - Offizielle Dokumente und IAM-Policys konfigurieren (Oracle Blog).

OCI-Compute-Instanzen in beiden Regionen bereitstellen: Erstellen Sie eine OCI-Compute-Instanz in jeder Region, um als Jumphost für das Hosting und die Ausführung der detaillierten Schritte scripts.For zu dienen. Informationen hierzu finden Sie unter OCI-Instanz erstellen. Der Einfachheit halber bezeichnen wir diese OCI Compute-Instanz als Jumphost in der gesamten tutorial.If, in der Sie bereits vorhandene OCI Compute-Instanzen haben, die als Jumphost fungieren können. Sie können diesen Schritt überspringen. Stellen Sie sicher, dass der Oracle Cloud Agent im Jumphost ausgeführt wird und das Befehls-Plug-in für die Ausführung aktiviert ist. Weitere Informationen finden Sie unter Oracle Cloud Agent.
Zugriff auf Ausführungsbefehle auf OCI Compute-Instanzen: Stellen Sie sicher, dass Sie die Voraussetzungen für den Ausführungsbefehl im Jumphost einrichten, da benutzerdefinierte Plangruppen zur Ausführung von Skripten während DR-Vorgängen verwendet werden. Weitere Informationen finden Sie unter Befehle auf einer Instanz ausführen.
Installieren Sie die OCI-CLI im Jumphost in beiden Regionen: Installieren Sie die OCI-CLI basierend auf dem Betriebssystem des Jumphosts in beiden Regionen, und stellen Sie sicher, dass Sie OCI-CLI-Befehle aufrufen können. Im Skript wird der Instanz-Principal verwendet. Weitere Informationen finden Sie unter OCI-CLI-Installation.
VCNs in beiden Regionen mit Remote-VCN-Peering einrichten: Erstellen Sie VCNs sowohl in der Primär- als auch in der Standbyregion, und richten Sie Remote-VCN-Peering ein. Dies ist zum Einrichten des regionsübergreifenden Oracle Data Guard erforderlich. Weitere Informationen finden Sie unter OCI Base DB-Netzwerkkonfiguration.
Manuelle Oracle Data Guard-Konfiguration: Konfigurieren Sie das Oracle Data Guard-Setup manuell basierend auf den Anforderungen mit Oracle Data Guard Broker. Weitere Informationen finden Sie unter Oracle Data Guard Broker und Oracle Clusterware.
Datenbank-Handler-Skripte im Jumphost herunterladen: Die Skripte müssen heruntergeladen und in beiden Regionen im Jumphost gespeichert werden.
1. Laden Sie die Skripte des Oracle Data Guard-Datenbank-Handlers aus dem folgenden Repository herunter: Data Guard-DB-Handler-Skripte.
2. Kopieren Sie die Skripte in das Verzeichnis /home/opc/ (oder einen anderen bevorzugten Pfad) auf dem Jumphost in beiden Regionen.
3. Stellen Sie sicher, dass die Skriptdateien ausführbare Berechtigungen haben.
4. full_stack_dr_non_std_db_handler.py is the Python script responsible for handling the Oracle Data Guard role transitions.The associated bash scripts are provided as templates and can be modified to suit your specific requirements. Ändern Sie nicht das Python-Rollenänderungsskript selbst.
OCI Vault und Secrets erstellen: Sie müssen einen OCI Vault erstellen und Datenbankzugangsdaten als Secrets in beiden Regionen speichern.
1. Erstellen Sie einen OCI Vault in jeder Region mit der OCI-Konsole oder CLI.
2. Erstellen Sie ein Secret im Vault, um das SYS-Benutzerkennwort für die Datenbank zu speichern.
Weitere Informationen finden Sie unter OCI-Vaults.
Konnektivitätsprüfungen aus dem Jumphost: Stellen Sie sicher, dass der OCI Database-Service, der OCI Vault-Service und der OCI-Containerinstanzservice von der Compute-Instanz aus zugänglich sind. Dies ist erforderlich, da die OCI-Full-Stack-DR-Skripte eine Introspektion ausführen, um Datenbankdetails sowohl aus primären als auch aus Standbyregionen abzurufen.
1. Konnektivität muss vom Jumphost aus funktionieren. Führen Sie die folgenden Befehle aus dem Jumphost aus.
```
  # Primary Region
  curl -v telnet://database.<primary_region>.oraclecloud.com:443
  curl -v telnet://secrets.vaults.<primary_region>.oci.oraclecloud.com:443
  curl -v telnet://iaas.<primary_region>.oraclecloud.com:443
  curl -v telnet://compute-containers.<primary_region>.oci.oraclecloud.com:443

  # Standby Region
  curl -v telnet://database.<standby_region>.oraclecloud.com:443
  curl -v telnet://secrets.vaults.<standby_region>.oci.oraclecloud.com:443
  curl -v telnet://iaas.<standby_region>.oraclecloud.com:443
  curl -v telnet://compute-containers.<standby_region>.oci.oraclecloud.com:443
```
  Hinweis: Ersetzen Sie <primary_region> und <standby_region> durch tatsächliche OCI-Regions-IDs.
  Beispiel:
  - us-ashburn-1 für Ashburn
  - us-phoenix-1 für Phoenix
  Eine vollständige Liste finden Sie unter OCI-Regions-IDs.
  
  Erwartete Ausgabe: Jeder Befehl muss eine Meldung wie Connected to ... zurückgeben.
  
  Wenn eine Verbindung nicht erfolgreich verläuft, prüfen Sie die Sicherheitslisten, Routentabellen und die Servicegatewaykonfiguration des VCN/der Subnetze des Jumphosts.
Objektspeicher-Buckets erstellen: Erstellen Sie OCI Object Storage-Buckets in der Primär- und Standbyregion, um Logs zu speichern, die von OCI Full Stack DR während Recovery-Vorgängen generiert wurden, wie hier beschrieben: Logspeicherort für Vorgangslogs vorbereiten.

Verwendung und Anpassung von Datenbank-Handler-Skripten: Sie können die Datenbank-Handler-Skripte aus dem angegebenen GitHub-Repository herunterladen. Hier sind die Datenbank-Handler-Skriptverwendung und die erforderlichen Parameter.

Abbildung B: DB-Handler-Skriptverwendung

Folgende --db_operation-Optionen werden unterstützt:

SWITCHOVER
SWITCHOVER_PRECHECK
FAILOVER
FAILOVER_PRECHECK
CONVERT_PHYSICAL_TO_SNAPSHOT_STANDBY
CONVERT_PHYSICAL_TO_SNAPSHOT_STANDBY_PRECHECK
REVERT_SNAPSHOT_TO_PHYSICAL_STANDBY_PRECHECK
REVERT_SNAPSHOT_TO_PHYSICAL_STANDBY

OCI Full Stack DR erwartet, dass alle erforderlichen Parameter übergeben werden, wenn das Datenbank-Handler-Skript ausgeführt wird. Für eine bessere Benutzerfreundlichkeit und Wiederholbarkeit wird empfohlen, ein Wrapper-bash-Skript zu erstellen, das:

Stellt die erforderlichen Parameter bereit.
Aktiviert das Logging für Auditing und Fehlerbehebung.

Beispiel: Datenbank-Switchover-Skript (db-switchover-iad-phx.sh).

#!/bin/bash

# Define log file with date and time
LOG_FILE="db-switchover-iad-phx-$(date +%Y%m%d_%H%M%S).log"

# Define Python script and argument
PYTHON_SCRIPT="full_stack_dr_non_std_db_handler.py"
ARGUMENT="--database_ocid="ocid1.database.oc1.phx.xxxxxxxx" --vault_ocid="ocid1.vaultsecr
et.oc1.phx.xxxxx" --region="us-phoenix-1" --primary_db_unique_name="adghol_site0" --st
andby_db_unique_name="adghol_site1" --drpg_ocid="ocid1.drprotectiongroup.oc1.phx.axxxxxxax
" --db_operation="SWITCHOVER" --auth_type=INSTANCE_PRINCIPAL"

# Execute Python script and log output
echo "Executing Python script: $PYTHON_SCRIPT with argument: $ARGUMENT" | tee -a $LOG_FILE
/usr/bin/python3 $PYTHON_SCRIPT $ARGUMENT 2>&1 | tee -a $LOG_FILE

echo "Execution completed. Logs saved in $LOG_FILE"

Hinweis: Speichern Sie dieses Wrapper-Skript an demselben Speicherort wie Ihre Datenbank-Handler-Skripte, und stellen Sie sicher, dass es ausführbar ist. OCIDs werden im Skript anonymisiert.
chmod +x db-switchover-wrapper.sh

DR-Planskriptzuordnung, bei der die DB, die in Region 1 (Ashburn) ausgeführt wird, primär und Region 2 (Phoenix) Standby ist

DR-Plantyp	Zielinstanz	Skriptname	Kommentar
`Switchover`	`script-phx`	`db-prechk-switchover-iad-phx.sh`	DB-Switchover von IAD zu PHX vorbereiten
`Switchover`	`script-phx`	`db-switchover-iad-phx.sh`	DB-Switchover von IAD zu PHX
`Failover`	`script-phx`	`db-prechk-failover-iad-phx.sh`	DB-Failover von IAD auf PHX vorbereiten
`Failover`	`script-phx`	`db-failover-iad-phx.sh`	DB-Failover von IAD zu PHX
`Start drill`	`script-phx`	`db-prechk-startdrill-phx.sh`	Prechk Start DR Drill in PHX
`Start drill`	`script-phx`	`db-startdrill-phx.sh`	DR Drill in PHX starten
`Stop drill`	`script-phx`	`db-prechk-stopdrill-phx.sh`	Prechk Stop DR Drill in PHX
`Stop drill`	`script-phx`	`db-stopdrill-phx.sh`	DR-Drill in PHX stoppen

DR-Planskriptzuordnung, bei der die in Region 2 (Phoenix) ausgeführte DB primär und Region 2 (Ashburn) Standby ist

DR-Plantyp	Zielinstanz	Skriptname	Kommentar
`Switchover`	`script-iad`	`db-prechk-switchover-phx-iad.sh`	DB-Switchover von PHX zu IAD vorbereiten
`Switchover`	`script-iad`	`db-switchover-phx-iad.sh`	DB-Switchover von PHX zu IAD
`Failover`	`script-iad`	`db-prechk-failover-phx-iad.sh`	DB-Failover von PHX zu IAD vorbereiten
`Failover`	`script-iad`	`db-failover-phx-iad.sh`	DB-Failover von PHX zu IAD
`Start drill`	`script-iad`	`db-prechk-startdrill-iad.sh`	Prechk Start DR Drill in IAD
`Start drill`	`script-iad`	`db-startdrill-iad.sh`	DR-Drilldown in IAD starten
`Stop drill`	`script-iad`	`db-prechk-stopdrill-iad.sh`	Prechk Stop DR Drill in IAD
`Stop drill`	`script-iad`	`db-stopdrill-iad.sh`	DR-Drilldown in IAD stoppen

Hinweis: Zur besseren Übersichtlichkeit und Benutzerfreundlichkeit haben wir mehrere bash-Wrapper-Skripte erstellt, die auf bestimmte DR-Plantypen und -Regionen zugeschnitten sind. Diese Skripte verwenden ein gemeinsam verwendetes Python-Skript für Datenbankrollenübergänge, das Sie an Ihre eigenen Anforderungen und Umgebungen anpassen können.

Aufgabe 1: Oracle Data Guard-Konfiguration prüfen und Tag aktualisieren

In dieser Aufgabe prüfen wir die manuelle Oracle Data Guard-Konfiguration mit Oracle Base Database Service. Wir erstellen ein *Tag** in der Datenbank, um ein nicht standardmäßiges Oracle Data Guard-Setup anzugeben. Auf diese Weise kann OCI Full Stack DR einen DR-Plan erstellen, ohne sich auf integrierte Plangruppen verlassen zu müssen.

Melden Sie sich bei der OCI-Konsole an, und navigieren Sie zu Oracle Database, und klicken Sie auf Oracle Base Database Service.
Stellen Sie sicher, dass der OCI-Regionskontext auf Region 1 (Ashburn) gesetzt ist.
Wählen Sie das DB-System aus, in unserem Beispiel adghol0-12345.

Abbildung 1.1: DB-System in Region 1
Navigieren Sie zur Registerkarte Datenbanken, und wählen Sie die Datenbank adghol aus.

Abbildung 1.2: Datenbank in Region 1
Stellen Sie sicher, dass der Data Guard-Status Nicht aktiviert ist. Dadurch wird bestätigt, dass Oracle Data Guard nicht mit der OCI-Konsole eingerichtet ist.

Abbildung 1.3: Data Guard-Control Plane-Status in Region 1

Navigieren Sie zur Registerkarte Tags, und erstellen Sie die Freiformtags. Sie müssen den Wert von Peer DB OCID basierend auf Ihrem Setup ersetzen. In diesem Beispiel müssen Sie die Datenbank-OCID der Region Phoenix hinzufügen.

Tagschlüssel	Datum
`FsdrNonStandardDataGuardPeerDatabaseId`	`Peer DB OCID`
`FsdrNonStandardDataGuardFlag`	`True`

iad-db-dataguard-tags
Abbildung 1.4: DB-Tags in Region 1

Gehen Sie zu den DB-Systemen, und wählen Sie Knoten aus.

Abbildung 1.5: DB-Knoten in Region 1

Hinweis: Dies ist ein Setup für Nicht-RAC, sodass ein einzelner Datenbankknoten angezeigt wird. Wenn dies ein Oracle Real Application Clusters-Setup wäre, würden zwei Knoten angezeigt.
Melden Sie sich beim Datenbankknoten an, und wechseln Sie zum Benutzer oracle. Prüfen Sie die Rollen mit Oracle Data Guard Broker.
```
dgmgrl
show configuration
```
Abbildung 1.6: Data Guard-Status in Region 1

Erwartete Ausgabe:
- adghol_site0 muss als Primäre Datenbank angezeigt werden.
- adghol_site1 muss als Physische Standbydatenbank angezeigt werden.
- Configuration Status sollte Erfolgreich angezeigt werden.
Wenn Fehler auftreten und die Datenbankrollen nicht wie erwartet sind, müssen Sie die Fehler in der Oracle Data Guard-Dokumentation beheben.
Melden Sie sich bei der OCI-Konsole an, und navigieren Sie zu Oracle Database, und klicken Sie auf Oracle Base Database Service.
Stellen Sie sicher, dass der OCI-Regionskontext auf Region 2 (Phoenix) gesetzt ist.
Wählen Sie das DB-System aus. Im Beispiel lautet es adghol1-12345

Abbildung 1.7: DB-System in Region 2
Navigieren Sie zur Registerkarte Datenbanken, und wählen Sie die Datenbank adghol aus.

Abbildung 1.8: Datenbank in Region 2
Stellen Sie sicher, dass der Data Guard-Status Nicht aktiviert ist. Dadurch wird bestätigt, dass Oracle Data Guard nicht mit der OCI-Konsole eingerichtet ist.

Abbildung 1.9: Data Guard-Control Plane-Status in Region 2

Tagschlüssel	Datum
`FsdrNonStandardDataGuardPeerDatabaseId`	`Peer DB OCID`
`FsdrNonStandardDataGuardFlag`	`True`

phx-db-dataguard-Tags
Abbildung 1.10: DB-Tags in Region 2

Wiederholen Sie den 7. und 8. Schritt, aber stellen Sie diesmal eine Verbindung zum Datenbankknoten in Region 2 (Standbyregion) her.
- Stellen Sie sicher, dass Sie als Benutzer oracle auf dem Datenbankknoten Region 2 angemeldet sind.
- Prüfen Sie die Oracle Data Guard-Rollen wie in Schritt 8 mit dgmgrl.

Aufgabe 2: DR-Schutzgruppen erstellen und zuordnen

Erstellen Sie DR-Schutzgruppen in Region 1 und Region 2, wenn die Schutzgruppen für diesen Anwendungsstack noch nicht vorhanden sind.

Aufgabe 2.1: Schutzgruppe in Region 1 erstellen

Gehen Sie zur OCI-Konsole, und navigieren Sie zu DR-Schutzgruppen, wie in Abbildung 2.1 dargestellt.
1. Stellen Sie sicher, dass der OCI-Regionskontext auf Region 1 (Ashburn) gesetzt ist.
2. Klicken Sie auf Migration und Disaster Recovery.
3. Klicken Sie auf DR-Schutzgruppen.
Abbildung 2.1: Zu DR-Schutzgruppen navigieren
Erstellen Sie eine grundlegende DR-Schutzgruppe in Region 1, wie in Abbildung 2.2 dargestellt. Peer, Rolle und Mitglieder werden in späteren Schritten zugewiesen.
1. Wählen Sie das Compartment aus, in dem die DR-Schutzgruppe erstellt werden soll.
2. Klicken Sie auf DR-Schutzgruppe erstellen.
3. Verwenden Sie einen aussagekräftigen Namen für die DR-Schutzgruppe.
4. Wählen Sie OCI Object Storage-Bucket für OCI Full Stack DR-Logs aus.
5. Klicken Sie auf Erstellen.
Abbildung 2.2: Erforderliche Parameter zum Erstellen einer DR-Schutzgruppe in Region 1

Aufgabe 2.2: Schutzgruppe in Region 2 erstellen

Navigieren Sie zur OCI-Konsole, und navigieren Sie zu DR-Schutzgruppen, wie in Abbildung 2.3 dargestellt.
1. Stellen Sie sicher, dass der OCI-Regionskontext auf Region 2 (Phoenix) gesetzt ist.
2. Klicken Sie auf Migration und Disaster Recovery.
3. Klicken Sie auf DR-Schutzgruppen.
Abbildung 2.3: Zu DR-Schutzgruppen navigieren
Erstellen Sie eine grundlegende DR-Schutzgruppe in Region 2, wie in Abbildung 2.4 dargestellt. Peer, Rolle und Mitglieder werden in späteren Schritten zugewiesen.
1. Wählen Sie das Compartment aus, in dem die DR-Schutzgruppe erstellt werden soll.
2. Klicken Sie auf DR-Schutzgruppe erstellen.
3. Verwenden Sie einen aussagekräftigen Namen für das DRPG.
4. Wählen Sie OCI Object Storage-Bucket für OCI Full Stack DR-Logs aus.
5. Klicken Sie auf Erstellen.
Abbildung 2.4: Erforderliche Parameter zum Erstellen einer DR-Schutzgruppe in Region 2

Aufgabe 2.3: Schutzgruppen in Region 1 und Region 2 zuordnen

Verknüpfen Sie die DRPGs in jeder Region als Peers untereinander, und weisen Sie die Peerrollen von Primär- und Standbydatenbank zu. Die Rollen von Primär- und Standbydatenbank werden automatisch von OCI Full Stack DR im Rahmen einer DR-Operation/DR-Planausführung geändert. Die Rollen müssen nicht jederzeit manuell verwaltet werden.

Gehen Sie zur Seite DR-Schutzgruppendetails.
1. Stellen Sie sicher, dass der OCI-Regionskontext auf Region 1 (Ashburn) gesetzt ist.
2. Klicken Sie auf das Dropdown-Menü Aktionen, und klicken Sie auf Zuordnen, um den Prozess zu starten.
Abbildung 2.5: DRPG-Verknüpfung beginnen
Geben Sie folgende Informationen ein.
1. Rolle: Wählen Sie die Rolle Primär aus. OCI Full Stack DR weist Region 2 automatisch die Standbyrolle zu.
2. Peerregion: Wählen Sie Region 2 (Phoenix) aus, in der die andere DR-Schutzgruppe erstellt wurde.
3. Peer- DR-Schutzgruppe: Wählen Sie die erstellte Peer-DR-Schutzgruppen aus.
4. Klicken Sie auf Verknüpfen.
Abbildung 2.6: Erforderliche Parameter für die Zuordnung der DRPGs

OCI Full Stack DR zeigt so etwas wie in der folgenden Abbildung, sobald die Verknüpfung abgeschlossen ist.

Die aktuelle primäre Peer-DRPG ist Ashburn (Region 1).
Die aktuelle Standby-Peer-DRPG ist Phoenix (Region 2).

Abbildung 2.7: Peer-Beziehung aus der individuellen DRPG-Perspektive anzeigen

Die gleichen Informationen finden Sie, wenn der Kontext/die Ansicht aus einer globalen Perspektive alle DR-Schutzgruppen zeigt, wie im folgenden Bild gezeigt.

Die aktuelle primäre Peer-DRPG ist Ashburn (Region 1).
Die aktuelle Standby-Peer-DRPG ist Phoenix (Region 2).

Abbildung 2.8: Peer-Beziehung aus globaler DRPG-Perspektive anzeigen

Aufgabe 3: Mitglieder zu DR-Schutzgruppen hinzufügen

In dieser Aufgabe fügen wir die folgenden OCI-Ressourcen zur primären DR-Schutzgruppe in Region 1 hinzu.

Die OCI Compute-Instanz, die das Datenbank-Handler-Skript hostet, wird als nicht verschiebende VM hinzugefügt.
Das primäre DB-System.

Aufgabe 3.1: Mitglieder zu DR-Schutzgruppe in Region 1 hinzufügen

Wählen Sie die DR-Schutzgruppe in Region 1 aus, wie in der folgenden Abbildung dargestellt.
1. Stellen Sie sicher, dass der OCI-Regionskontext Region 1 (Ashburn) ist.
2. Wählen Sie die DR-Schutzgruppe in Region 1 aus.
3. Navigieren Sie zur Registerkarte Mitglieder.
4. Klicken Sie auf Mitglieder verwalten.
Abbildung 3.1: So fügen Sie Mitglieder zur DR-Schutzgruppe in Region 1 hinzu
Fügen Sie eine Compute-Instanz für die Datenbank-Handler-Skripte hinzu.
1. Wählen Sie Element hinzufügen aus
2. Wählen Sie unter Compute als ElementRessourcentyp die Option Instanz aus.
3. Wählen Sie die Compute-Instanz aus, in der die Datenbank-Handler-Skripte gehostet werden.
4. Wählen Sie Nicht zu verschiebende Instanz aus.
5. Klicken Sie auf Hinzufügen.
Abbildung 3.2: Compute-Instanz zum DRPG in Region 1 hinzufügen

Prüfen Sie die hinzugefügte Compute-Instanz.

Abbildung 3.2: Compute-Instanz wurde dem DRPG in Region 1 hinzugefügt
Primärdatenbank hinzufügen Klicken Sie auf Mitglied hinzufügen
1. Wählen Sie Element hinzufügen aus
2. Wählen Sie Oracle Database -> Datenbank (Base DB,ExaDB-D,ExaCC,ExaXS) als Element Ressourcentyp aus.
3. Wählen Sie Oracle Base Database als Datenbanktyp aus.
4. Wählen Sie Datenbanksystem aus.
5. Wählen Sie Datenbank-Home aus.
6. Wählen Sie Datenbank aus.
7. Datenbankkennwort-Secret auswählen
8. Klicken Sie auf Hinzufügen.
Abbildung 3.3: Parameter, die zum Hinzufügen der primären DB erforderlich sind

Prüfen Sie die hinzugefügte Primärdatenbank, und veröffentlichen Sie beide Member.

Abbildung 3.4: Primäre DB wurde dem DRPG in Region 1 hinzugefügt

Abbildung 3.5: Veröffentlichen von Elementen im DRPG in Region 1

Nach einigen Minuten sollten beide Mitglieder unter den Mitgliedern zur Verfügung stehen.

Abbildung 3.6: Dem DRPG in Region 1 hinzugefügte Elemente

Aufgabe 3.2: Mitglieder zu DR-Schutzgruppe in Region 2 hinzufügen

Wählen Sie die DR-Schutzgruppe in Region 2 aus, wie in der folgenden Abbildung dargestellt.
1. Stellen Sie sicher, dass der OCI-Regionskontext Region 2 (Phoenix) ist.
2. Wählen Sie die DR-Schutzgruppe in Region 2 aus.
3. Navigieren Sie zur Registerkarte Mitglieder.
4. Klicken Sie auf Mitglieder verwalten.
Abbildung 3.7: So fügen Sie Mitglieder zur DR-Schutzgruppe in Region 2 hinzu
Fügen Sie eine Compute-Instanz für die Datenbank-Handler-Skripte hinzu.
1. Wählen Sie Element hinzufügen aus
2. Wählen Sie unter Compute als ElementRessourcentyp die Option Instanz aus.
3. Wählen Sie die Compute-Instanz aus, in der die Datenbank-Handler-Skripte gehostet werden.
4. Wählen Sie Nicht zu verschiebende Instanz aus.
5. Klicken Sie auf Hinzufügen.
Abbildung 3.8: Compute-Instanz zum DRPG in Region 2 hinzufügen

Prüfen Sie die hinzugefügte Compute-Instanz.

Abbildung 3.9: Compute-Instanz, die dem DRPG in Region 2 hinzugefügt wurde
Hinzufügen der Standbydatenbank. Klicken Sie auf Mitglied hinzufügen
1. Wählen Sie Element hinzufügen aus
2. Wählen Sie Oracle Database -> Datenbank (Base DB,ExaDB-D,ExaCC,ExaXS) als Element Ressourcentyp aus.
3. Wählen Sie Oracle Base Database als Datenbanktyp aus.
4. Wählen Sie Datenbanksystem aus.
5. Wählen Sie Datenbank-Home aus.
6. Wählen Sie Datenbank aus.
7. Datenbankkennwort-Secret auswählen
8. Klicken Sie auf Hinzufügen.
Abbildung 3.10: Erforderliche Parameter zum Hinzufügen der Standby-DB

Prüfen Sie die hinzugefügte Standby-Datenbank, und veröffentlichen Sie beide Member.

Abbildung 3.11: Standby-DB in Region 2 zum DRPG hinzugefügt

Abbildung 3.12: Veröffentlichen von Elementen im DRPG in Region 2

Nach einigen Minuten sollten beide Mitglieder unter den Mitgliedern zur Verfügung stehen.

Abbildung 3.13: Dem DRPG in Region 2 hinzugefügte Elemente

Aufgabe 4: DR-Pläne in Region 2 erstellen und anpassen

In dieser Aufgabe erstellen wir die ersten Switchover-, Failover- und Drilldown starten-Pläne, die mit der Standby-DR-Schutzgruppe in Region 2 (Phoenix) verknüpft sind.

Diese Pläne sind so konzipiert, dass die Workload nahtlos von der primären Region (Region 1) in die Standby-Region (Region 2) übertragen wird.

OCI Full Stack DR füllt diese Pläne vorab mit integrierten Schritten auf, die auf den zuvor hinzugefügten Mitgliederressourcen basieren.
Da Oracle Data Guard jedoch manuell (außerhalb der Database Control Plane) konfiguriert wird, sind keine integrierten Plangruppen für Übergänge von Oracle-Datenbankrollen verfügbar.
Deshalb werden wir:
- Passen Sie die DR-Pläne mit benutzerdefinierten Plangruppen an.
- Fügen Sie Datenbank-Handler-Skripte zur Verarbeitung der Rollenübergänge während der einzelnen Plantypen hinzu (Switchover, Failover, Drill).

DR-Pläne werden immer in der Schutzgruppe mit der Standby-Rolle erstellt.

Da Region 2 (Phoenix) derzeit das Standby ist, erstellen wir dort alle anfänglichen DR-Pläne.

Aufgabe 4.1: DR-Pläne erstellen

DR-Pläne erstellen, indem Sie das DRPG in Region 2 (Phoenix) auswählen
1. Stellen Sie sicher, dass der OCI-Regionskontext Region 2 (Phoenix) ist.
2. Wählen Sie das Standby-DRPG in Region 2.
3. Navigieren Sie zur Registerkarte Pläne.
4. Klicken Sie auf Plan erstellen.
Abbildung 4.1: Grundlegende DR-Pläne in Region 2 erstellen
Switchover-Plan erstellen
1. Geben Sie einen einfachen, aber aussagekräftigen Namen für den Switchover-Plan ein. Der Name sollte so kurz wie möglich, aber leicht auf einen Blick zu verstehen sein, um Verwirrung und menschliche Fehler während einer Krise zu reduzieren.
2. Wählen Sie Plantyp als Switchover (geplant) aus.
Abbildung 4.2: Die Parameter, die zum Erstellen eines DR-Switchover-Plans erforderlich sind
Failover-Plan erstellen

Führen Sie denselben Prozess aus, um einen einfachen Failover-Plan zu erstellen, wie in der folgenden Abbildung gezeigt.
1. Geben Sie Name des Failover-Plans ein, der einfach, aber aussagekräftig ist.
2. Wählen Sie Plantyp als Failover (ungeplant) aus.
Abbildung 4.3: Die Parameter, die zum Erstellen eines DR-Failover-Plans erforderlich sind
Erstellen Sie einen Startaufgliederungsplan.

Führen Sie denselben Prozess aus, um einen einfachen Failover-Plan zu erstellen, wie in der folgenden Abbildung gezeigt.
1. Geben Sie den Namen des Startaufgliederungsplans einfach, aber aussagekräftig ein.
2. Wählen Sie Plantyp als Failover (ungeplant) aus.
Abbildung 4.4: Die Parameter, die zum Erstellen eines DR-Start-Drill-Plans erforderlich sind

Die Standby-DR-Schutzgruppe in Region 2 sollte jetzt über die drei DR-Pläne verfügen, wie in der folgenden Abbildung dargestellt. Diese verarbeiten den Übergang von Workloads von Region 1 zu Region 2. Sie erstellen ähnliche Pläne in Region 1, um Workloads in einer späteren Aufgabe von Region 2 zurück zu Region 1 zu wechseln.

Abbildung 4.5: Drei DR-Pläne anzeigen, die in Region 2 vorhanden sein müssen, bevor Sie fortfahren

Hinweis: Mit OCI Full Stack DR können Sie einen Stop-Drill-Plan erst erstellen, nachdem der Start-Drill-Plan erfolgreich ausgeführt wurde und die DR-Schutzgruppe den Status Inaktiv (Drill in Bearbeitung) aufweist.

Aufgabe 4.2: DR-Pläne mit benutzerdefinierten Plangruppen anpassen

Die in Aufgabe 4.1 erstellten DR-Pläne generieren keine integrierten Plangruppen für die Übergänge der Oracle-Datenbankrolle, da das Oracle Data Guard-Setup manuell durchgeführt wurde.

In dieser Aufgabe führen Sie folgende Schritte aus:

Erfahren Sie, wie Sie benutzerdefinierte DR-Plangruppen hinzufügen.
Definieren Sie Schritte, die zur Verwaltung von Oracle Data Guard-Rollenübergängen erforderlich sind.

Dadurch wird sichergestellt, dass Ihre DR-Pläne Failover-, Switchover- und Drill-Szenarios vollständig verarbeiten können, die eine manuell konfigurierte Data Guard-Umgebung umfassen.

Navigieren Sie zu dem in Aufgabe 4.1 erstellten Switchover-Plan, und wählen Sie Plangruppen aus.

Abbildung 4.6: So beginnen Sie mit der Anpassung des Switchover-Plans in Region 2
Fügen Sie zunächst benutzerdefinierte benutzerdefinierte DR-Plangruppen hinzu, um den DR-Workflow an die spezifischen Anforderungen der Änderungen der Oracle-Datenbankrollen anzupassen. Diese Plangruppen rufen die erforderlichen Skripte aus dem Jumphost script-iad in Region 1 auf.
Fügen Sie eine benutzerdefinierte Plangruppe zu DB-Switchover hinzu.
1. Klicken Sie auf Gruppe hinzufügen.
2. Geben Sie einen einfachen, aber aussagekräftigen Namen für die Plangruppe ein. In diesem Beispiel wird DB Switchover verwendet.
3. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript für die DB-Rollenänderung angegeben wird.
  
  Abbildung 4.7: Parameter zum Erstellen einer Plangruppe zum Ausführen einer DB-Rollenänderung
  
  Geben Sie unter Schritt "Plangruppe hinzufügen" die folgenden Informationen ein.
4. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel wird DB Switchover from IAD to PHX verwendet.
5. Wählen Sie Instanzregion aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Beispiel wird das Skript auf dem Jumphost in Region 2 ausgeführt. Wählen Sie daher Phoenix aus.
6. Wählen Sie Lokales Skript ausführen aus.
7. Wählen Sie Zielinstanz aus. Dies ist der Jumphost script-phx in Region 2.
8. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/db-switchover-iad-phx.sh.
9. Geben Sie unter Als Benutzer ausführen opc ein.
10. Klicken Sie auf Schritt hinzufügen.
  
  Abbildung 4.8: Parameter zum Hinzufügen eines Schritts für die DB-Rollenänderung
11. Prüfen Sie den hinzugefügten Schritt.
  
  Abbildung 4.9: Für DB-Rollenänderung hinzugefügt
12. Klicken Sie auf Hinzufügen.
  
  Abbildung 4.10: DB-Rollenänderungsgruppe hinzufügen
  
  Die Plangruppe ist jetzt verfügbar.
  
  Abbildung 4.11: DB-Switchover-Plangruppe
Fügen Sie einem Switchover-DR-Plan einen benutzerdefinierten Vorabprüfungsschritt hinzu. Die benutzerdefinierte Vorabprüfung wird zusammen mit den integrierten Vorabprüfungsschritten ausgeführt.
1. Gehen Sie zu Plangruppen, klicken Sie vor Prechecks-Built auf …, und wählen Sie Benutzerdefinierte Vorabprüfung hinzufügen aus.
  
  Abbildung 4.12: Benutzerdefinierte Vorabprüfung für DB-Switchover hinzufügen
2. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel wird DB Switchover precheck from IAD to PHX verwendet.
3. Wählen Sie Instanzregion aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Beispiel wird das Skript auf dem Jumphost in Region 2 ausgeführt. Wählen Sie daher Phoenix aus.
4. Wählen Sie Lokales Skript ausführen aus.
5. Wählen Sie Zielinstanz aus. Dies ist der Jumphost script-phx in der Region.
6. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/db-prechk-switchover-iad-phx.sh.
7. Geben Sie unter Als Benutzer ausführen opc ein.
8. Klicken Sie auf Schritt hinzufügen.
  
  Abbildung 4.13: Parameter zum Hinzufügen eines benutzerdefinierten Vorabprüfungsschritts für DB-Rollenänderungen
9. Prüfen Sie den hinzugefügten Schritt.
  
  Abbildung 4.14: Benutzerdefinierter Vorabprüfungsschritt für DB-Rollenänderung hinzugefügt
  
  Die Anpassung des Switchover-Plans wurde erfolgreich abgeschlossen.
  
  Abbildung 4.15: Endgültiger Switchover-Plan
Passen Sie die Failover-, Drill-Startpläne ebenso an, verwenden Sie die richtigen Zielinstanz und Skripte mit den tabellarischen Details, die in den Voraussetzungen verfügbar sind: DB-Handler-Skriptverwendung und -Anpassung.
Pläne für Failover und Drilldown starten werden wie folgt angezeigt, sobald die benutzerdefinierte Plangruppe und der benutzerdefinierte Vorabprüfungsschritt hinzugefügt werden.

Abbildung 4.16: Endgültiger Failover-Plan

Abbildung 4.17: Endgültiger Start-Drill-Plan

Aufgabe 5: Vorabprüfungen für DR-Pläne in Region 2 ausführen

Bei Switchover, Failover wurden in der Standbyregion 2 erfolgreich DR-Pläne zum Starten von Drill-Vorgängen erstellt. Diese Pläne ermöglichen es OCI Full Stack DR, Workloads von Region 1 in Region 2 zu übertragen oder DR-Drill durchzuführen. Die nachfolgende Aufgabe besteht darin, die Vorabprüfungen für die DR-Pläne auszuführen, um die Bereitschaft sicherzustellen und den Übergangsprozess zu validieren.

Aufgabe 5.1: Vorabprüfungen für den Switchover-Plan starten

Vorabprüfungen für den Switchover-DR-Plan ausführen.

Stellen Sie sicher, dass der Regionskontext auf {\b Standby Region 2} eingestellt ist.
Stellen Sie sicher, dass die richtige DR-Schutzgruppe in Region 2 ausgewählt ist. Sie muss die Standbyrolle sein.
Klicken Sie auf das Dropdown-Menü Aktionen.
Klicken Sie auf Vorabprüfungen ausführen.
Wählen Sie den Plan DB Switchover von IAD zu PHX aus.
Geben Sie den Planausführungsnamen ein, wenn er nicht automatisch generiert wird.
Klicken Sie auf Vorabprüfungen ausführen.

Abbildung 5.1: Anzeigen, wie Vorabprüfungen des Switchover-Plans ausgeführt werden
Prüfen Sie den Status Erfolgreich auf der Registerkarte Planausführungen.

Abbildung 5.2: Abgeschlossene Vorabprüfungen des Switchover-Plans anzeigen

Aufgabe 5.2: Vorabprüfungen für den Failover-Plan starten

Führen Sie die Vorabprüfungen für den Failover-DR-Plan aus.

Stellen Sie sicher, dass der Regionskontext auf {\b Standby Region 2} eingestellt ist.
Stellen Sie sicher, dass die richtige DR-Schutzgruppe in Region 2 ausgewählt ist. Sie muss die Standbyrolle sein.
Klicken Sie auf das Dropdown-Menü Aktionen.
Klicken Sie auf Vorabprüfungen ausführen.
Wählen Sie den Plan DB Failover von IAD zu PHX aus.
Geben Sie den Planausführungsnamen ein, wenn er nicht automatisch generiert wird.
Klicken Sie auf Vorabprüfungen ausführen.

Abbildung 5.3: Anzeigen, wie Vorabprüfungen des Failover-Plans ausgeführt werden
Prüfen Sie den Status Erfolgreich auf der Registerkarte Planausführungen.

Abbildung 5.4: Abgeschlossene Vorabprüfungen des Failover-Plans anzeigen

Aufgabe 5.3: Vorabprüfungen für den Startaufgliederungsplan starten

Führen Sie die Vorabprüfungen für den DR-Plan für den Startdrill aus.

Stellen Sie sicher, dass der Regionskontext auf {\b Standby Region 2} eingestellt ist.
Stellen Sie sicher, dass die richtige DR-Schutzgruppe in Region 2 ausgewählt ist. Sie muss die Standbyrolle sein.
Klicken Sie auf das Dropdown-Menü Aktionen.
Klicken Sie auf Vorabprüfungen ausführen.
Wählen Sie den Drill in PHX starten-Plan aus.
Geben Sie den Planausführungsnamen ein, wenn er nicht automatisch generiert wird.
Klicken Sie auf Vorabprüfungen ausführen.

Abbildung 5.5: Anzeigen der Ausführung von Vorabprüfungen des Start-Drill-Plans
Prüfen Sie den Status Erfolgreich auf der Registerkarte Planausführungen.

Abbildung 5.6: Abgeschlossene Vorabprüfungen des Failover-Plans anzeigen

Aufgabe 6: Switchover-Plan in Region 2 ausführen

Führen Sie den Switchover-DR-Plan aus, um den Übergang der Oracle-Datenbankrolle von Region 1 (Primär) zu Region 2 (Standby) zu initiieren.

Stellen Sie sicher, dass der Regionskontext auf {\b Standby Region 2} eingestellt ist.
Stellen Sie sicher, dass die richtige DR-Schutzgruppe in Region 2 ausgewählt ist. Sie muss die Standbyrolle sein.
Klicken Sie auf das Dropdown-Menü Aktionen.
Klicken Sie auf Plan ausführen.

Abbildung 6.1: So führen Sie den Switchover-Plan aus
Wählen Sie den Plan DB Switchover von IAD zu PHX aus.
Mit dieser Aufgabe wird der Switchover-Plan in Region 2 ausgeführt.
Heben Sie die Auswahl von Vorabprüfungen aktivieren auf, da die Vorabprüfungen bereits in Aufgabe 5 ausgeführt wurden. Wenn Sie die Ausführung wiederholen möchten, können Sie sie aktivieren.
Geben Sie den Planausführungsnamen ein, wenn er nicht automatisch generiert wird.
Klicken Sie auf Plan ausführen.

Abbildung 6.2: Anzeigen der Ausführung des Switchover-Plans
Navigieren Sie zur Registerkarte Planausführungen, und wählen Sie die Switchover-Planausführung aus.

Abbildung 6.3: Switchover-Plan wird angezeigt
Überwachen Sie den Switchover-Plan, bis die gesamte Workload vollständig von Region 1 in Region 2 übertragen wurde. Die Ausführung des Switchover-Plans wurde in ca. 8 Minuten erfolgreich abgeschlossen.

Abbildung 6.4: Eine abgeschlossene Switchover-Planausführung wird angezeigt.
Sie können den Status der Datenbankrolle anhand der in Aufgabe 1.8 angegebenen Details prüfen.

Abbildung 6.5: Data Guard-Status nach Switchover

Erwartete Ausgabe:
- adghol_site1 muss als Primäre Datenbank angezeigt werden.
- adghol_site0 muss als Physische Standbydatenbank angezeigt werden.
- Configuration Status sollte Erfolgreich angezeigt werden.
Die Rolle in der DR-Schutzgruppe wird getauscht, Region 2 wird als Primär angezeigt, und Region 1 wird als Standby angezeigt.

Abbildung 6.6: DR-Schutzrollenänderung nach Switchover

Aufgabe 7: DR-Pläne in Region 1 erstellen und anpassen

Mit der erfolgreichen Ausführung des Switchover-DR-Plans von Region 1 in Region 2 hat Region 2 jetzt die Rolle der Primärdatenbank übernommen, während Region 1 zur Standbyrolle übergegangen ist.

Befolgen Sie denselben Ansatz wie in Aufgabe 4, um die Switchover-, Failover- und DR Drill-Pläne innerhalb der DR-Schutzgruppe für Region 1 zu erstellen und anzupassen, die jetzt als Standby-Peerregion dient.

Sobald diese Pläne mit benutzerdefinierten Plangruppen und einem benutzerdefinierten Vorabprüfungsschritt erstellt und aktualisiert wurden, sehen sie wie die folgenden Bilder aus.

Abbildung 7.1: DR-Pläne in Region 1 erstellt

Abbildung 7.2: Switchover-Plan in Region 1

Abbildung 7.3: Failover-Plan in Region 1

Abbildung 7.4: Drill-Plan in Region 1 starten

Bei Bedarf können Sie den Switchover-Plan ausführen, um die Datenbank in Region 1 wieder in die primäre Rolle hochzustufen, während die Datenbank in Region 2 zum Standby wird.

Ebenso können Sie den Start-Drill-Plan ausführen, um ein Disaster-Recovery-Ereignis zu simulieren. Anschließend können Sie den Stopp-Drill-Plan erstellen und ausführen, um das System in seinen ursprünglichen Zustand zurückzusetzen.

Während des Startaufgliederungsplans wird die Datenbank von einer physischen Standbydatenbank in eine Snapshot-Standbydatenbank konvertiert. Dadurch können Anwendungen vorübergehend auf die Standbydatenbank zugreifen und zu Testzwecken mit ihr interagieren.
Während des Stopp-Drillingsplans wird die Datenbank von Snapshot-Standby in Physische Standbydatenbank zurückkonvertiert, um sicherzustellen, dass sie mit der primären Datenbank neu synchronisiert wird.

Nächste Schritte

Weitere Informationen finden Sie in der Dokumentation zu OCI Full Stack DR, Oracle Base Database Service und Oracle Data Guard im Abschnitt Zugehörige Links.

Bestätigungen

Autor – Suraj Ramesh (Senior Principal Product Manager für OCI Full Stack DR)
Mitwirkende – Santhosh Shankaramanchi (Consulting Member of Technical Staff for OCI Full Stack DR)

Weitere Lernressourcen

Sehen Sie sich weitere Übungen zu docs.oracle.com/learn an, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning YouTube-Kanal zu. Besuchen Sie außerdem education.oracle.com/learning-explorer, um ein Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.

Titel und Copyright-Informationen

Automate Role Changes for Manually Configured Oracle Data Guard in OCI Database Services Using OCI Full Stack DR and Custom Scripts

G45722-03

Oracle und/oder verbundene Unternehmen.