Die Herausforderung
Beim Einsatz von Multitenant Database in einer Data Guard Umgebung gibt es einige Besonderheiten. Nachfolgend wird an einem Beispiel erklärt, wie man eine PDB aus einer existierenden heraus erstellt und dabei die Data Guard Seite wieder synchronisiert. In diesem Beispiel wird Oracle 12 Release 1 (12.1.0.2) und Data Guard ohne Real Time Apply (also kein Active Data Guard) verwendet.
Warum ist das eine Herausforderung?
Wenn man eine Pluggable Database aus der PDB$SEED erstellt, funktioniert das in einer Data Guard Umgebung sehr gut, d.h. auf der Standby Seite werden die Datendateien angelegt und entsprechend synchronisiert.
SQL> CREATE PLUGGABLE DATABASE <PDBNAME>
ADMIN USER ... IDENTIFIED BY ... FILE_NAME_CONVERT=...;
Wenn man aber eine Pluggable Database aus einer anderen heraus erstellt (Cloning), dann werden die Dateien nicht übertragen und die Data Guard Konfiguration meldet einen Fehler:
SQL> CREATE PLUGGABLE DATABASE <PDBNEU>
FROM <PDBALT> FILE_NAME_CONVERT=...;
Data Guard:
<Standby DBNAME> - Physical standby database
Error: ORA-16766: Redo Apply is stopped
Laut der Oracle Dokumentation soll man die Pluggable Database mit der Option „STANDBYS=NONE“ anlegen, dann werden auf der Standby Seite „Dummy“ Dateien angelegt und man kann die fehlenden Dateien kopieren und mit „ALTER DATABASE CREATE DATAFILE“ in die Standby Datenbank integrieren. Dafür muss allerdings die Standby Datenbank Read-Only geöffnet werden. Keine Angst, da der Apply-Prozess durch den Fehler gestoppt ist, ist das kein Lizenzverstoß bezüglich der „Active Data Guard“.
Vergisst man die Option „STANDBYS=NONE“ dann kommt man um ein Recovery der Standby Seite nicht herum. Und hier fangen jetzt meine Tests an und ich würde mich freuen, wenn der ein oder andere dazu seinen Kommentar abgeben würde:
Erstellen einer PDB
Zunächst wird die PDB auf der primären Datenbank ganz normal aus einer existierenden erstellt. Übrigens ist es schon mit 12.2.0.1 und dem Patchset von Oktober 2016 (glaube ich zumindest) möglich, die Quell-PDB geöffnet zu lassen. Allerdings wird sie für die Dauer der Kopie eingefroren.
SQL> CREATE PLUGGABLE DATABASE pdbneu
FROM pdbalt FILE_NAME_CONVERT=('pdbalt','pdbneu');
SELECT d.name
FROM v$datafile d, v$pdbs p
WHERE d.con_id = p.con_id
AND p.name = 'PDBNEU';
...
/u02/oradata/LUDWIG/pdbneu/system01.dbf
/u02/oradata/LUDWIG/pdbneu/sysaux01.dbf
/u02/oradata/LUDWIG/pdbneu/users01.dbf
Die PDB wird jetzt nicht geöffnet sondern die Datendateien werden auf die Standby Seite kopiert:
oracle% scp -r /u02/oradata/LUDWIG/pdbneu bach:/u02/oradata/LUDWIG
Jetzt kommt der Trick:
Wenn man den Apply-Prozess so oft wieder startet, wie die PDB Datendateien hat (im Beispiel also drei Mal), dann synchronisiert sich Data Guard wieder und die Konfiguration funktioniert. Danach kann man die PDB auf der Primären Datenbank öffnen.
dgmgrl /
DGMGRL> show configuration
Configuration - LUDWIG_DG
Protection Mode: MaxAvailability
Members:
LUDWIG_S1 - Primary database
LUDWIG_S2 - Physical standby database
Error: ORA-16766: Redo Apply is stopped
Fast-Start Failover: DISABLED
Configuration Status:
ERROR (status updated 35 seconds ago)
DGMGRL> edit database "LUDWIG_S2" set state='APPLY-ON';
Succeeded.
DGMGRL> edit database "LUDWIG_S2" set state='APPLY-ON';
Succeeded.
DGMGRL> edit database "LUDWIG_S2" set state='APPLY-ON';
Succeeded.
DGMGRL> show database "LUDWIG_S2"
Database - LUDWIG_S2
Enterprise Manager Name: LUDWIG_S2
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 0 seconds ago)
Average Apply Rate: 18.00 KByte/s
Real Time Query: OFF
Instance(s):
LUDWIG1 (apply instance)
LUDWIG2
Database Status:
SUCCESS
Kann / darf man das machen? Es hat zumindest funktioniert und lässt sich einfach skripten (zumindest nach meiner Ansicht).