Blog Johannes

Blog Johannes

johannes blog ohne logo

Blog Johannes

Flashback PDB mit Version 12.1.0.2

Veröffentlicht: 24. Februar 2017
Geschrieben von Johannes Ahrends

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.

oracle@beethovens2[LUDWIG1]% 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;

racle@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 "_oracle_script" (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 DEMO_CLONE 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!

Johannes Ahrends

Twitter CarajanDB

CarajanDB GmbH

Siemensstr. 25  50374 Erftstadt

Fon: +49 (2235) 170 91 83

Fax: +49 (2235) 170 79 78

Mail: info@carajandb.com

 

carajan-db-logo