Below is the configuraiton file used in this case.
global.autoupg_log_dir=/home/oracle/upgr_log # ----- NonCDB to PDB conversion ----- # To upgrade and convert an existing NonCDB database into a PDB of a target CDB, # use the target_cdb parameter to specify the destination CDB. # The target_pdb_name and target_pdb_copy_option parameters can be used # to determine how each PDB is created on the target CDB. # # When neither of these options are used, a full upgrade of the source DB/CDB is performed. # upg1.sid=testupg upg1.source_home=/opt/app/oracle/product/11.2.0/dbhome_1 upg1.target_home=/opt/app/oracle/product/19.x.0/dbhome_1 upg1.run_utlrp=yes upg1.timezone_upg=yes ### NonCDB to PDB parameters ### upg1.target_cdb=testcdb upg1.target_pdb_name=devpdb upg1.target_pdb_copy_option=file_name_convert=NONEThe 11.2 DB is called testupg and it's Oracle home is the source_home. The configuration already has a 19c CDB and its Oracle home is the target_home. This CDB is the target_cdb and called testcdb.
The 11.2 DB will be upgraded and plugged into the target CDB as a PDB named devpdb. The target_pdb_copy_option parameter is set to NONE so that upgraded PDB's data files are copied under the target CDB's data file structure.
The 11.2 DB has the final patch set update applied on it and 19c CDB has 19.19 RU applied.
As the first step run the AU in analyze mode to identify any issues.
java -jar autoupgrade.jar -config noncdb11g2_cdb.cfg -mode analyze
Some prechecks may require manual intervention to fix. For others AU provides a fixup mode.
java -jar autoupgrade.jar -config noncdb11g2_cdb.cfg -mode fixups
When all the fixups are done and prechceks have passed, run the AU in deploy mode to begin the upgrade and plugin as a PDB.
java -jar autoupgrade.jar -config noncdb11g2_cdb.cfg -mode deploy
The 11.2 DB is now a PDB inside the target CDB. If there was a database service associated with it then this has to be manaully created using srvctl.
One of the things noticed during this upgrade test is with regard to timezone. The 19c CDB had timezone file 32 as the current timezone file. However, the 19.19 RU has newer timezone files but they are simply copied to Oracle home and not applied. This is mentioned in the RU readme.html.
Applying this Release Update (RU) does not change the DST version in any of your databases. The DST patches are only copied into $ORACLE_HOME/oracore/zoneinfo and no DST upgrade is performed. You can decide to upgrade the DST version in your database to a newer DST version independently of applying the RU at any time.During the upgrade, as timezone_upg is set to yes the 11.2 DB's timezone is upgraded to 41. When this is plugged into the CDB then the PDB will have a higher timezone than the CDB. To avoid this from happening, either upgrade the CDB to latest timezone before the upgrade or set timezone_upg to no in the config file. Then run the timezone upgrade in the PDB by setting the timezone value used by the CDB.
The copies of the 11.2 datafiles remains in their original location after the upgrade. This database could be opened as a 19c non-CDB from a 19c home. On the otherhand it could be mounted using the 11.2 home and flashback to 11.2 using the restore point created by AU. In the later case (flashback to 11.2) following error may occur when archivelog clean up is initiated using rman
ORA-19633: control file record 25 is out of sync with recovery catalogThis is due to mismatch in letter cases (upper cases vs lower case use in 11.2 and 19c) in archivelog file paths. More on this is on MOS 1105924.1. To fix this recreate the controlfile from trace
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
Related Posts
Unplug-Plug-Upgrade from 19c to 21c Using Autoupgrade
Plugging non-CDB as a PDB - Manual vs Autoupgrade
Upgrading Oracle Single Instance with ASM (Oracle Restart) from 11.2.0.4 to 19c (19.6) on RHEL 7
