Patching to Oracle 19.19.0 out-of-place with additional patches

From all my quarterly blog posts you know that I patch usually in-place for space and other reasons. And you may have similar reasons when you patch. But it is not ideal – and just speaking about risk and downtime, you should always patch out-of-place. So let me show you how Patching to Oracle 19.19.0 out-of-place with additional patches works.

What do I need?

Actually, this is not complicated at all. And if you never done it this way, give it a try now please.

  • Base release Oracle Database 19.3.0 image
  • opatch 37 from April 2023
  • Release Update 19.19.0 from April 2023
  • Data Pump Bundle Patch on top of RU 19.19.0 from April 2023
  • OJVM Patch Bundle 19.19.0 from April 2023
  • MRP1 on top of 19.19.0 from May 2023

And of course, you can add more fixes. Just make sure they are built on top of 19.19.0. The above list is conflict free to each other. I described the process already here. But today I will add more patches, and then have AutoUpgrade patch my database to the new home.

 

Where do I start?

Starting point is my new home. I will unpack the base release 19.3.0 into this home. And of course, set your environment correctly before you start.

cd /u01/app/oracle/product
mkdir 1919
cd 1919

cp /home/oracle/stage/LINUX.X64_193000_db_home.zip .
unzip LINUX.X64_193000_db_home.zip
rm LINUX.X64_193000_db_home.zip

rm -rf OPatch
cp /home/oracle/stage/p6880880_210000_Linux-x86-64.zip .
unzip p6880880_210000_Linux-x86-64.zip
rm p6880880_210000_Linux-x86-64.zip

I need to remove the existing OPatch subdirectory, and exchange it with the most current one. Always include this step, regardless of what the readmes tell you.

 

Let’s prepare our patches

It’s key that you separate all additional patches and bundles into separate subdirectories. Otherwise, you will overwrite the PatchSearch.xml file, and patches can’t be accessed and installed.

.
├── dpbp
│   ├── 35261302
│   └── PatchSearch.xml
├── mrp
│   ├── 35333937
│   └── PatchSearch.xml
├── ojvm
│   ├── 35050341
│   └── PatchSearch.xml
└── ru
    ├── 35042068
    └── PatchSearch.xml

 

We can kick it off

Now let me install everything with just one command. And since the MRP currently is not known to the OUI (aka runInstaller), I need to add every of its subdirectories separately. This will be fixed in a later RU.

├── mrp
│   ├── 35333937
│   │   ├── 34340632
│   │   ├── 35012562
│   │   ├── 35037877
│   │   ├── 35116995
│   │   ├── 35225526
│   │   ├── README.html
│   │   └── README.txt
│   └── PatchSearch.xml

Hence, my string will become a bit lengthy:

./runInstaller -applyRU /home/oracle/stage/ru/35042068 -applyOneOffs /home/oracle/stage/ojvm/35050341,/home/oracle/stage/dpbp/35261302,/home/oracle/stage/mrp/35333937/34340632,/home/oracle/stage/mrp/35333937/35012562,/home/oracle/stage/mrp/35333937/35037877,/home/oracle/stage/mrp/35333937/35116995,/home/oracle/stage/mrp/35333937/35225526

So what am I doing?

I use the command:

./runInstaller -applyRU ... -applyOneOffs ...

where I separate the one-offs (the OJVM and the Data Pump Bundle Patch are technically one-offs as well) by comma. Once Bug 35251760 – ADD SUPPORT FOR “NAPPLYONEOFFS” TO BE ABLE TO INSTALL MULTIPLE ONEOFFS OR MRP USING GRIDSETUP/RUNINSTALLER will be fixed, you’ll be able to pass on the main bug number for the MRP, and it will fetch the subpatches automatically.

 

And then it installs and applies

Now it will take a bit – but not too long usually.

Once we are here (in my VBox environment on my laptop’s SSD this finishes in 12 minutes):

$ ./runInstaller -applyRU /home/oracle/stage/ru/35042068 -applyOneOffs /home/oracle/stage/ojvm/35050341,/home/oracle/stage/dpbp/35261302,/home/oracle/stage/mrp/35333937/34340632,/home/oracle/stage/mrp/35333937/35012562,/home/oracle/stage/mrp/35333937/35037877,/home/oracle/stage/mrp/35333937/35116995,/home/oracle/stage/mrp/35333937/35225526

Preparing the home to patch...
Applying the patch /home/oracle/stage/ru/35042068...
Successfully applied the patch.
Applying the patch /home/oracle/stage/ojvm/35050341...
Successfully applied the patch.
Applying the patch /home/oracle/stage/dpbp/35261302...
Successfully applied the patch.
Applying the patch /home/oracle/stage/mrp/35333937/34340632...
Successfully applied the patch.
Applying the patch /home/oracle/stage/mrp/35333937/35012562...
Successfully applied the patch.
Applying the patch /home/oracle/stage/mrp/35333937/35037877...
Successfully applied the patch.
Applying the patch /home/oracle/stage/mrp/35333937/35116995...
Successfully applied the patch.
Applying the patch /home/oracle/stage/mrp/35333937/35225526...
Successfully applied the patch.
The log can be found at: /u01/app/oraInventory/logs/InstallActions2023-05-22_02-57-50PM/installerPatchActions_2023-05-22_02-57-50PM.log
Launching Oracle Database Setup Wizard...

I will need to pass in my root command in the OUI’s screen:

Patching to Oracle 19.19.0 out-of-place with additional patches

And another screen:

Patching to Oracle 19.19.0 out-of-place with additional patches

And another screen …:

Patching to Oracle 19.19.0 out-of-place with additional patches

And more … I am silently hoping that there are ways to suppress these screens …

And now the important screen:

Patching to Oracle 19.19.0 out-of-place with additional patches

 

And then we are (almost) done

Well, finally after all these clicks, I’m getting to the OUI’s summary page where I can click the “Install” button:

Patching to Oracle 19.19.0 out-of-place with additional patches

Which I happily do – but just to get to a screen I will never understand:

Patching to Oracle 19.19.0 out-of-place with additional patches

Didn’t I say before (and confirm by passing on my root credentials) that I want the OUI do this for me? I have no idea why this screen is coming up …

Patching to Oracle 19.19.0 out-of-place with additional patches

Installation with all patches complete.

Let me do a quick check before we continue:

$ $ORACLE_HOME/OPatch/opatch lspatches

35225526;FRA E18POD EPM | ORA-00942  TABLE OR VIEW DOES NOT EXIST WHEN RUNNING SELECT QUERY
35116995;19.X DATAPATCH FAILS WITH ORA-01422 ,ORA-20004  NO FILE FOUND IN SCRIPT RDBMS/ADMIN/NOTHING.SQL
35037877;EM CODE IS BROKEN IN 19.18
35012562;OR EXPANSION IS NOT PICKED UP IN QUERY WITH CONTAINS OPERATOR AFTER UPGRADE TO 19C
34340632;AQAH  SMART MONITORING & RESILIENCY IN QUEUE KGL MEMORY USAGE
35261302;DATAPUMP BUNDLE PATCH 19.19.0.0.0
35050341;OJVM RELEASE UPDATE: 19.19.0.0.230418 (35050341)
35042068;Database Release Update : 19.19.0.0.230418 (35042068)
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)

OPatch succeeded.

This looks good.

 

But I am still not done

Final steps is to lift my databases to the new home. You can – of course – do this database-by-database. But we are in a modern IT environment and hence, we will use AutoUpgrade certainly and automate this task.

Let’s have a look at the config file at first:

global.autoupg_log_dir=/home/oracle/upg_logs
global.timezone_upg=no
global.restoration=no

upg1.source_home=/u01/app/oracle/product/19
upg1.target_home=/u01/app/oracle/product/1919
upg1.sid=CDB2

And then I can kickoff AutoUpgrade to lift my database from 19.18.0 to 19.19.0 and execute all the necessary checks and steps.

$ java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar -config PATCH.cfg -mode deploy

AutoUpgrade is not fully tested on OpenJDK 64-Bit Server VM, Oracle recommends to use Java HotSpot(TM)
AutoUpgrade 22.5.221011 launched with default internal options
Processing config file ...
+--------------------------------+
| Starting AutoUpgrade execution |
+--------------------------------+
1 CDB(s) plus 1 PDB(s) will be processed
Type 'help' to list console commands

upg>

And shortly later …

upg> lsj
+----+-------+---------+---------+-------+----------+-------+-------------------+
|Job#|DB_NAME|    STAGE|OPERATION| STATUS|START_TIME|UPDATED|            MESSAGE|
+----+-------+---------+---------+-------+----------+-------+-------------------+
| 100|   CDB2|DBUPGRADE|EXECUTING|RUNNING|  23:04:44|24s ago|0%Patching CDB$ROOT|
+----+-------+---------+---------+-------+----------+-------+-------------------+
Total jobs 1

Now AutoUpgrade completed the patching process successfully:

upg> Job 100 completed
------------------- Final Summary --------------------
Number of databases            [ 1 ]

Jobs finished                  [1]
Jobs failed                    [0]
Jobs restored                  [0]
Jobs pending                   [0]

All set. And you can automate this perfectly well for all your databases.

 

Are we done now?

Not fully. Once you are fine with the new home, all is working well, you may want to cleanup the previous, old home. And in addition, you may also cleanup the patch leftovers from the previous patch run as I explained in Cleaning up patch artifacts and improving patching performance.

One of the real benefits with out-of-place patching is that you can go back to the previous home easily – while when you patch in-place, you will have a lot of extra work to do rolling out patches in the right order.

 

And there may be more …

Please take into account certain files you may need to move around by yourself:

 

Further Links and Information

–Mike

Share this: