AutoUpgrade: Plug Noarchive Non-CDB Database as Upgraded PDB
The Database AutoUpgrade utility has been slowly developing its capability to cover all possibilities of database upgrades. Recently I’ve tested an upgrade of a database running in NOARCHIVELOG mode using this utility. I added more complications with this testing phase; these are my environment details:
1. Environment Configuration and Setup
The source database namely “testnew” was running in rdbms 12.1.0.2 version, NOARCHIVELOG mode. This was a non-CDB database. The target database namely “test19c” was running in rdbms 19.3.0 version, NOARCHIVELOG mode. This was a CDB database.
Updating the AutoUpgrade Utility
First I verified the MOS note 2485457.1 and noticed the most recent version of the AutoUpgrade utility was version 20201214. Hence, I checked which version was available in my rdbms 19.3 oracle home and found the build version was 20190207.
[oracle@vm130-196 admin]$ java -jar autoupgrade.jar -version build.version 20190207 build.date 2019/02/07 12:35:56 build.label RDBMS_PT.AUTOUPGRADE_LINUX.X64_190205.1800
I downloaded the latest version and copied across this Oracle home.
[oracle@vm130-196 admin]$ ls -ltr auto* -rw-r--r--. 1 oracle oinstall 3360892 Feb 8 2019 autoupgrade.jar_old -rw-r--r--. 1 oracle oinstall 2868558 Feb 21 23:53 autoupgrade.jar [oracle@vm130-196 admin]$ java -jar autoupgrade.jar -version build.hash 8ee6880 build.version 21.1.1 build.date 2020/12/14 14:41:34 build.max_target_version 21 build.supported_target_versions 12.2,18,19,21 build.type production
2. Troubleshooting the Analyze Phase
I created a very basic configuration file(config.txt) for this upgrade activity and executed it in Analyze Mode; it failed with the “ARCHIVE_MODE_ON” error.
[oracle@vm130-196 ~]$ cat config.txt upg1.source_home=/u01/app/oracle/product/12.1.0/dbhome_1 upg1.target_home=/u01/app/oracle/product/19.3.0/dbhome_1 upg1.sid=testnew
Resolving NOARCHIVELOG Mode Compatibility
The configuration file was added with the parameter “restoration=no,” which was related to the ARCHIVELOG mode of the database. The utility with Analyze Mode didn’t throw any errors this time.
[oracle@vm130-196 admin]$ cat /home/oracle/config.txt upg1.source_home=/u01/app/oracle/product/12.1.0/dbhome_1 upg1.target_home=/u01/app/oracle/product/19.3.0/dbhome_1 upg1.sid=testnew upg1.restoration=no
Addressing Non-CDB to PDB Plug-in Violations
This means I could upgrade this as a non-CDB database. However, since my objective was to plug this non-CDB database as an upgraded PDB, I added an associated parameter “target_cdb” with the configuration file. The Analyze Mode failed with a “TARGET_CDB_COMPATIBILITY” error.
[oracle@vm130-196 admin]$ cat /home/oracle/config.txt upg1.source_home=/u01/app/oracle/product/12.1.0/dbhome_1 upg1.target_home=/u01/app/oracle/product/19.3.0/dbhome_1 upg1.sid=testnew upg1.restoration=no upg1.target_cdb=test19c
Handling the APEX Version Mismatch
I reviewed the associated logfiles and noticed the error was due to APEX mismatch. This meant the source database was running with Oracle Application Express database component, version 4.2.5. But the target database was running without this component.
2021-02-22 00:18:42.464 INFO Plug in violation [TESTNEW 1 ERROR PENDING APEX mismatch: PDB has installed common APEX. CDB has not installed APEX.] not ignored - CheckPluginCompatibility.getNonIgnorableViolations
I reviewed various scenarios and decided to remove the APEX component as it wasn’t getting used (Ref MOS note 558340.1). I executed the required scripts in the source database and compiled the invalid objects.
3. Executing the Database Upgrade
The execution of AutoUpgrade in Analyze Mode was done without any issues. Once the utility was executed with deploy option, the upgrade started its execution.
Launching Deploy Mode and Monitoring Progress
[oracle@vm130-196 admin]$ java -jar autoupgrade.jar -config /home/oracle/config.txt -mode deploy
The AutoUpgrade execution took around 80 minutes to complete its execution. It didn’t report any errors.
upg> status -job 104 Stage summary: SETUP <1 min PREUPGRADE <1 min PRECHECKS <1 min PREFIXUPS 3 min DRAIN <1 min DBUPGRADE 31 min (IN PROGRESS)
4. Post-Upgrade Verification
As a part of verification, I checked the invalid objects and status of database components. I didn’t see any issues.
Verifying PDB Status and Registry
SQL> select con_id,name,OPEN_MODE from v$pdbs order by 1; CON_ID NAME OPEN_MODE ---------- -------------------- ---------- 2 PDB$SEED READ ONLY 3 TEST19CPDB READ WRITE 4 TESTNEW READ WRITE SQL> SELECT comp_id, status, SUBSTR(version,1,10) version, comp_name FROM dba_registry ORDER BY 1; ... 15 rows selected.
So the usage of parameters “restoration=no” and “target_cdb” helped to complete the requirement. This looks easy, doesn’t it?
If you have any questions, or thoughts about the above, please leave them in the comments.
Oracle Database Consulting Services
Ready to optimize your Oracle Database for the future?
Share this
Share this
More resources
Learn more about Pythian by reading the following blogs and articles.

How to Minimize downtime for 19c upgrade using Oracle logical standby transient Database
Issues With Database Service Names Starting With Pluggable Database (PDB) Name
Oracle Database 18c schema only accounts
Ready to unlock value from your data?
With Pythian, you can accomplish your data transformation goals and more.