Patching my databases with the July 2018 PSU, BP and RU

Patching my databases with the July 2018 PSU, BP and RUAs usual I download the patch bundlesΒ  and apply them to our Hands-On Lab environment as quickly as possible. First of all for the simple reason that I don’t want to trap into issues which are fixed already. Second for the reason that I always tell you: YOU MUST PATCH! But if I’m saying this over and over again, then I can’t have my own environments unpatched. And at third, because I want to learn if anything is not working correctly or has changed (see below).

Of course my tiny single instance environments are not comparable to your critical production sites. And I don’t have to complete any extra tests. Or include the patch into a Rapid Home Provisioning rollout plan. So for me it’s a fairly simple task whereas for you it usually involves more work.

Patching my databases with the July 2018 PSU, BP and RU

As you can see from my previous blog post, I figured out already which patches I need to download, I learned about the July 2018 Risk Matrix scores, and I checked the READMEs as well.

Then as next step, I will have to verify the prerequisites including OPatch, and afterwards apply the patch bundles. I don’t patch OJVM as I didn’t include it in any of my databases.

Prerequisites

For the Oracle 11.2.0.4 PSU I must ensure OPatch utility version 11.2.0.3.6 is installed. In my case it is already. Hence, no action needed here. But for Oracle 12.1.0.2 there’s a change.

Important change:
Different from previous runs where I simply used the 12.2/18c OPatch as you could see in April 2018 to patch also my Oracle 12.1.0.2 databases, this will fail now since the OPatch 12.2.0.1.14 version.
When you invoke it from a different home, you’ll see the below error pattern.
Thus, you MUST install the version of OPatch into your 12.1.0.2 homes now as well.

$OH18/OPatch/datapatch -verbose
...
Queryable inventory could not determine the current opatch status.
Execute 'select dbms_sqlpatch.verify_queryable_inventory from dual'
and/or check the invocation log
/u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_16186_2018_07_18_13_07_29/sqlpatch_invocation.log
for the complete error.
Prereq check failed, exiting without installing any patches.
...
SQL> select dbms_sqlpatch.verify_queryable_inventory from dual;

VERIFY_QUERYABLE_INVENTORY
--------------------------------------------------------------------------------
ORA-20001: Latest xml inventory is not loaded into table

As far as I can see, there reason seem to be the 3 directories OPatch creates in the database (see DBA_DIRECTORIES). But I didn’t went into details as my shortcut most likely wasn’t meant to work anyways. Hence, I can’t blame anybody πŸ™‚

For Oracle 18.3.0 the OPatch requirement is now OPatch utility version 12.2.0.1.14. As my current version is Opatch 12.2.0.1.13 I will need to update it via patch 6880880.

Patching my databases with the July 2018 PSU, BP and RU

In the README I find the following install instructions:

  1. Please take a backup of ORACLE_HOME/OPatch into a dedicated backup location.
  2. Please make sure no directory ORACLE_HOME/OPatch exist.
  3. Please unzip the OPatch downloaded zip into ORACLE_HOME directory

This is not complicated.

. cdb2
cd $ORACLE_HOME
tar -czf opatch_old_del_later.tar OPatch
rm -rf OPatch
cp /media/sf_TEMP/p6880880_180000_Linux-x86-64.zip .
unzip p6880880_180000_Linux-x86-64.zip
cd OPatch

Afterwards I verify the version – and this looks good.

[CDB2] oracle@localhost:/u01/app/oracle/product/18/OPatch
$ ./opatch version
OPatch Version: 12.2.0.1.14

OPatch succeeded.

Good thing: I can use this version also for the 12.1.0.2 patching but I will have to install it this time separately into my 12.1.0.2 home as well.

Patching Oracle 11.2.0.4 with the July 2018 Patch Set Update

As I don’t have an Engineered System unfortunately, I patch my single instance 11.2.0.4 environment with the July PSU.

And as I showed the task in step-by-step instructions already in April, I recorded a short 3 min video this time:

.

Patching Oracle 12.1.0.2 with the July 2018 Bundle Patch

Please find all the steps in the README. As noted above it is now important to have the OPatch utility installed into the same Oracle Home as otherwise the inventory can’t be queried within the database.

.

Patching Oracle 18.1.0 with the July 2018 Update

I have applied the 18.2.0 Update already a few weeks ago to my Oracle 18.1.0 environment. But for this exercise I use a standard 18.1.0 environment. For most of you this task won’t be necessary as you’ll start off with Oracle 18.3.0 on premises anyway, and hence don’t have to apply the July 2018 Update (RU).

All the necessary steps are similar to Oracle 12.2.0.1 patching. You can find them in the README.

In brief:

$ORACLE_HOME/OPatch/opatch version

$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /media/sf_TEMP/p28090523_180000_Linux-x86-64/28090523

cd /media/sf_TEMP/p28090523_180000_Linux-x86-64/28090523

$ORACLE_HOME/OPatch/opatch apply

$ORACLE_HOME/OPatch/datapatch -verbose

But please see the short video below:

.

–Mike

10 thoughts on “Patching my databases with the July 2018 PSU, BP and RU

  1. Hi Mike,

    First of all thanks for your blogs, they are always handy πŸ™‚

    Let’s go to the questions, shall we ?

    I used to find the client-installation patchset in the full RDBMS patcheset.

    Do you happen to know where I can find the RU (12.2.0.1 – July 17, 2018) for OCI Client on linux x64 ?

    Cheers.

    Alessio.

  2. is there any way to clean up the sql_patch dictionary views in the database if cloned from non patched home.

    i.e. we have an oracle home with DATABASE BUNDLE PATCH: 12.1.0.2.160719 (23144544) and there is cloned databases from the same version

    now i updated the cloned database rdbms home to july 2018 but i’m getting the below error

    Connecting to database…OK
    Bootstrapping registry and package to current versions…done
    Determining current state…done

    Current state of SQL patches:
    Patch 23177536 (Database PSU 12.1.0.2.160719, Oracle JavaVM Component (JUL2016)):
    Installed in the SQL registry only
    Bundle series DBBP:
    ID 180717 in the binary registry and ID 160719 in the SQL registry

    Adding patches to installation queue and performing prereq checks…
    Installation queue:
    The following patches will be rolled back:
    23177536 (Database PSU 12.1.0.2.160719, Oracle JavaVM Component (JUL2016))
    The following patches will be applied:
    27547374 (DATABASE BUNDLE PATCH 12.1.0.2.180717)

    Error: prereq checks failed!
    patch 23177536: Archived patch directory is empty
    Prereq check failed, exiting without installing any patches.

    Please refer to MOS Note 1609718.1 and/or the invocation log
    /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_3505_2018_07_19_11_38_58/sqlpatch_invocation.log
    for information on how to resolve the above errors.

    SQL Patching tool complete on Thu Jul 19 11:39:38 2018

    • Samer,

      this is a typical and known issue. When you clone often the patch directory for the previous patch is not present anymore. The workaround I know: copy this directory to the new home, then it can be rolled back.

      Please see here:
      https://support.oracle.com/epmos/faces/DocumentDisplay?id=2235541.1
      And ignore the first workaround which is complete nonsense as nobody can rollback a patch before cloning in PROD.

      Cheers,
      Mike

      PS: And yes, I know this is a “questionable design”. Yes …

  3. Hi πŸ™‚
    1. Please take a backup of ORACLE_HOME/OPatch into a dedicated backup location.
    Solution:
    rm -rf OPatch

    Good approach πŸ™‚

    • Don’t be so picky, Arek. It’s a burn&destroy testing environment in my case πŸ˜‰
      But for your convenience I added a “tar -czf opatch.tar OPatch” πŸ˜‰

      Cheers,
      Mike

      PS: I don’t really understand the idea of backing up the opatch directory. I can always install almost any version.

  4. Any video on how to apply “this” (Patching Oracle 12.1.0.2 with the July 2018 Bundle Patch) to a ASM GRID RAC infrastructure? The information given in the readme are confusing and outdated.

Leave a Reply

Your email address will not be published. Required fields are marked *

* Checkbox to comply with GDPR is required

*

I agree

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