Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Die Standby-Datenbank für Data Guard auf Google Cloud NetApp Volumes finalisieren

06/25/2026 Beitragende

PDFs

Die Standby-Datenbank für Oracle Data Guard auf Google Cloud NetApp Volumes wird finalisiert, indem Standby-Wiederherstellungsprotokolldateien erstellt, Flashback-Datenbank aktiviert, Redo-Shipping aktiviert und der Data Guard-Status überprüft werden.

Tierspezifisch: Dieses Verfahren ist nur für die Prod HA (Data Guard + FSFO) Tier erforderlich.

Schritt 1: Erstellen von Standby Wiederherstellungsprotokoll-Logdateien

Standby-Wiederherstellungsprotokolldateien auf beiden Datenbankhosts erstellen, um Fast-Start Failover zu unterstützen. Die Größe muss größer oder gleich dem größten primären Online-Wiederherstellungsprotokoll sein, und die Anzahl sollte (Online-Gruppen pro Thread) + 1 entsprechen. Nach dem GCNV-Seeding die Standby-Wiederherstellungsprotokolle auf dem Standby-Host löschen und neu erstellen, um replizierte Pfade zu korrigieren.

Standby-Wiederherstellungsprotokoll-Logdateien auf der primären Datenbank erstellen (orcl:

ALTER SYSTEM SET db_create_file_dest='+DATA' SCOPE=BOTH;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 ('+DATA') SIZE 1024M;
-- repeat (online log groups + 1) times

Standby-Wiederherstellungsprotokolldateien auf der Standby-Datenbank (orcls nach dem GCNV-Seeding löschen und neu erstellen. Replizierte Pfade unter +DATA/ORCL/… cause ORA-19527 / ORA-16086 bis zum Wiederaufbau:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER SYSTEM SET standby_file_management=MANUAL SCOPE=BOTH;
-- DROP STANDBY LOGFILE GROUP for each group# in v$standby_log;
ALTER SYSTEM SET db_create_file_dest='+DATA' SCOPE=BOTH;
ALTER SYSTEM SET standby_file_management=AUTO SCOPE=BOTH;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 ('+DATA') SIZE 1024M;
-- repeat (online groups + 1) times; one member per group
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

Schritt 2: Flashback aktivieren und Recovery starten

Die Flashback Datenbank auf dem Standby-System wird aktiviert, um die automatische Wiederherstellung nach einem Failover zu unterstützen, anschließend wird die verwaltete Wiederherstellung mit Echtzeit gestartet. Flashback muss vor dem Start der verwalteten Wiederherstellung aktiviert sein, da dies bei aktivem MRP nicht möglich ist.

Die Standby-Datenbank herunterfahren, im MOUNT-Modus neu starten und die Flashback-Datenbank auf oracdb2 aktivieren:

# On oracdb2
sudo -u oracle bash -c '
. ~/.bash_profile
export ORACLE_SID=orcls
sqlplus / as sysdba <<SQL
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER SYSTEM SET db_flashback_retention_target=1440 SCOPE=BOTH;
ALTER DATABASE FLASHBACK ON;
EXIT
SQL'

Verwaltete Wiederherstellung mit Echtzeit-Apply starten:

sudo -u oracle bash -c '
. ~/.bash_profile
export ORACLE_SID=orcls
sqlplus / as sysdba <<SQL
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
EXIT
SQL'

`USING CURRENT LOGFILE`ermöglicht die Echtzeit-Anwendung (Wiederherstellungsprotokoll wird angewendet, sobald es in den SRLs landet).

Schritt 3: Wiederherstellungsprotokoll-Versand aktivieren

Aktivieren des Transports des Wiederherstellungsprotokolls von der Primärdatenbank zur Standby-Datenbank durch Aktivieren von LOG_ARCHIVE_DEST_STATE_2, was in Schritt 2 des Standby-Initialisierungsverfahrens bewusst auf DEFER gesetzt wurde, um ORA-12154 Fehler während der Standby-Erstellung zu unterdrücken.

Zu LOG_ARCHIVE_DEST_STATE_2 und ENABLE wechseln und einen Log-Switch erzwingen, um die Wiederherstellungsprotokoll-Übertragung zu initiieren:

sudo -u oracle bash -c '
. ~/.bash_profile
sqlplus / as sysdba <<SQL
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;
ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM ARCHIVE LOG CURRENT;
EXIT
SQL'

Überprüfen, ob das Wiederherstellungsprotokoll ordnungsgemäß übertragen wird:
```
sudo -u oracle bash -c '
. ~/.bash_profile
sqlplus / as sysdba <<SQL
SELECT dest_id, status, error FROM v\$archive_dest_status WHERE dest_id IN (1,2);
EXIT
SQL'
# Expected: dest_id=2, STATUS=VALID, ERROR null.
```
Falls dest_2 ORA-12154 angezeigt wird, den Primary neu starten. Nach Schritt 1: Aktivieren Sie den Broker auf beiden Datenbanken den Transport über DGMGRL verwalten.

Schritt 4: Data Guard Status überprüfen

Es sollte sichergestellt sein, dass sich die primäre Datenbank im READ WRITE-Modus befindet und die Standby-Datenbank mit verwaltetem Recovery eingebunden ist, wobei Wiederherstellungsprotokolle angewendet werden.

Die primäre Datenbankrolle und der Öffnungsmodus auf oracdb1 werden überprüft:

sudo -u oracle sqlplus -s / as sysdba \
  <<<"SELECT database_role || ' | ' || open_mode FROM v\$database;"
# Expected: PRIMARY | READ WRITE

Die Rolle der Standby-Datenbank, den Open Mode und den Status des Managed Recovery auf oracdb2 überprüfen:

gcloud compute ssh oracdb2 --tunnel-through-iap --zone=us-west1-b

sudo -u oracle bash <<'BASH'
. ~/.bash_profile
export ORACLE_SID=orcls

sqlplus -s / as sysdba <<'SQL'
SELECT database_role || ' | ' || open_mode
FROM v$database;

SELECT process, status, sequence#
FROM v$managed_standby
WHERE process IN ('MRP0','RFS');

EXIT
SQL
BASH

Erwartet im Standby-Modus: PHYSICAL STANDBY | MOUNTED; MRP0 mit APPLYING_LOG.

Wenn der Standby-Server MOUNTED meldet, die Anwendung jedoch nicht läuft, sollte die verwaltete Wiederherstellung auf oracdb2 neu gestartet werden:

sudo -u oracle bash -c '
. ~/.bash_profile
export ORACLE_SID=orcls
sqlplus / as sysdba <<SQL
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
EXIT
SQL'

Was kommt als Nächstes?

Um die automatisierte Rollenverwaltung und den Ausfallschutz zu aktivieren, mit Konfigurieren Sie Oracle Data Guard Broker, Fast-Start Failover und den Observer fortfahren.