Die Aufgabenstellung
Es soll eine Kopie einer Datenbank erzeugt werden, es ist aber (aus diversen Gründen) nicht möglich, dies per Backup und Restore zu lösen. Data Pump scheidet aus Volumengründen ebenfalls aus.
Was für Optionen bleiben?
Man kann mittels Dataguard eine Standby-Datenbank erzeugen.
Diese kann dann in eine Primary-Datenbank umgewandelt werden, ohne die bereits vorhandene Primary-Datenbank zu beeinflussen.
Wie funktioniert es?
Nach dem Erzeugen der Standby DB DBC sieht das Bild im Broker so aus:
DGMGRL> show configuration;
Configuration - DB_config
Protection Mode: MaxAvailability
Members:
DBA - Primary database
DBC - Physical standby database
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 32 seconds ago)
Im ersten Schritt wird Standby DB DBC aus der Brokerkonfiguration entfernt:
DGMGRL> disable database DBC;
Disabled.
DGMGRL> remove database DBC;
Removed database "DBC" from the configuration
Dann wird der automatische Brokerstart auf der Standby-DB abgeschaltet.
SYS@DBC1> alter system set dg_broker_start=false scope=both;
System altered.
Das noch laufende Recovery wird dann abgebrochen.
SYS@DBC1> alter database recover managed standby database cancel;
Database altered.
Im Alertlog sieht man:
alter database recover managed standby database cancel
2023-11-26T07:46:39.891980+01:00
PR00 (PID:125306): MRP0: Background Media Recovery cancelled with status 16037
2023-11-26T07:46:39.892667+01:00
Errors in file /app/oracle/admin/DBC/diag/rdbms/DBC/DBC1/trace/DBC1_pr00_125306.trc:
ORA-16037: user requested cancel of managed recovery operation
PR00 (PID:125306): Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
2023-11-26T07:46:41.027601+01:00
Recovered data files to a consistent state at change 15170711719847
2023-11-26T07:46:44.368201+01:00
Stopping change tracking
2023-11-26T07:46:44.368825+01:00
Errors in file /app/oracle/admin/DBC/diag/rdbms/DBC/DBC1/trace/DBC1_pr00_125306.trc:
ORA-16037: user requested cancel of managed recovery operation
2023-11-26T07:46:44.397719+01:00
Background Media Recovery process shutdown (DBC1)
2023-11-26T07:46:44.877840+01:00
Managed Standby Recovery Canceled (DBC1)
Completed: alter database recover managed standby database cancel
Nun kommt der "magische" Befehl, der die Standby-Kopie in eine Primary-DB umwandelt:
SYS@DBC1> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
Database altered.
Dies wird ebenfalls im Alertlog protokolliert:
ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE
2023-11-26T07:47:58.331774+01:00
ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE [Process Id: 136982] (DBC1)
2023-11-26T07:47:58.343649+01:00
...
.... (PID:136982): Begin: SRL archival
.... (PID:136982): End: SRL archival
2023-11-26T07:48:00.795365+01:00
RESETLOGS after incomplete recovery UNTIL CHANGE 15170711719847 time 11/26/2023 07:43:15
Resetting resetlogs activation ID 4185568358 (0xf97ab466)
...
2023-11-26T07:48:04.458303+01:00
Standby became primary SCN: 15170711719845
2023-11-26T07:48:04.458987+01:00
Setting recovery target incarnation to 13
2023-11-26T07:48:04.466318+01:00
...
2023-11-26T07:48:04.501251+01:00
.... (PID:136982): Database role cleared from PHYSICAL STANDBY [kcvs.c:1114]
ACTIVATE STANDBY: Complete - Database mounted as primary
Completed: ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE
Abschließend sollte die DBID der Datenbankkopie geändert werden, um spätere Kollisionen zu vermeiden.
Referenz
support.oracle.com: Doc ID 2074686.1 (How To Remove Standby Database And Convert It to Standalone Database )
Matthias Mann
