Flashback Pluggable Database
Oracle 12.2 steht in den Startlöchern und damit die Funktionalität des Flashback Pluggable Database. Allerdings wird es wohl noch etwas dauern, bis es die 12.2 in die Produktion schafft und außerdem brauchen wir noch Erfahrung damit, was es heißt, dass jede PDB ein UNDO-Tablespace bekommt. Denn das ist die Voraussetzung für das Flashback Pluggable Database. Aber es geht auch schon mit der Version 12.1.0.2 – und zwar dann, wenn es sich um eine Data Guard Konfiguration handelt. Interessant ist diese Konfiguration auch deshalb, weil es nach der Prozedur zwei Pluggable Databases gibt. Das Original und die Kopie auf dem älteren Stand.
Die Ausgangsbasis ist folgende Konfiguration:
- Server 1: beethovens1 mit der primären Datenbank LUDWIG_S1 und der PDB DEMO
- server 2: beethovens2 mit der Standby Datenbank LUDWIG_S2
Ziel ist es, die Pluggable Database DEMO als DEMO_CLONE auf dem Stand 10:00 Uhr zurückzusetzen und über Data Guard wieder zu synchronisieren.
Flashback Standby Datenbank
Generell wäre es in unserem Fall möglich, die PDB aus einer Read-Only Kopie zu erstellen. Da es aber oftmals notwendig ist, zunächst einige Änderungen an der zurückgerollten Datenbank vorzunehmen (z.B. Accounts entsperren), verwenden wir hier die Snapshot Standby Funktion.
dgmgrl sysdg/sysdgLUDWIG@LUDWIG_S2
DGMGRL> show configuration
Configuration - LUDWIG_DG
Protection Mode: MaxAvailability
Members:
LUDWIG_S1 - Primary database
LUDWIG_S2 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 29 seconds ago)
DGMGRL> show database "LUDWIG_S2"
Database - LUDWIG_S2
Enterprise Manager Name: LUDWIG_S2.hv.devk.de
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 1 second ago)
Apply Lag: 0 seconds (computed 1 second ago)
Average Apply Rate: 5.00 KByte/s
Real Time Query: OFF
Instance(s):
LUDWIG1 (apply instance)
LUDWIG2
Database Status:
SUCCESS
DGMGRL> CONVERT DATABASE "LUDWIG_S2" TO SNAPSHOT STANDBY;
Converting database "LUDWIG_S2" to a Snapshot Standby database, please wait...
Database "LUDWIG_S2" converted successfully
DGMGRL> EXIT;
oracle@beethovens2[LUDWIG1]%:~> sqlplus / as sysdba
SQL> select db_unique_name, database_role, open_mode, flashback_on from v$database;
DB_UNIQUE_NAME DATABASE_ROLE OPEN_MODE
------------------------------ ---------------- --------------------
LUDWIG_S2 SNAPSHOT STANDBY READ WRITE
SQL> exit
Wie man sieht, ist die Standby Datenbank jetzt zum Lesen und Schreiben geöffnet. Jetzt kann ein Guaranteed Restore Point erstellt und danach die Datenbank auf den gewünschten Zeitpunkt zurückgesetzt werden:
oracle@beethovens2[LUDWIG1]%:~> sqlplus / as sysdba
SQL> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>startup mount
ORACLE instance started.
Total System Global Area 1.5737E+10 bytes
Fixed Size 3729312 bytes
Variable Size 2919237728 bytes
Database Buffers 1.2784E+10 bytes
Redo Buffers 29822976 bytes
Database mounted.
SQL> CREATE RESTORE POINT before_flashback GUARANTEE FLASHBACK DATABASE;
Restore point created.
SQL> FLASHBACK DATABASE TO TIMESTAMP to_date('23.02.2017 10:00:00','DD.MM.YYYY HH24:MI:SS');
Flashback complete.
SQL> ALTER DATABASE OPEN RESETLOGS;
Database altered.
Da die Datenbank vorher schon zum Lesen und Schreiben geöffnet war, ist nichts weiter zu tun. Falls man möchte, könnte man jetzt die PDB auch über die Erstellung eines Manifests (UNPLUG INTO XML) kopieren. In diesem Fall verwenden wir jeoch einen Datenbank Link.
oracle@beethovens1[LUDWIG1]%:~> sqlplus / as sysdba
SQL> !mkdir /u03/temp/LUDWIG/DEMO_CLONE
SQL> CREATE DATABASE LINK "LUDWIG_S2" CONNECT TO c##johannes
IDENTIFIED BY abc123def USING 'LUDWIG_S2';
SQL> CREATE PLUGGABLE DATABASE demo_clone FROM DEMO@LUDWIG_S2
file_name_convert=('DEMO','DEMO_CLONE');
Die PDB DEMO_CLONE wird jetzt jedoch noch nicht geöffnet, weil wir zunächst die Data Guard Konfiguration wieder aktivieren müssen. Dafür brauchen wir eine geschlossene PDB (siehe auch Blog „PDB Cloning mit DataGuard“). Bevor wir allerdings die Standby Datenbank wieder „vorrollen“ können, müssen wir zunächst die PDB$SEED öffnen, ansonsten meldet diese den folgenden Fehler:
SQL> flashback database to restore point before_flashback; flashback database to restore point before_flashback * ERROR at line 1: ORA-01122: database file 2 failed verification check ORA-01110: data file 2: '/u03/oradata/TC02/pdbshared/pdbseed/system.dbf' ORA-01207: file is more recent than control file - old control file
Offiziell ist es nicht möglich bzw. vorgesehen, die SEED-Datenbank zum Schreiben zu öffnen – aber wie sollte sie dann erstellt und gepatcht werden? Über den SESSION Parameter [inlinecode]_oracle_script[/inlinecode] (geschickt – wer vermutet da schon die Seed-Datenbank) kann man die PDB$SEED öffnen und anpassen. Das wollen wir aber gar nicht. Es genügt, sie einmal kurz zum schreiben zu öffnen und dann wieder auf Read-Only zu setzen. Schon funktioniert das anschließende „Flashback Database to GRP“.
oracle@beethovens2[LUDWIG1]%:~> sqlplus / as sysdba SQL> ALTER SESSION SET "_oracle_script"=TRUE; Session altered. SQL> ALTER PLUGGABLE DATABASE pdb$seed OPEN READ WRITE FORCE; Pluggable database altered. SQL> ALTER PLUGGABLE DATABASE pdb$seed OPEN READ ONLY FORCE; Pluggable database altered. SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area 1.5737E+10 bytes Fixed Size 3729312 bytes Variable Size 2919237728 bytes Database Buffers 1.2784E+10 bytes Redo Buffers 29822976 bytes Database mounted. SQL> FLASHBACK DATABASE TO RESTORE POINT before_flashback; Flashback complete. SQL> DROP RESTORE POINT before_flashback;
Jetzt kann die „Snapshot“ Standby wieder in eine „Physical“ Standby konvertiert werden.
oracle@beethovens1[LUDWIG1]% dgmgrl sysdg/sysdgLUDWIG@LUDWIG_S1 DGMGRL> convert database "LUDWIG_S2" to physical standby; Converting database "LUDWIG_S2" to a Physical Standby database, please wait... Database "LUDWIG_S2" converted successfully
Eigentlich wären wir jetzt fertig. Aber da ist noch das Problem mit der Erstellung von PDBs in einer Data Guard Umgebung. Die [inlinecode]DEMO_CLONE[/inlinecode] PDB wurde ja neu angelegt und es wurde noch kein Recovery der Standby Datenbank durchgeführt. Aber so, wie im Blog „PDB Cloning mit DataGuard“ beschrieben, reicht es, die Dateien auf die Standby Seite zu übertragen und dann für jedes Datafile einmal den Apply-Prozess zu aktivieren. Danach ist die Data Guard Konfiguration wieder synchronisiert und wir haben – ohne Downtime – einen Clone unserer produktiven PDB auf einem älteren Stand.
Viel Spaß beim Probieren und über Feedback würden ich mich freuen!