In short: If you are using the classic Preupgrade tool (preupgrade.jar) you should ensure that the tool is present in target Oracle Home. The MOS note How to Download and Run Oracle’s Database Pre-Upgrade Utility (Doc ID 884522.1) has been updated to highlight the following:
If the upgrade-to version is 12.2 or higher, then save the file to your target $ORACLE_HOME/rdbms/admin directory and then unzip the file.
You can use this example:
cp preupgrade_19_cbuild_7_lf.zip /u01/app/oracle/product/188.8.131.52/dbhome_1/rdbms/admin/ cd /u01/app/oracle/product/184.108.40.206/dbhome_1/rdbms/admin/ unzip preupgrade_19_cbuild_7_lf.zip
If you are moving the database to a new server as part of the upgrade, ensure that the same version of the Preupgrade tool is used on both the source and target database host.
Lately, I have been involved in a few cases, where customers reported that the classic Preupgrade tool failed during post-upgrade fixups:
@postupgrade_fixups.sql DECLARE * ERROR at line 1: ORA-20000: In run_check, Pre-Upgrade Package Requested Check "post_disable_bct_upg" does not exist ORA-06512: at line 1 ORA-06512: at "SYS.DBMS_PREUP", line 293 ORA-06512: at "SYS.DBMS_PREUP", line 5227 ORA-06512: at "SYS.DBMS_PREUP", line 3239 ORA-06512: at line 139
After guidance from our developers, I learnt that you must extract the classic Preupgrade tool (all the files) into the target Oracle Home before you execute the post-upgrade fixups. Specifically, the files must go into
$ORACLE_HOME/rdbms/admin. And you can safely overwrite the existing files. Or, back them up first if you are cautious.
This is especially relevant when you are upgrading the database and moving the database to a new server as well. I have a blog post series on upgrading on VM DB Systems in OCI and they all involve moving the database to a new server. And my initial editions of the posts didn’t have this information.
When you run the classic Preupgrade tool on the source database you should be using the latest version of the tool. You can download it from My Oracle Support. You run the tool on the source database before you shut it down, and move the database to another server. When the upgrade is completed, and you execute the post-upgrade fixups it will use auxiliary packages from the target Oracle Home to make some of the fixups. If the two versions of the auxiliary packages are out of sync, you might run into problems.
One of the developers wrote:
When postupgrade_fixups.sql is executed, preupgrade_package.sql is executed again, but it is taken from the $ORACLE_HOME/rdbms/admin. As it has a different version, then it is not able to execute the postupgrade fixup
I have been upgrading databases for many years, and I haven’t been aware of this. That I haven’t run into problems before, is just pure luck, I assume.
And remember, always use the latest version of the tool from My Oracle Support.