In diesem Tipp 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
…
## CODE ##
Danach der zweite Versuch:
## CODE ##
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 …