As 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.
For the Oracle 188.8.131.52 PSU I must ensure OPatch utility version 184.108.40.206.6 is installed. In my case it is already. Hence, no action needed here. But for Oracle 220.127.116.11 there’s a 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 18.104.22.168 databases, this will fail now since the OPatch 22.214.171.124.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 126.96.36.199 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 188.8.131.52.14. As my current version is Opatch 184.108.40.206.13 I will need to update it via patch 6880880.
In the README I find the following install instructions:
- Please take a backup of ORACLE_HOME/OPatch into a dedicated backup location.
- Please make sure no directory ORACLE_HOME/OPatch exist.
- 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: 220.127.116.11.14 OPatch succeeded.
Good thing: I can use this version also for the 18.104.22.168 patching but I will have to install it this time separately into my 22.214.171.124 home as well.
Patching Oracle 126.96.36.199 with the July 2018 Patch Set Update
As I don’t have an Engineered System unfortunately, I patch my single instance 188.8.131.52 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 184.108.40.206 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 220.127.116.11 patching. You can find them in the README.
$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:
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 (18.104.22.168 – July 17, 2018) for OCI Client on linux x64 ?
very good question.
But it’s here:
Oracle Support Document 2394520.1 (Critical Patch Update (CPU) Program July 2018 Patch Availability Document (PAD)) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=2394520.1
Search for “client” in the document and you’ll see it.
Database Update 22.214.171.124.170718 Patch 26123830
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: 126.96.36.199.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 188.8.131.52.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…
The following patches will be rolled back:
23177536 (Database PSU 184.108.40.206.160719, Oracle JavaVM Component (JUL2016))
The following patches will be applied:
27547374 (DATABASE BUNDLE PATCH 220.127.116.11.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
for information on how to resolve the above errors.
SQL Patching tool complete on Thu Jul 19 11:39:38 2018
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:
And ignore the first workaround which is complete nonsense as nobody can rollback a patch before cloning in PROD.
PS: And yes, I know this is a “questionable design”. Yes …
Thanks for the detail information.
1. Please take a backup of ORACLE_HOME/OPatch into a dedicated backup location.
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” 😉
PS: I don’t really understand the idea of backing up the opatch directory. I can always install almost any version.
Any video on how to apply “this” (Patching Oracle 18.104.22.168 with the July 2018 Bundle Patch) to a ASM GRID RAC infrastructure? The information given in the readme are confusing and outdated.
If you give me access to your cluster, Frank 😉
I don’t have a RAC system.
And setting it up on my tiny little Mac book will not work …
Thanks for coming back on this to me.
We perform out-of-place patching.
We had to rollback the July 2018 PSU(22.214.171.124 + Jul 2018 PSU) and apply Jan 2018 PSU(126.96.36.199 + Jan 2018 PSU).
We shutdown the database from Home with Jul 2018 PSU and started one instance in upgrade mode from Jan 2018 PSU ORACLE_HOME. It did not work.
Datapatch was able to rollback July PSU but did not install Jan PSU. Is this expected ?
I found that in the Bundle_id column the value was 180116 for the entry for ROLLBACK of Jul PSU.
* select PATCH_ID,PATCH_UID,VERSION,FLAGS,ACTION,INSTALL_ID,BUNDLE_SERIES,BUNDLE_ID,action_time from dba_registry_sqlpatch where BUNDLE_SERIES=’DBRU’
PATCH_ID PATCH_UID VERSION FLAGS ACTION INSTALL_ID BUNDLE_SERIES BUNDLE_ID ACTION_TIME
———- ———- ——————– ———- ————— ———- —————————— ———- —————————————————————————
28163133 0 0 NB APPLY 1 DBRU 180717 01-AUG-18 03.27.40.522063 PM
28163133 22313390 188.8.131.52 NB APPLY 2 DBRU 180717 01-AUG-18 04.00.23.374650 PM
28163133 22313390 184.108.40.206 NB ROLLBACK 3 DBRU 180116 21-AUG-18 07.29.35.869762 AM
Could you please let me know the best way to achieve this? Thanks
sorry to read this. And I feel bad when I see such messages.
Unfortunately I can’t diagnose such issue – you will have to log an SR but I’m always happy to read about the solution.
I was away the past two weeks – I hope you could solve it in between.
We rolled back the July 2018 RU from current home and stopped the database,
We then started the database from new home(220.127.116.11 + Jan 2018 RU) and executed Datapatch.
This way, it complained about Database Vault and OLS is not present. We did not install these to start with.
Not sure why did Datapatch complain about the components those were never installed in the first place.
Worked with Oracle Support and they asked us to create Database Vault schema (and its metadata) and enable OLS (using Doc ID 2176049.1)
Argh … I think the reason is that datapatch is not component agnostic. Meaning, if a patch contained a specific fix for lets say DV and you had no DV present, it failed. I thought this had been fixed and included. But when I read your message I have my doubts.
What should I say 🙁
But I checked the note you are referring to: 2176049.1
And I disagree with the content. There’s no such thing as a mandatory DV. None of my databases in my test envs has DV installed.
I read it now 3 times and maybe I don’t get the point.
I think the problem is NOT the non-existence of DV or OLS but the fact that datapatch has changes for a component which is not present but does not recognize the component isn’t present.
can you either copy/paste me the SR number or send it to me to: email@example.com ?
I am putting together instructions on applying the July 2018 QFSDP to Exadata and noticed that the OJVM patching instructions (README.html) for 18.104.22.168 and 22.214.171.124 databases just says:
“README is being worked”
The README paths are:
The README.html for 18.3 has complete instructions in the same patch. I have opened a SR. See what support says.
Support supplied a resolution. The README for each version is available online:
https://updates.oracle.com/download/27923163.html >>>>>> Patch 27923163 OJVM PATCH SET UPDATE 126.96.36.199.180717
https://updates.oracle.com/download/27923320.html >>>>>> Patch 27923320 OJVM PATCH SET UPDATE 188.8.131.52.180717
Good – and thanks for raising the SR and for the update.
I recently applied Q3 2018 PSU to a standalone 184.108.40.206 database with Oracle Restart configuration. The initial attempt failed as I had not stopped database and a DBA had left a sqlplus process open. Upon subsequent opatch auto run, while the grid home got patched correctly, the database home is still showing old OCW patch. Any idea how I can get only OCW patched? Below are opatch details (post patching)
$ $ORACLE_HOME/OPatch/opatch lspatches
27959254;ACFS Patch Set Update : 220.127.116.11.180717 (27959254)
27441052;OCW PATCH SET UPDATE: 18.104.22.168.180417 (27441052)
27734982;Database Patch Set Update : 22.214.171.124.180717 (27734982)
$ $ORACLE_HOME/OPatch/opatch lspatches
27923163;OJVM PATCH SET UPDATE 126.96.36.199.180717
27734982;Database Patch Set Update : 188.8.131.52.180717 (27734982)
23054319;OCW Patch Set Update : 184.108.40.206.160719 (23054319)
apply the OCW patch again to the database home (after stopping all services).
This should do the trick.
I guess that there were services up and hence files and the inventory couldn’t be changed.
I’d guess as well that the patch apply didn’t succeed and got rolled back for the subcomponent OCW.
This is where I am struggling. According to support note Doc ID 1595371.1, it seems OCW patch can not be separately downloaded and when I tried applying patch 27967757 again, it still did not appear to have updated DB home with correct patch for OCW. Am I missing anything?
but you can install it separately even if it’s not available as a separate download.
You need to enter the 27441052 subdirectory and install the patch.
Otherwise please open an SR and check with Oracle Support.
Do we need to Apply OCW, DBWLM and ACFS patches coming with GI PSU to our grid home? As i have single Grid home and single Oracle Instance hosted on single server.
OCW of course for sure as this is Oracle Clusterware.
DBWLM is Workload Management (or Quality of Service). I honestly doubt that you are using it.
ACFS: depends if you are using ACFS or not.
opatchauto wont let me install individual patches, do i need to apply the patches manually then using opatch as mentioned in below note?
Example: Manually Apply a 12c GI PSU/Interim or DB Interim Patch in Standalone Environment (Doc ID 1595408.1)
I think so, yes.
After applying July 2018 patch to Exadata, we were hit by bug 28571483 (Doc ID 28571483.8). ASM instance crashed on all cluster nodes taking down databases with it. We had to apply interim patch 28571483 to fix the issue.
thanks for letting me know – this sounds bad!
When applying the latest PSU, do you rollback the previous PSU before applying?
No, I don’t.
Is there a change in how DST patches are built for oracle 18 both DST V32 and DST V33 had dependencies on DBRU’s 18.3 and 18.4 respectively.
Is this supposed to be how they will be built in future, what if we want to skip a RU but need the next DST Patch?
Would you please mind to drop me the patch numbers for DST V32 and DST V33.
I just realize that the owner of:
Updated DST Transitions and New Time Zones in Oracle RDBMS and OJVM Time Zone File Patches (Doc ID 412160.1)
may not have recognized that there is a new version available.
DST V32 p28125601 and DSTV33 p28852325, DBRU 18.4 p28655784
excerpt from log below:
Prerequisite check “CheckPatchApplyDependents” failed.
The details are:
Interim patch 28852325 requires prerequisite patch(es) [ 28655784 ] which are not present in the Oracle Home.
Apply prerequisite patch(es) [ 28655784 ] before applying interim patch 28852325 .
Same thing happens when u apply DSTV32 without the 18.3 RU.
The other issue is 18.4RU is a Superset of 18.3RU and when u apply 18.3RU then apply 18.4 RU it makes 18.3 inactive and then u cannot applu DST V32 after.
If you apply DSTV32 after applying 18.3RU and then want to apply 18.4RU it conflicts which it should not, have a SR going no response on it yet.
thanks a lot for sharing. I mailed the people responsible for the DST notes yesterday and asked them to update the note. Glad that you have found the patch numbers. I will download and try by myself later on.
Could you please share the SR number with me? I’m highly interested!
SR 3-19243289641, thanks for the help.
I see the SR and check now in my env. Will get back to you later.
I verified the issue you are seeing – I see exactly the same as you. And I think this is a bug. There’s no reason for binding a time zone patch to a specific RU – it would fail for an RUR for instance as well. This makes no sense and was handled differently until 220.127.116.11 where we had RUs already.
Please follow up with the SR and escalate it if necessary. I will drop the owner an email as well.
Thanks for bringing this to my attention.