Oracle database and grid home patches to install

This blogpost is about Oracle database and grid infrastructure software homes, which patches should be applied to which homes, and what it then looks like. This is fully documented by MyOracleSupport notes, but you will see that with version 18 and up this is unclear.

I keep a script-set that automatically installs and patches the Oracle database software and creates a database. This script-set is called vagrant-builder, and it can install any version with any PSU applied between up to 19.5, which is the latest PSU of the latest version, with a few exceptions: for and I only created an install for the base version and the latest PSU for the database, and version is left out entirely.

I recently reviewed my installs and verified everything is carried out correctly. First a simple overview of what I think should be applied on the database and grid infrastructure install:

Version  Grid               Database
-------- ------             ---------- -                  DB PSU -                  DB PSU+OJVM GI PSU+JDBC patch  DB PSU+OJVM GI PSU+JDBC patch  DB PSU+OJVM GI PSU             DB PSU+OJVM
18       GI PSU             DB PSU+OJVM
19       GI PSU             DB PSU+OJVM

(‘-‘ means not investigated)
My idea of what should be applied is based on MOS note 1929745.1: Oracle recommended patches.

Grid patches, JDBC patch
The JDBC patch for grid infrastructure and is a patch that updates java classes. Therefore the patch is a generic one, the java classes do not contain operating system dependent machine code. The table in the MOS note also show differences for the JDBC patch between = januari 2014 = july 2016 and higher. No surprise there. It’s especially easy because all versions in premier support as of the date of this blogpost do not need the JDBC patch.

Grid patches, GI PSU
For the GI PSU, there are a lot of patches that contain the GI PSU, because outside of the GI patch itself, there are also combination patches that for example contain both the GI and the DB PSU. I like to keep it as simple as I can. Therefore, I stick to MOS note 2118136.2: Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), bundle patches, Patchsets and Base releases, and look at the following:
– versions Oracle Database PSU, SPU(CPU), Bundle Patches (Versions 12.1 & lower), version (, GI PSU column.
– versions and up: Oracle Database Updates, version (,,, GI Update column.

Database patches, DB PSU
Here too there are multiple patches that can be used to apply the DB PSU, and I stick with MOS note 2118136.2: Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), bundle patches, Patchsets and Base releases, and look at the following:
– versions Oracle Database PSU, SPU(CPU), Bundle Patches (Versions 12.1 & lower), version (, PSU column.
– versions and up: Oracle Database Updates, version (,,, DB Update column.

Database patches, OJVM
There are multiple MOS documents talking about the database JavaVM patch, and there are multiple patches, but here I stick with MOS note 2118136.2: Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), bundle patches, Patchsets and Base releases once again, and look at the following:
– OJVM Update/PSU/Bundle Patches,, OJVM Update.

Okay. So we got the table above that is based on MOS note 1929745.1, and we got all the patches organised in MOS note 2118136.2. So that’s nice and simple, right?

Well, not entirely…

As I said, I was checking up on the latest PSU installs. This is the ‘opatch lspatches’ overview of and

GI 190716
29509318;OCW PATCH SET UPDATE (29509318)
29494060;Database Patch Set Update : (29494060)
29423125;ACFS PATCH SET UPDATE (29423125)
26983807;WLM Patch Set Update: (26983807)
DB 190716
29774383;Database PSU, Oracle JavaVM Component (JUL2019)
29494060;Database Patch Set Update : (29494060)
GI 191015
30138470;Database Oct 2019 Release Update : (30138470)
30122828;ACFS OCT 2019 RELEASE UPDATE (30122828)
30122814;OCW OCT 2019 RELEASE UPDATE (30122814)
30093408;TOMCAT RELEASE UPDATE (30093408)
26839277;DBWLM RELEASE UPDATE (26839277
DB 191015
30133625;OJVM RELEASE UPDATE: (30133625)
30138470;Database Oct 2019 Release Update : (30138470)

For the database (DB), we see two patches, which is exactly what is expected.
– The database patch, which is called release update with one and patch set update with the other.
– The OJVM update which also named differently between the two versions, but very much recognisable as such.
I think it’s bad that the names vary, but this is totally expected.

For the grid infrastructure (GI), we see 5 patches in both situations, but these are not the same patches between the homes!
– The unnamed patch in the home is the JDBC patch, which should only be applied to, not to higher versions.
– The OCW patch (oracle clusterware).
– The database patch.
– The ACFS patch. The version indication in the patch name changed.
– The WLM/DBWLM patch. Sadly the name changed, and the name with is actually quite useless, I can’t tell the actual version, I have to look up the patch number.
– Starting from version, there is a tomcat installation in the grid home, as this patch indicates. The name here is not helpful because it doesn’t indicate the actual version, like with the DBWLM patch.

So, outside of in my opinion bad naming, and a weird inclusion of a competing product of Oracle (Tomcat versus Weblogic), this still follows the rules of logic.

Now let’s look at the same output for version 18 and 19:

GI 18.8
30116128;ACFS RELEASE UPDATE (30116128)
30113775;OCW RELEASE UPDATE (30113775)
30112122;Database Release Update : (30112122)
30093398;TOMCAT RELEASE UPDATE (30093398)
28655963;DBWLM RELEASE UPDATE (28655963)
27923415;OJVM RELEASE UPDATE: (27923415)
DB 18.8
30133603;OJVM RELEASE UPDATE: (30133603)
30112122;Database Release Update : (30112122)
28090553;OCW RELEASE UPDATE (28090553)
GI 19.5
30125133;Database Release Update : (30125133)
30122167;ACFS RELEASE UPDATE (30122167)
30122149;OCW RELEASE UPDATE (30122149)
29401763;TOMCAT RELEASE UPDATE (29401763)
DB 19.5
30128191;OJVM RELEASE UPDATE: (30128191)
30125133;Database Release Update : (30125133)
29585399;OCW RELEASE UPDATE (29585399)

I must say that the naming in general looks more consistent, that is a good thing!

For the database (DB) we see THREE patches (I suspected 2):
– The database release update patch, which nicely reports its version.
– The OVM patch, which also reports its version.
– This is weird. One of the grid infrastructure patches, the “OCW” patch, is applied to the database home. In fact, this is applied to the base release. Because it’s not a patch that is documented to be needed to be applied, this will sit at this version and never be updated. However, this unexpected patch is consistently applied to the base release for both version 18 and 19.

For the grid home (GI) we see an inconsistent number of patches (!) between 18.8 and 19.5. This is partly as expected, but I found an weird patch applied too. Let’s go over the patches:
– The ACFS patch is totally expected and appropriately named.
– The OCW patch is expected and appropriately named too.
– The Database Release Update patch is expected and appropriately named.
– The TOMCAT patch is expected. I don’t understand why it can’t have the RU numbering, but at least it’s consistent between 18 and 19.
– The DBWLM patch is only applied to the 18 home. As far as I understand, this is how it’s supposed to be, DBWLM is not regularly updated like the other ones above, so it’s okay to have an older version of it with the other patches, and if there isn’t a patch to apply, it can simply not be there, like with version 19 in this case.
– The OJVM patch puzzles me. I don’t know what to think of it. Also, it’s only applied to the base release of version 18, not to the base release of version 19. This, very much like the OCW patch, will never be updated. But I just don’t understand, this patches the java virtual machine in the database, which for GI is the ASM instance, for which, as far as I know, the java virtual machine isn’t used.

The naming of the patches as visible with “opatch lspatches” has certainly improved with version 18 and higher. Still it would be helpful if the grid infrastructure tomcat patch would follow the same naming of the other patches.

I am in doubts about the inclusion of two patches in the base releases of versions 18 and 19:
The OJVM patch inclusion in the base release of grid infrastructure of version 18 only.
The OCW patch inclusion in the base release of the database of version 18 and 19.

After debating this on twitter and with my colleagues, I found that my OCW assumptions were incorrect. The grid infrastructure patch versions 12.2 and up reasonably clearly describes that the OCW sub-patch that is part of the GI PSU/RU patch should be applied to the database home too (if cluster ware is used for that home). So that means that if you got another version of the database home than the grid infrastructure home and it is used with grid infrastructure, you should download the grid infrastructure PSU/RU patch and apply the OCW sub patch to the oracle database home, because the OCW patch is not in the database PSU/RU patch.
Because the database home patch itself is also in the grid infrastructure PSU/RU patch, I see no reason to bother downloading the database patch, and now only download and use the grid infrastructure PSU/RU patch, because that contains the database home patch as well as the OCW patch.

Addendum 2.
The OCW patch being installed into the grid infrastructure home and additionally in the database home turns out to be a change with PSU Before that, the OCW patch did exist with the grid infrastructure home patch, but couldn’t be applied to the database home. This change was documented in the patch readme, but wasn’t really heavily marketed by Oracle.

Addendum 3.
Despite OCW being documented as being additionally applied to the database home for and higher, in my tests it was not possible to apply the OCW patch to a database home for any PSU; opatch fails with a dependency problem. It does succeed starting from ( not tested) and higher.

I have to say that when looking in the OCW patch metadata, it says ‘rac’, so the OCW patch might succeed when the home is explicitly installed for a cluster database. I tested with grid infrastructure installed for a single machine (“siha”).

  1. Arnost said:

    OCW Release Update is mentioned in GI RU readme. It has to be installed in both homes, grid and DB.
    Your work on vagrant-builder is awesome.

    • Yes, I got pointed to the GI patch readme, which indeed mentions patching the DB home with the GI patch OCW patch. So a database home that has databases that interact with GI, should have the OCW patch installed along with the DB PSU or RU, while the OCW patch is made available only in the GI PSU/RU.

      I think this is confusing and not obvious to me.

      If you got multiple database homes (which is a given in most real life situations) on a system with GI, you must download the GI patch, not the DB patch to patch a DB home in order to be able to apply both the DB patch and the OCW patch.

      This means I need to change my vagrant-builder script-set to download the GI patch for the DB home to be able to patch OCW.

      • Arnost said:

        could it be possible to separate patch download from installation roles? I am trying to use your ansible roles for installing server with no access to internet. I have setup new roles for downloading patches to my local machine and copy them to stage directory on the server.
        I am also trying to use CRS_SWONLY install option because it is needed for ASMFD driver installation. CRS stack is configured after ASMFD driver installation.


  2. Hi Arnost, you should pull the latest version from gitlab. I reworked some things, and one of these is patch downloading. In the latest version, it will first look in files/ for ANY individual file before trying to download. In fact, the patch downloading is put in a task file which is run for every patch, instead of the same sequence in all the roles.
    This would also allow to put your own procedure in it, if you can’t or don’t want to download and pull the files from a central location.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: