Funny, I was traveling recently with RAC PM Anil Nair – but he forgot to tell me that this cool story has been published just a few days before we took of for YATRA 2022 to India: Intel uses AutoUpgrade to upgrade from Oracle 11.2.0.4 to 19c. I know that Anil is simply so busy – and my surprise was huge.
Photo by Daniel Pantu on Unsplash
What’s the story?
Gagan Singh, Enterprise Architect at Intel, shared it with me last week. The goal was to upgrade from Oracle 11.2.0.4 to Oracle 19c with the least amount of downtime to minimize the impact on factory operations. Oracle ACS and the RAC PM team were involved in this project.
If you are interested then please read on here:
- Intel upgrades mission critical database to Oracle 19c & improves application performance with Oracle RAC
(Link is currently inactive and will be re-established once the story got republished)
We were happy to see and read how AutoUpgrade Tool got used by the teams in this case.
Congrats to the team at Intel, and of course to the ACS and RAC PM team as well!
Further Links and Information
- MOS Note: 2485457.1 – AutoUpgrade Tool
- Intel upgrades mission critical database to Oracle 19c & improves application performance with Oracle RAC
–Mike
Hello Mike, will you have the downtime that this database update took in Intel?
Greetings and thanks.
Hi Victor,
yes, the upgrade time actually is downtime.
But it was kept relatively low since there are no unused options installed in this database.
Cheers
Mike
Hi Mike,
What could be the strategy to follow to update a database from 11.2.0.4 to 19c with the minimum interruption time.
The current environment is:
1. A primary two-node Oracle RAC database 11.2.0.4
2. A Standby Single Instance database 11.2.0.4 Open read only (Active Dataguard)
3. For both databases, Infrastructure Grid 11.2.0.4 is installed, for which it is also required to update to 19c.
It is required to migrate to version 19c to the CDB architecture.
Could you use dbms_rolling (transient logical standby)?
Thanks and regards,
Victor
Hi Victor,
at first you must upgrade and patch GI to 19c. That is anyway the first task. And it works rolling.
Then it is your choice based on the allowed downtime.
If you are in the area of “5 minutes or less” then Transient Logical Standby is a good choide. DBMS_ROLLING can’t be used since the source does not know about it. So you need to do the manual transient approach.
Oracle GoldenGate would be the alternative to even go below close to zero.
See our Virtual Classroom Seminar Episode 10:
https://mikedietrichde.com/videos/
We have a dedicated section about Standby rolling upgrades.
Cheers
Mike
Hi Mike
Thank you very much for your prompt response, I just saw the video you indicated and it will be very useful. It’s great.
It is clear to me that the GI must first be updated and patched to 19c.
Regarding the use of the dbms_rolling package, it would be ruled out because the version of the source database is 11.2.0.4.
The manual transient option would remain as indicated in note 949322.1.
The question here would be?
Could this migration strategy be complemented with the use of autoupgrade.jar ? Since as indicated above it is necessary to migrate from non cdb (11.2.0.4) to cdb (19c).
Postscript: We don’t have licenses for Golden Gate. 🙁
Cheers,
Victor.
Hi Victor,
yes, you can use AU for the upgrade itself. See our Virtual Classroom Seminar 10 (How Low can you go) for further information and inglre that fact that it uses DBMS_ROLLING. For the upgrade itself, there is no difference between the method we show and the manual transient method:
43:04 – ROLLING: Transient Logical Standby and DBMS_ROLLING
(see the DESCRIPTION field of the video)
Cheers
Mike
Mike,
Does AutoUpgrade convert 11.2.0.4 database to a CDB/PDB architecture when upgrading to 19c?
Thanks,
Arun
Hi Arun,
sure it does – just use
upg1.target_cdb and have the CDB created.
Cheers
Mike
Hi Mike,
I have faced the issue while using autoupgrade from 11.2.0.4.0 to 19 with RU14 and OJVM patch.
Although i did 10 databases which is on 12c to 19 successfully.i have created SR
Exception: SQLException
Err message: Errors executing [@@/ora19c_01/app/oracle/product/19.0.0.0/db_home/rdbms/admin/catnorul.sql
@@/ora19c_01/app/oracle/product/19.0.0.0/db_home/rdbms/admin/catnoexf.sql
=======================
ERROR at line 1:
ORA-29532: Java call terminated by uncaught Java exception: java.lang.UnsatisfiedLinkError: java.lang.Class.forName0
ORA-06512: at “SYS.DBMS_JAVA”, line 667
ORA-06512: at line 1
======================
2022-11-12 04:55:52.127 ERROR Error running dispatcher for job 108
Cause: Runtime exception during Pre-Upgrade Fix-Up execution – AutoUpgDispatcher.errorHandling
2022-11-12 04:55:52.127 ERROR Dispatcher failed:
Error: UPG-1321
UPG-144
Do you have the SR number for me – I can’t debug issues on the blog 🙂
Cheers,
Mike
Mike,
Here is an upgrade situation. I have to upgrade a 12.1 non-CDB database to 19c CDB/PDB (single tenant). The 12.1 database is on on-premises Exadata and it has to be upgraded to 19c and migrated to Exadata Cloud at Customer. I am thinking about least number of steps in which to complete the upgrade/migrate/convert to CDB/PDB. Is it possible to clone a non-CDB 12.1 database over network as a PDB into a 19c database and then upgraded? If not, then what would be the easiest path? The database is small, 180GB. The client does not want to create a 12.1 DB HOME on ExaCC.
Thanks,
Arun
Hi Arun,
sorry for my late reply but I’ve had several weeks off now 🙂
No, you can’t “online clone” a 12.1. database. Most of the nice things work nicely with at least a 12.2.0.1 source.
See:
https://mikedietrichde.com/2019/07/23/database-migration-from-non-cdb-to-pdb-upgrade-plug-in-convert/
https://mikedietrichde.com/2019/07/25/database-migration-from-non-cdb-to-pdb-clone-via-noncdb-upgrade-convert/
Cheers
Mike
Hello Mike,
For some reason, the link to Intel upgrade story is showing “Not found” page.
By any chance, are Intel now not happy with 19c? 🙂
Hi Narendra,
I am checking with the MAA team what has happened to the original blog post. And I am not aware of any turbulence.
I will update the blog post as soon as I receive a reply – and THANKS A LOT for pointing me to it.
Cheers,
Mike