AutoUpgrade: Plug Noarchive Non-CDB Database as Upgraded PDB | Official Pythian®® Blog

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?