Oracle 12.2 PDB Migration mit dem DataGuard-Broker – „DataGuard on PDB level“

23. Januar 2018 Aus Von Markus Flechtner

Mit Oracle 12.2 kann der DataGuard-Broker beim Verschieben einer Pluggable Database von einer Container-Datenbank in eine andere helfen. Je nachdem ob die Ausgangsdatenbank eine Primär- bzw. Standby-Datenbank ist, nennt Oracle das Verfahren „PDB Migration“ bzw. „PDB Failover“. Etwas verkürzt wird es auch oftmals als „DataGuard auf PDB-Ebene“ bezeichnet. Wie funktioniert das Ganze?

Zuerst einmal funktioniert es leider nicht „out-of-the-box“. Es sind zusätzliche Patches erforderlich. Auf meinem Test-System ist der Patch-Stand wie folgt:

oracle@vm111:~/ [rdbms12201] $ORACLE_HOME/OPatch/opatch lspatches
26970717;
21068751;
26635944;OJVM RELEASE UPDATE: 12.2.0.1.171017 (26635944)
26710464;Database Release Update : 12.2.0.1.171017 (26710464)

OPatch succeeded.

Neben den Release-Updates für Datenbank und JVM sind die Patches für folgende Bugs installiert:

26970717 – BROKER PDB MIGRATE SHOULD STOP PROCESSING IF UNABLE TO CREATE XML MANIFEST
21068751 – CDB : AUTOMATIC RECOVERY AT PDB FIRST OPEN AFTER PDB SHUTDOWN ABORT

Diese Patches gibt es in unterschiedlichen Ausgaben, je nach Releasestand (Release-Update) der Datenbank-Software. Darauf muss man beim Download achten.

Die Testkonfiguration bei mir sieht wie folgt aus:

zwei virtuelle Server, vm111 und vm112, beide mit Oracle Linux 7.4
zwei Datenbanken, CDB111 und CDB112 auf dem Server vm111 bzw. vm112 und den zugehörigen Standby-Datenbanken auf dem jeweils anderen Server
eine PDB (PDBRELOC) in der CDB111
beide Container-Datenbanken laufen mit Local Undo (Default in Oracle 12.2)

oracle@vm112:~/ [CDB111] dgmgrl

DGMGRL for Linux: Release 12.2.0.1.0 - Production on Mon Jan 22 08:43:59 2018
Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved.
Welcome to DGMGRL, type "help" for information.

DGMGRL> connect sys/manager@CDB111_SITE1
Connected to "CDB111_SITE1"
Connected as SYSDBA.

DGMGRL> show configuration;
Configuration - CDB111

  Protection Mode: MaxAvailability
  Members:
  cdb111_site1 - Primary database
    cdb111_site2 - Physical standby database

Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS   (status updated 41 seconds ago)

oracle@vm112:~/ [CDB111] dgmgrl

DGMGRL for Linux: Release 12.2.0.1.0 - Production on Mon Jan 22 08:44:34 2018
Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved.
Welcome to DGMGRL, type "help" for information.

DGMGRL> connect sys/manager@CDB112_SITE1

Connected to "CDB112_SITE1"
Connected as SYSDBA.

DGMGRL> show configuration

Configuration - CDB112

  Protection Mode: MaxAvailability
  Members:
  cdb112_site1 - Primary database
    cdb112_site2 - Physical standby database

Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS   (status updated 32 seconds ago)

oracle@vm112:~/ [CDB111] sqlplush sys/manager@CDB111_SITE1 as sysdba

SQL*Plus: Release 12.2.0.1.0 Production on Mon Jan 22 08:45:19 2018
Copyright (c) 1982, 2016, Oracle.  All rights reserved.

Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

SQL> select host_name from v$instance;
HOST_NAME
----------------------------------------
vm111.markusdba.local

SQL> show pdbs
    CON_ID CON_NAME   OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED  READ ONLY  NO
3 PDBRELOC  READ WRITE NO

SQL> exit

In diesem Test wollen wir die PDB PDBRELOC von der Standby-Datenbank CDB111 auf vm112 in die Primär-Datenbank CDB112 auf dem gleichen Server migrieren. In der Oracle-Diktion ist es ein „PDB-Failover“.

DGMGRL> connect sys/manager@cdb111_site2

Connected to "CDB111_SITE2"
Connected as SYSDBA.

DGMGRL> migrate pluggable database immediate pdbreloc to Container cdb112_site1 using '/tmp/pdbreloc.xml' connect as sys/manager@CDB112_SITE1;

Connected to "CDB112_SITE1"
Connected as SYSDBA.

Warning: either source or destination multitenant container database does not have local undo enabled.

Beginning migration of pluggable database PDBRELOC.

Source multitenant container database is CDB111_SITE2.
Destination multitenant container database is CDB112_SITE1.

Connected to "CDB111_SITE1"

Closing pluggable database PDBRELOC on all instances of multitenant container database cdb111_site1.
Pluggable database PDBRELOC on database CDB111_SITE2 lags its primary
database, cdb111_site1, by 241 seconds.

Continuing with migration of pluggable database PDBRELOC to multitenant container database CDB112_SITE1.
Stopping Redo Apply services on source multitenant container database CDB111_SITE2.

Opening database CDB111_SITE2.
Opening pluggable database PDBRELOC on source multitenant container database CDB111_SITE2 to prepare for migration.
Pluggable database description will be written to /tmp/pdbreloc.xml.
Closing pluggable database PDBRELOC on all instances of multitenant container database CDB111_SITE2.
Disabling media recovery for pluggable database PDBRELOC.
Closing database CDB111_SITE2.
Restarting redo apply services on source multitenant container database CDB111_SITE2.
Creating pluggable database PDBRELOC on multitenant container database CDB112_SITE1.
Opening pluggable database PDBRELOC on all instances of multitenant container database CDB112_SITE1.
Unplugging pluggable database PDBRELOC from multitenant container database cdb111_site1.
Pluggable database description will be written to /tmp/ora_tfilpzTwbS.xml.
Dropping pluggable database PDBRELOC from multitenant container database cdb111_site1.
Migration of pluggable database PDBRELOC completed.
Succeeded.

Die Warnung bzgl. des Undo-Modes ist leider etwas irreführend, denn in meinem Fall sind beiden Datenbanken mit „LOCAL UNDO“ konfiguriert.

Generell versucht Oracle, bei einem PDB Failover, diesen ohne Datenverlust durchzuführen. Wenn es – wie in meinem Fall – ein Delta zwischen Primary und Standby-Datenbank gibt, muss mit „IMMEDIATE“ gearbeitet werden.

Wie sieht es jetzt in der CDB112 aus?

SQL> show pdbs

CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
 2 PDB$SEED READ ONLY NO
 3 PDBRELOC MOUNTED

SQL> alter pluggable database PDBRELOC open;
Pluggable database altered.

Damit ist die PDB geöffnet und der „PDB-Failover“ ist abgeschlossen. Wenn die tnsnames-Einträge der Clients passend konfiguriert sind, d.h. beide Server sind dort eingetragen, dann können sie sich anmelden und mit der PDB arbeiten.

Die Dateien der PDB sind allerdings weiterhin an ihrem alten Speicherort:

SQL> select name from v$datafile where con_id>2;NAME
-------------------------------------------
/u01/oradata/CDB111/PDBRELOC/system01.dbf
/u01/oradata/CDB111/PDBRELOC/sysaux01.dbf
/u01/oradata/CDB111/PDBRELOC/undotbs101.dbf
/u01/oradata/CDB111/PDBRELOC/users01.dbf

Ggf. kann es daher hilfreich sein, die Dateien mittels „ALTER DATABASE MOVE DATAFILE .. ONLINE“ in ein „passenderes“ Verzeichnis (in meinem Beispiel z.B. /u01/oradata/CDB112/PDBRELOC/“ zu verschieben.

Abschließend noch der Blick in die alert.log-Datei der Datenbank CDB112:

Auf der Primärseite:

2018-01-22T10:03:15.639992+01:00
create pluggable database PDBRELOC using '/tmp/pdbreloc.xml' nocopy standbys=none tempfile reuse
2018-01-22T10:03:15.735715+01:00
PDBRELOC(3):Endian type of dictionary set to little
****************************************************************
Pluggable Database PDBRELOC with pdb id - 3 is created as UNUSABLE.
If any errors are encountered before the pdb is marked as NEW,
then the pdb must be dropped
local undo-1, localundoscn-0x00000000000000e0
****************************************************************
PDBRELOC(3):Autotune of undo retention is turned on.
PDBRELOC(3):[14643] Successfully onlined Undo Tablespace 2.
PDBRELOC(3):Undo initialization finished serial:0 start:5385462 end:5385509 diff:47 ms (0.0 seconds)
PDBRELOC(3):Database Characterset for PDBRELOC is AL32UTF8
PDBRELOC(3):JIT: pid 14643 requesting stop
Completed: create pluggable database PDBRELOC using '/tmp/pdbreloc.xml' nocopy standbys=none tempfile reuse
alter pluggable database PDBRELOC open instances=all
PDBRELOC(3):Autotune of undo retention is turned on.
PDBRELOC(3):Endian type of dictionary set to little
PDBRELOC(3):[14643] Successfully onlined Undo Tablespace 2.
PDBRELOC(3):Undo initialization finished serial:0 start:5385884 end:5385981 diff:97 ms (0.1 seconds)
PDBRELOC(3):Deleting old file#145 from file$
PDBRELOC(3):Deleting old file#146 from file$
PDBRELOC(3):Deleting old file#147 from file$
PDBRELOC(3):Deleting old file#148 from file$
PDBRELOC(3):Adding new file#96 to file$(old file#145)
PDBRELOC(3):Adding new file#97 to file$(old file#146)
PDBRELOC(3):Adding new file#98 to file$(old file#147)
PDBRELOC(3):Adding new file#99 to file$(old file#148)
PDBRELOC(3):Successfully created internal service pdbreloc.markusdba.local at open
2018-01-22T10:03:16.693505+01:00
****************************************************************
Post plug operations are now complete.
Pluggable database PDBRELOC with pdb id - 3 is now marked as NEW.
****************************************************************
PDBRELOC(3):Database Characterset for PDBRELOC is AL32UTF8
2018-01-22T10:03:18.762461+01:00
PDBRELOC(3):Opening pdb with no Resource Manager plan active
PDBRELOC(3):Mon Jan 22 10:03:18 2018
PDBRELOC(3):Logminer Bld: Build started
2018-01-22T10:03:19.906881+01:00
PDBRELOC(3):Mon Jan 22 10:03:19 2018
PDBRELOC(3):Logminer Bld: Done
Pluggable database PDBRELOC opened read write
Completed: alter pluggable database PDBRELOC open instances=all

Da die PDB mit „STANDBYS=NONE“ angelegt wird, ist sie nicht in der Standby-Datenbank der CDB112 enthalten:

SQL> show pdbs

CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
 2 PDB$SEED MOUNTED
 3 PDBRELOC MOUNTED

SQL> select name from v$datafile where con_id>2;
NAME
-----------------------------------------------------------
/u00/app/oracle/product/12.2.0.1/dbs/UNNAMED00096
/u00/app/oracle/product/12.2.0.1/dbs/UNNAMED00097
/u00/app/oracle/product/12.2.0.1/dbs/UNNAMED00098
/u00/app/oracle/product/12.2.0.1/dbs/UNNAMED00099

Über das in der Support-Note 1916648.1 beschriebene Verfahren kann (und sollte!) sie wieder in die DataGuard-Konfiguration aufgenommen werden, damit die Verfügbarkeit der PDB wieder sichergestellt ist.

MOS-Notes:

PDB Failover in a Data Guard environment: Using Data Guard Broker to Unplug a Single Failed PDB from a Standby Database and Plugging into a New Container or Migrate a Single PDB into a New Conainer (Doc ID 2088201.1)
Making Use Deferred PDB Recovery and the STANDBYS=NONE Feature with Oracle Multitenant (Doc ID 1916648.1)

Werbung (Amazon-Partner-Link)

Kategorie12cR2 Multitenant

SchlagwörterDataGuard Hochverfügbarkeit Multitenant PDB Failover