PDB-Upgrade mittels Refreshable PDB

7. Juli 2021 Aus Von Markus Flechtner

Upgrade einer Pluggable Datenbank mit kurzer Downtime, die Quell-Datenbank soll als Fallback-Lösung erhalten bleiben, das war die Kundenanforderung. Einfaches Umhängen der PDB (Fallback-Lösung geht verloren) scheidet somit genauso aus wie ein Remote Cloning (dauert zu lange). Bleibt als Option die “Refreshable PDB” mit der das Kopieren der PDB in die Ziel-DB quasi “online” erfolgt.

Die Testkonfiguration

Auf dem Server sind Oracle 18c und 19c, jeweils mit dem aktuellen Release-Update (RU) vom April 2021 installiert:

oracle@kiwi:~/ [rdbms18ee] $ORACLE_HOME/OPatch/opatch lspatches
32552752;OJVM RELEASE UPDATE: 18.14.0.0.210420 (32552752)
32524155;Database Release Update : 18.14.0.0.210420 (32524155)
28090553;OCW RELEASE UPDATE 18.3.0.0.0 (28090553)
OPatch succeeded.

oracle@kiwi:~/ [rdbms19ee] $ORACLE_HOME/OPatch/opatch lspatches
32545013;Database Release Update : 19.11.0.0.210420 (32545013)
32399816;OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816)
31732095;UPDATE PERL IN 19C DATABASE ORACLE HOME TO V5.32
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)
OPatch succeeded.

Zusätzlich habe ich die aktuelle Version des AutoUpgrade-Tools heruntergeladen (MOS-Note 2485457.1 / Version 20210421) und ins 19c-ORACLE_HOME kopiert:

oracle@kiwi:/u00/app/oracle/utils/ [CDB19C] ls -al autoupgrade.jar
-rwxr-xr-x. 1 oracle oinstall 2973275 Jul  5 21:59 autoupgrade.jar

oracle@kiwi:/u00/app/oracle/utils/ [CDB19C] mv $ORACLE_HOME/rdbms/admin/autoupgrade.jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar.backup

oracle@kiwi:/u00/app/oracle/utils/ [CDB19C] cp autoupgrade.jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar

Auf dem Server laufen zwei Container-Datenbanken

  • CDB18C (mit PDB “TESTPDB”)
  • CDB19C

Die Dateien der CDBs liegen im Verzeichnis /u01/oradata/CDB18C bzw. /u01/oradata/CDB19C, die der PDB TESTPDB im Verzeichnis /u01/oradata/CDB18C/TESTPDB.

Beide Container-Datenbanken laufen im Archivelog-Modus, haben den gleichen Zeichensatz (AL32UTF8), die gleiche Default-Blockgröße (8 KB) und die gleichen Datenbank-Optionen. Damit sind die Voraussetzungen für Remote-Cloning bzw. die Refreshable PDB erfüllt. Wenn man sich nicht sicher ist, ob dies der Fall ist, sprich: ob man die PDB in die Ziel-CDB einhängen kann, kann man mit DBMS_PDB.DESCRIBE die Manifest-Datei der PDB erzeugen und mittels DBMS_PDB.CHECK_COMPATIBILITY in der Ziel-CDB prüfen, ob die Ziel CDB kompatibel ist.

Anlegen der Refreshable PDB

Schritt1: Anlegen eines “Common Users” in der Quell-CDB

SQL> create user c##refresh identified by "RefreshOnly" container=ALL;
User created.
SQL> grant create session,sysoper,create pluggable database to c##refresh container=ALL;
Grant succeeded.

Schritt 2: Anlegen eines Datenbank-Links von der Ziel-CDB zu Quell-CDB

SQL> create database link CDB18C connect to c##refresh identified by "RefreshOnly" using 'CDB18C.markusdba.local';
Database link created.

Hinweis: Nach dem Upgrade nicht vergessen, den Datenbank-Link zu droppen.

Sicherheitshalber den Datenbank-Link anschließend testen:

SQL> select * from dual@CDB18C;

D
-
X

Anlegen der Refreshable PDB

In der Ziel-Datenbank legen wir jetzt die Refreshable PDB an:

SQL> create pluggable database TESTPDB from TESTPDB@CDB18C
  2  file_name_convert=('CDB18C','CDB19')
  3  refresh mode every 10 minutes;
Pluggable database created.

Ich bevorzuge für den Upgrade mittels Refreshable PDB ein kurzes, automatisches Refresh-Intervall (im Beispiel 10 Minuten). Man kann natürlich auch mit “REFRESH MODE MANUAL” arbeiten und ist dann selbst für die Aktualisierung der PDB verantwortlich.

Ergänzend sollte in der Ziel-CDB der Parameter REMOTE_RECOVERY_FILE_DEST gesetzt werden. Mit diesem Parameter wird angegeben, wo die Ziel-CDB die Archivelog-Dateien der Quell-PDB findet, wenn dies für einen Refresh notwendig ist. Bei kurzen Refresh-Intervallen sollte das allerdings eher weniger der Fall sein; hier sollte der Zugriff auf die Information aus den Online-Redolog-Dateien der Quell-CDB reichen.

SQL> alter system set remote_recovery_file_dest='/u02/fast_recovery_area' scope=both;
System altered.

Da das Anlegen der Refreshable PDB und der regelmäßige Refresh die Ausgangsdatenbank nicht beeinflußt (wenn man von der vorübergehenden höheren I/O-Last absieht) ist es also eine “Online-Operation”, die Applikation bleibt verfügbar

Erstellen der Konfigurationsdatei für AutoUpgrade

Autoupgrade benötigt eine Konfigurationsdatei:

oracle@kiwi:~/autoupgrade/ [CDB19C] cat autoupgrade_TESTPDB.conf
global.autoupg_log_dir=/home/oracle/autoupgrade
testupgrade.dbname=CDB18C
testupgrade.start_time=NOW
testupgrade.source_home=/u00/app/oracle/product/18-ee
testupgrade.sid=CDB18C
testupgrade.target_version=19
testupgrade.target_home=/u00/app/oracle/product/19-ee
testupgrade.pdbs=TESTPDB

Analysieren der Quell-PDB mit “autoupgrade -analyze”

oracle@kiwi:~/autoupgrade/ [CDB19C] $ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar -config /home/oracle/autoupgrade/autoupgrade_TESTPDB.conf -mode analyze
AutoUpgrade tool launched with default options
Processing config file ...
+--------------------------------+
| Starting AutoUpgrade execution |
+--------------------------------+
1 databases will be analyzed
Type 'help' to list console commands
upg> Job 100 completed
------------------- Final Summary --------------------
Number of databases            [ 1 ]

Jobs finished                  [1]
Jobs failed                    [0]
Jobs pending                   [0]

Please check the summary report at:
/home/oracle/autoupgrade/cfgtoollogs/upgrade/auto/status/status.html
/home/oracle/autoupgrade/cfgtoollogs/upgrade/auto/status/status.log

Hinweis: für den eigentlichen Upgrade können wir “autoupgrade” nicht verwenden, da es dieses Szenario “Upgrade via Refreshable PDB” noch nicht beherscht. Der einzige Nutzen von autoupgrade ist es in diesem Fall, die Analyse und die anschließenden Korrekturen zu übernehmen. Man könnte also genauso gut mit dem altbekannten “preupgrade-Tool” (MOS-Note 884522.1) die Ausgangsdatenbank analysieren und die Probleme dann manuell lösen.

Es folgt die Kontrolle der Log-Datei für die PDB TESTPDB auf Probleme, die Autoupgrade nicht selbst korrigieren kann:

oracle@kiwi:~/ [CDB19C] view /home/oracle/autoupgrade/CDB18C/100/prechecks/prechecks_testpdb.log

Damit sind die Vorbereitungen abgeschlossen. Die Refreshable PDB wird automatisch im Hintergrund aktualisiert und wir können die Auszeit der Applikation für den Upgrade planen. Sollte es zwischen dem “analyze” und dem Upgrade etwas länger dauern, empfiehlt sich natürlich ein neuerlicher “analyze” kurz vor dem Upgrade.

Stop der Applikation – Beginn der “Downtime”

Mit dem Stoppen der Applikation beginnt die Downtime und der eigentliche Upgrade.

Zuerst beenden wir den automatischen Refresh der PDB:

SQL> alter pluggable database TESTPDB refresh mode manual;
Pluggable database altered.

Danach lassen wir Autoupgrade die Korrekturen (“Fixups”) in der Ausgangs-PDB machen:

oracle@kiwi:~/ [CDB19C] $ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar -config /home/oracle/autoupgrade/autoupgrade_TESTPDB.conf -mode fixups
AutoUpgrade tool launched with default options
Processing config file ...
+--------------------------------+
| Starting AutoUpgrade execution |
+--------------------------------+
[…]
upg> Job 101 completed
------------------- Final Summary --------------------
Number of databases            [ 1 ]

Jobs finished                  [1]
Jobs failed                    [0]
Jobs pending                   [0]

Danach kann die PDB in der Ausgangs-CDB geschlossen werden:

SQL> alter pluggable database TESTPDB close immediate;
Pluggable database altered.

Da wir in diesem Test die beiden CDBs auf dem gleichen Server haben, ist es sinnvoll, das automatische Öffnen der PDB auf der Ausgangs-CDB zu unterbinden, um ein “Split-Brain” zu verhindern:

SQL> alter pluggable database TESTPDB discard state;
Pluggable database altered.

Manueller Refresh der Ziel-PDB

Es folgt ein letzter manueller Refresh und das Abschalten des Refreshes. Dadurch geht dann auch die Verbindung zur Ausgangs-CDB verloren:

SQL> alter pluggable database TESTPDB refresh;
Pluggable database altered.

SQL> alter pluggable database TESTPDB refresh mode none;
Pluggable database altered.

Upgrade der PDB

Zum Abschluss wird dann die PDB in der Ziel-CDB auf die Zielversion aktualisiert. Das können wir leider nicht mit dem “autoupgrade”-Tool machen, sondern nehmen “dbupgrade”

SQL> alter pluggable database TESTPDB open upgrade;
Pluggable database altered.

SQL> exit
Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.11.0.0.0

oracle@kiwi:~/ [CDB19C] dbupgrade -c TESTPDB -n 4 -l /home/oracle/dbupgrade
[…]

------------------------------------------------------
Phases [0-107]         End Time:[2021_07_07 17:17:59]
Container Lists Inclusion:[TESTPDB] Exclusion:[NONE]
------------------------------------------------------

Grand Total Time: 3103s [TESTPDB]

 LOG FILES: (/home/oracle/dbupgrade/catupgrdtestpdb*.log)

Upgrade Summary Report Located in:
/home/oracle/dbupgrade/upg_summary.log

     Time: 3109s For PDB(s)

Grand Total Time: 3109s

 LOG FILES: (/home/oracle/dbupgrade/catupgrd*.log)


Grand Total Upgrade Time:    [0d:0h:51m:49s]

Nacharbeiten

PDB öffnen und Status sichern

.. damit die PDB bei einem Neustart der Instanz automatisch geöffnet wird

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

SQL> alter pluggable database TESTPDB save state;
Pluggable database altered.

Aktualisierung der Zeitzonen-Informationen

SQL> alter session set container=TESTPDB;

Session altered.

SQL> @?/rdbms/admin/utltz_upg_check.sql
[…]
SQL> @?/rdbms/admin/utltz_upg_apply.sql
[…]
Number of failures: 0
INFO: Total failures during update of TSTZ data: 0 .
An upgrade window has been successfully ended.
INFO: Your new Server RDBMS DST version is DSTv32 .
INFO: The RDBMS DST update is successfully finished.
INFO: Make sure to exit this SQL*Plus session.
INFO: Do not use it for timezone related selects.

SQL> exit
Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.11.0.0.0

Kontrolle des Upgrades

SQL> alter session set container=TESTPDB;
SQL> @?/rdbms/admin/utlrp
[…]
SQL> select count(*) from dba_objects where status='INVALID';

  COUNT(*)
----------
     0
SQL> @?/rdbms/admin/catresults.sql

Oracle Database Release 19 Post-Upgrade Status Tool    07-07-2021 17:41:3
Container Database: CDB19C
[CON_ID: 4 => TESTPDB]

Component				Current 	Full	 Elapsed Time
Name					Status		Version  HH:MM:SS

Oracle Server				  VALID     19.11.0.0.0  00:14:11
JServer JAVA Virtual Machine		  VALID     19.11.0.0.0  00:00:56
Oracle XDK				  VALID     19.11.0.0.0  00:01:54
Oracle Database Java Packages		  VALID     19.11.0.0.0  00:00:31
OLAP Analytic Workspace 		  VALID     19.11.0.0.0  00:00:14
Oracle Text				  VALID     19.11.0.0.0  00:00:46
Oracle Workspace Manager		  VALID     19.11.0.0.0  00:00:42
Oracle Real Application Clusters     OPTION OFF     19.11.0.0.0  00:00:00
Oracle XML Database			  VALID     19.11.0.0.0  00:01:40
Oracle Multimedia			  VALID     19.11.0.0.0  00:00:26
Spatial 				  VALID     19.11.0.0.0  00:09:28
Oracle OLAP API 			  VALID     19.11.0.0.0  00:00:30
Datapatch							 00:17:24
Final Actions							 00:17:28
Post Upgrade							 00:01:50
Post Compile							 00:01:13

Total Upgrade Time: 00:52:06 [CON_ID: 4 => TESTPDB]

Database time zone version is 32. It meets current release needs.

Achtung: Wenn man “catresults.sql” vor dem Recompile laufen lässt, dann sind viele Komponenten noch im Status “UPGRADED” oder “LOADING”.

Statistiken aktualisieren

Wenn die Datenbank nicht zu groß ist, dann sollte man neue Datenbank-Statistiken sammeln:

SQL> execute dbms_stats.gather_database_stats;

In jedem Fall sollte man Dictionary-Statistiken sammeln

SQL> execute dbms_stats.gather_dictionary_stats;

Die Statistiken der “Fixed Objects” sollten erst gesammelt werden, wenn die Applikation etwa eine Woche in Betrieb war. Der Vollständigkeit halber hier der zugehörige Befehl:

SQL> execute dbms_stats.gather_fixed_objects_stats;

Um am Ende nicht vergessen, den Datenbank-Link zur Quell-CDB zu löschen:

SQL> alter session set container=CDB$ROOT;
SQL> drop database link CDB18C;

Für den Fall eines Serverwechsels muss man nur noch die tnsnames.ora auf de Clients anpassen (oder die Daten im LDAP-Server), damit sich die Anwendung mit der PDB verbinden kann.

Fazit

Upgrade mit Refreshable PDB ermöglicht den Upgrade einer PDB mit Fallback Lösung (alte PDB) und relativ kurzer Downtime. Quell- und Ziel-CDB können dabei auf unterschiedlichen Servern liegen. Wenn man den Server nicht wechselt (wie z.B. in dem hier dargestellten Test) kann man auch mit “RELOCATE” der PDB arbeiten (siehe Links).

 

Quellen / Referenzen

Amazon Partner Link

Oracle Database 12c Release 2 Multitenant (Oracle Press)
Oracle Database 12c Release 2 Multitenant (Oracle Press)
Amazon
KategorieMultitenant
SchlagwörterMultitenant Refreshable PDB Upgrade