Hello Oracle community,
I am tasked with migrating an Oracle database from 12cR1 on Windows 2008 R2 to 19c on Windows 2016. I conducted a test on the Windows 2016 server first:
1) Install Database 12cR1 (even though it's not certified)
2) Install July 2019 CPU for 12cR1
3) Create test database to eventually upgrade to 19c
4) Run datapatch on test database in 12cR1
5) Install Database 19c software
6) Install July 2019 CPU for 19c
7) Upgrade test database from 12cR1 to 19c using DBUA
Everything is going great but then my upgrade halts with:
ORA-01722: invalid number
I trace it back to a statement that confirms that the script version identified by the &C_ORACLE_HIGH_ variables in dbms_registry_basic.sql matches the server version full value from v$instance. This query produces the invalid number error, and I think I know why...
The &C_ORACLE_HIGH variables defined in dbms_registry_basic.sql are still referring to 19.3 (which is the version of 19c I downloaded and installed). The July 2019 CPU for 19c upgraded it to 19.4, but it appears the dbms_registry_basic.sql file wasn't changed. The catupgd log says that if this error is encountered, you should use a different script or server, which makes me think 19.4 got stuck in v$instance but dbms_registry_basic.sql says 19.3
I'm assuming if I change the order of my steps and had upgraded the database BEFORE installing the 19c July patch, I'd probably be fine. But nowhere in the upgrade docs did I see this mentioned - maybe I missed it. And to be honest, I'd prefer to have the database patched before upgrading because it's something I can do ahead of time outside the upgrade maintenance window.
Is this expected behavior? I know I can just rollback my patches, do the upgrade, and re-patch, but should I be expected to upgrade the database from 12 to 19 before patching/datapatch, or should I be able to patch 19 and then upgrade the database? Did I stumble on a bug here?
Curious to hear what folks think. Thanks for your time.