Upgrade und Migration einer Non-Container-DB (12.1.0.2) in eine Container-DB (12.2.0.1)

01.
März
2018
Veröffentlicht von: Matthias Meyer

In diesem Monatstipp geht es um die Migration einer Non-Container Datenbank in die Container Architektur. Dabei soll auch gleichzeitig ein Upgrade auf die Version 12.2.0.1 erfolgen.

Notwendigkeit des Umstiegs

Seitdem im März 2013 die Version 12c erschienen ist, wird verstärkt über das zentrale neue Feature "Pluggable Database" diskutiert. Für die Einen endlich die Möglichkeit, ihre zahlreichen, kleinen (ähnlich gestrickten) Datenbanksysteme in einem zentralen DBMS zu konsolidieren und sich damit die Verwaltung zu vereinfachen, für die Anderen aus den verschiedensten Gründen nicht umsetzbar. Nicht zuletzt wegen der anfallenden Lizenzkosten für die Multitenant Option.

Aber egal, wie sehr man diese neue Architektur auch ablehnt, wer Oracle weiterhin produktiv einsetzen und dabei auch Support "genießen" möchte, der kommt um die Migration auf die Container-Architektur nicht herum. Der Oracle Premier Support für 12.1.0.2 ist (derzeit) bis Mitte 2019 und für 12.2.0.1 bis Mitte 2022 festgelegt worden. Danach wird laut Oracle Dokumentation (vermutlich) nur noch die neue Architektur supportet. Hier ein Auszug aus der Doku dazu:

Note:

Starting with Oracle Database 12c, release 1 (12.1), non-CDB architecture is deprecated. It can be desupported in a future release. Oracle Database deployed with the multitenant architecture is the default configuration option. All Oracle Database releases earlier than Oracle Database 12c release 1 (12.1.0.1) use non-CDB architecture.

Oracle strongly recommends that you upgrade your source and target databases to the most recent bundle patch or patch set update (BP or PSU) before starting an upgrade ...

Also wollen wir uns in diesem Monatstipp einmal ansehen, wie der eigentliche Migrations- und Upgrade-Vorgang aussehen könnte. An der Stelle sei darauf hingewiesen, dass es verschiedene Alternativen gibt, um eine Migration von Non-CDB in CDB durchzuführen, auf die hier nicht ganzheitlich eingegangen wird.

Folgende Vorbereitungen müssen aber für alle Varianten getroffen werden:

Die Binaries der Zielversion (12.2.0.1) sind bereits in einem neuen ORACLE_HOME installiert und eine neue (Ziel-)Datenbank (hier mit Namen O122CDB) wurde als Container-DB angelegt.

Aber Achtung: Sobald Sie mehr als eine Pluggable Database innerhalb einer CDB installiert haben, müssen Sie die Multitenant-Lizenz erwerben. Falls dies nicht gewünscht ist, muss die CDB zunächst ohne Pluggable Database erzeugt werden. Dort hinein wird in den folgenden Schritten die Non-Container Quell-DB (o12c der Version 12.1.0.2) als PDB (pdb_o12c der Version 12.2.0.1) eingehängt. 

Die Empfehlung von Oracle, vor dem Upgrade den neuesten Bundle Patch (BP) oder PSU einzuspielen ignorieren wir zunächst einmal, was sich allerdings sehr bald rächen soll ...

Preupgrade Prüfung

Für die Vorabprüfung eines Upgrades auf 12.2 gibt es ein neues Skript (PREUPGRADE.JAR). Dieses wird aus dem (alten) ORACLE_HOME heraus aufgerufen:

$ cd $ORACLE_HOME_<old>/jdk/bin
$ ./java -jar $ORACLE_HOME_<new>/rdbms/admin/preupgrade.jar

Im Idealfall sieht die Rückmeldung folgendermaßen aus:

Preupgrade generated files:

/u01/app/oracle/cfgtoollogs/o12c/preupgrade/preupgrade.log
/u01/app/oracle/cfgtoollogs/o12c/preupgrade/preupgrade_fixups.sql
/u01/app/oracle/cfgtoollogs/o12c/preupgrade/postupgrade_fixups.sql

Falls bei der Durchführung Probleme auftreten, sollten die OS-Variablen ORACLE_HOME, PATH, PERL und PERL5LIB überprüft werden.

Durchführung des Upgrades und Fehlerbehandlung

Im Internet findet man etliche Anleitungen für das Upgrade, allerdings habe ich gemerkt, dass keine davon zusammenfassend alle Probleme behandelt, in die ich gelaufen bin, geschweige denn Lösungen dafür anbietet. Der folgende Tipp bietet hoffentlich eine hilfreiche Liste der möglichen Schritte und Hindernisse, erhebt jedoch ebenfalls keinen Anspruch auf Darstellung aller möglichen Fehler.

Als Grundlage für den Upgrade, soll an dieser Stelle eine Variante gewählt werden, die zwar in der Doku enthalten, aber nach meiner Erkenntnis noch nicht allzu weit verbreitet ist: (siehe Mike Dietrich: Öffnet externen Link in neuem Fensterhttps://mikedietrichde.com/2015/05/18/create-a-pdb-directly-from-a-stand-alone-database/ )
Das remote Klonen einer Non-CDB über die NON$CDB Option mit Database Link.

Dazu melden Sie sich am Root-Container der Ziel-Datenbank an und erzeugen einen Database Link zur Quell-Datenbank. Achten Sie auf den korrekten Eintrag in der TNSNAMES.ORA.

Der Benutzer, mit dem die Verbindung über den DB-Link zur Quell-DB vorgenommen wird, benötigt das CREATE PLUGGABLE DATABASE Recht.

SQL> conn / as sysdba
SQL> CREATE DATABASE LINK o12c CONNECT TO system 
       IDENTIFIED BY <pwd> using 'o12c';


Nun der erste Versuch des Klonvorgangs:

$ mkdir /u01/app/oracle/oradata/o122cdb/pdb_o12c
SQL> CREATE PLUGGABLE DATABASE pdb_o12c FROM NON$CDB@o12c 
       file_name_convert=('/u01/app/oracle/oradata/o12c',
          '/u01/app/oracle/oradata/o122cdb/pdb_o12c');
/*
 CREATE PLUGGABLE DATABASE pdb_o12c FROM NON$CDB@o12c ...
*
ERROR at line 1:
ORA-17628: Oracle error 17630 returned by remote Oracle server
ORA-17630: Mismatch in the remote file protocol version client  server
*/

Die Internetsuche ergab einen Bug, der durch das Einspielen des Patches 18633374 auf der Quellseite behoben wird (bitte Readme dazu lesen).


$ cd /tmp/18633374
$ opatch apply


Danach der zweite Versuch:

SQL> CREATE PLUGGABLE DATABASE pdb_o12c FROM NON$CDB@o12c 
       file_name_convert=('/u01/app/oracle/oradata/o12c',
          '/u01/app/oracle/oradata/o122cdb/pdb_o12c');
/*
 CREATE PLUGGABLE DATABASE pdb_o12c FROM NON$CDB@o12c ...
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [25029], [3], [3], [2], [], [], [], [], [], [], [], []
*/

Dieser Fehler erfordert das Einspielen des aktuellen BP auf der Zielseite. In diesem Fall wird der Patch 27105253 im neuen ORACLE_HOME eingespielt (Achtung Readme dazu).


$ cd /tmp/27105253
$ opatch apply


SQL> conn / as sysdba
SQL> startup
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;

$ cd $ORACLE_HOME/OPatch
$ ./datapatch -verbose


Und der dritte Versuch:

SQL> CREATE PLUGGABLE DATABASE pdb_o12c FROM NON$CDB@o12c 
       file_name_convert=('/u01/app/oracle/oradata/o12c',
          '/u01/app/oracle/oradata/o122cdb/pdb_o12c');
/*
 CREATE PLUGGABLE DATABASE pdb_o12c FROM NON$CDB@o12c ...
*
ERROR at line 1:
ORA-65353: The undo tablespace is missing from the XML metadata file.
*/

Das Problem ist in diesem Fall der in 12.2 standardmäßig eingestellte LOCAL UNDO Modus. Der UNDO-Tablespace aus der Quell-DB kommt nicht mit, wird aber im Ziel erwartet. Also wird temporär LOCAL UNDO in der Ziel-DB auf FALSE gesetzt.

SQL> shutdown immediate
SQL> startup upgrade
SQL> ALTER DATABASE LOCAL UNDO OFF;
SQL> shutdown immediate
SQL> startup


Aber jetzt, der vierte Versuch - na geht doch:

SQL> CREATE PLUGGABLE DATABASE pdb_o12c FROM NON$CDB@o12c 
       file_name_convert=('/u01/app/oracle/oradata/o12c',
          '/u01/app/oracle/oradata/o122cdb/pdb_o12c');
-- Pluggable database created.

 

In jedem Fall sollte man sich die PDB_PLUG_IN_VIOLATIONS View ansehen, um über WARNINGs und ERRORs informiert zu werden.

SQL> col message for a200
     col action for a150
     col cause for a20
     col time for a30
     col name for a10
SQL> SELECT time, name, cause, type, message, status, action
       FROM pdb_plug_in_violations;

...
VSN not match 
ERROR
PDB's version does not match CDB's version: PDB's version 12.1.0.2.0. CDB's version 12.2.0.1.0.
PENDING 
Either upgrade the PDB or reload the components in the PDB. 
...
Non-CDB to PDB       
WARNING             
PDB plugged in is a non-CDB, requires noncdb_to_pdb.sql be run.
PENDING       
Run noncdb_to_pdb.sql.

Also muss die Pluggable Database PDB_O12C zunächst upgegradet werden. Dies erfolgt über den Aufruf des Perl-Skripts CATCTL.PL

SQL> ALTER SESSION SET CONTAINER=pdb_o12c;
SQL> ALTER PLUGGABLE DATABASE pdb_o12c OPEN UPGRADE;

$ export ORACLE_HOME=/u01/app/oracle/product/12.2.0.1/dbhome_1
$ export ORACLE_SID=o122cdb
$ export PERL=$ORACLE_HOME/perl/bin
$ export PERL5LIB=$ORACLE_HOME/rdbms/admin
$ export PATH=$ORACLE_HOME/bin:$PERL:$PATH
$ cd $ORACLE_HOME/rdbms/admin

$ $ORACLE_HOME/perl/bin/perl catctl.pl -c 'PDB_O12C' catupgrd.sql

/*
Argument list for [catctl.pl]
Run in                c = PDB_O12C


catctl.pl VERSION: [12.2.0.1.0]
           STATUS: [production]
            BUILD: [RDBMS_12.2.0.1.0_LINUX.X64_170125]

/u01/app/oracle/product/12.2.0.1/dbhome_1/rdbms/admin/orahome =
[/u01/app/oracle/product/12.2.0.1/dbhome_1]
/u01/app/oracle/product/12.2.0.1/dbhome_1/bin/orabasehome =
[/u01/app/oracle/product/12.2.0.1/dbhome_1]
catctlGetOrabase = [/u01/app/oracle/product/12.2.0.1/dbhome_1]

Analyzing file /u01/app/oracle/product/12.2.0.1/dbhome_1/rdbms/admin/catupgrd.sql


*****************   Post Upgrade   *****************
°Serial   Phase #:112  [PDB_O12C] Files:1    Time: 55s
****************   Summary report   ****************
Serial   Phase #:113  [PDB_O12C] Files:1    Time: 1s
Serial   Phase #:114  [PDB_O12C] Files:1    Time: 25s
Serial   Phase #:115  [PDB_O12C] Files:1     Time: 0s

------------------------------------------------------
Phases [0-115]         End Time:[2018_01_30 11:33:48]
Container Lists Inclusion:[PDB_O12C] Exclusion:[NONE]
------------------------------------------------------

Grand Total Time: 1620s [PDB_O12C]

*/


Da sich die neue PDB im Modus RESTRICTED befindet, muss anschließend das Skript NONCDB_TO_PDB.SQL aufgerufen werden

SQL> ALTER SESSION SET container=pdb_o12c;
SQL> @?/rdbms/admin/noncdb_to_pdb.sql


Falls beim erneuten Versuch die PDB zu öffnen eine Warnung kommt

SQL> startup
Warning: PDB altered with errors.
Pluggable Database opened.
sollte folgendermaßen vorgegangen werden:
SQL> ALTER SESSION SET CONTAINER=CDB$ROOT;
SQL> ALTER PLUGGABLE DATABASE pdb_o12c CLOSE;
SQL> ALTER PLUGGABLE DATABASE pdb_o12c OPEN RESTRICTED;
SQL> exec dbms_pdb.sync_pdb();
SQL> ALTER PLUGGABLE DATABASE pdb_o12c CLOSE;
SQL> ALTER PLUGGABLE DATABASE pdb_o12c OPEN;

Zu überprüfen ist, ob der STATUS bei allen Meldungen von PENDING auf RESOLVED geändert wurde. Falls nicht, gibt die Spalte ACTION Auskunft darüber, was zu tun ist. Nun sollte sich die PDB (ohne Probleme, Warnungen oder Fehler) öffnen lassen.

Tipp: Überprüfen Sie ebenfalls die ungültigen Objekte und, falls welche vorhanden, versuchen Sie diese zu rekompilieren.

SQL> SELECT COUNT(*) FROM dba_invalid_objects;
SQL> @?/rdbms/admin/utlrp.sql


Falls Sie wieder auf den LOCAL UNDO Modus wechseln wollen, gehen Sie analog zum Ausschalten vor. 

SQL> shutdown immediate
SQL> startup upgrade
SQL> ALTER DATABASE LOCAL UNDO ON;
SQL> shutdown immediate
SQL> startup

Oracle erzeugt dabei automatisch einen UNDO-Tablespace für die PDB. Dazu der Auszug aus der Alertdatei:

...
PDB_O12C(3):CREATE SMALLFILE UNDO TABLESPACE undo_1 DATAFILE '/u01/app/oracle/oradata/o122cdb/pdb_o12c/system01_i1_undo.dbf'
SIZE 104857600 AUTOEXTEND ON NEXT 5242880 MAXSIZE 34359721984 ONLINE
...

FAZIT

Sie haben nun einen Eindruck davon bekommen, was auf Sie zukommen kann, wenn Sie auf die Container-Architektur umstellen und dabei auch gleich noch einen Versions-Upgrade durchführen möchten.

Es sei an dieser Stelle aber noch einmal ausdrücklich erwähnt, dass dieser Tipp keine Besonderheiten wie RAC, Data Guard, ASM oder andere Oracle Optionen berücksichtigt. Deshalb kann nicht vorhergesagt werden, welche zusätzlichen Hürden sich Ihnen in den Weg stellen ...

Migration Pluggable Database Non-Container Datenbank Upgrade DBA

Jede Menge Know-how für Sie!

In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.