Quarterly routine: When the new security alert get published, then it is patching time again. I’ll show you as usual how Patching all my environments with the July 2020 Patch Bundles works. And I heard your comments – in the next round in October, I will do this for GI and OJVM most likely, too. If not earlier …

Photo by Piron Guillaume on Unsplash
And just an important annotation upfront: I patch in-place due to space issues. But in reality, you please patch always out-of-place with a separate home.
Security Alert July 2020
This is the Security Alert for July 2020 listing all affected platforms and products. But as usual, I watch out for Oracle Database Server, versions 11.2.0.4, 12.1.0.2, 12.2.0.1, 18c, 19c, [Spatial Studio] prior to 19.2.1]. This link guides you to the Risk Matrix for the database.
And this time, it is a longer list than usual. It contains the usual OJVM fix but also a good number of APEX ones.

Risk Matrix Oracle Database Server – July 2020
But regardless of what’s included, you should apply the RUs anyway as there are a lot more fixes in it.
For instance, it contains a fix which disables the autotask window for the SYS_AUTO_STS I wrote about a few weeks ago.
Database Patch Bundles
You will find the links to the database patches in MOS Note: 2664876.1 – Critical Patch Update (CPU) Program Jul 2020 Patch Availability Document (PAD). In my case, this is the list of bundles:
- Oracle Database 19c
- Database Release Update 19.8.0.0.200714 Patch 31281355 for UNIX (1.4GB)
- Readme
- List of fixes: MOS Note: 2523220.1 (does not include any 19.8.0 fixes yet unfortunately)
- Database Release Update 19.8.0.0.200714 Patch 31281355 for UNIX (1.4GB)
- Oracle Database 12.2.0.1
- Database Jul2020 Release Update 12.2.0.1.200714 Patch 31312468 for UNIX (845MB)
- Readme
- Database Jul2020 Release Update 12.2.0.1.200714 Patch 31312468 for UNIX (845MB)
- Oracle Database 11.2.0.4
- Database PSU 11.2.0.4.200714 Patch 31103343 for UNIX (355MB)
- Readme
- Database PSU 11.2.0.4.200714 Patch 31103343 for UNIX (355MB)
Unfortunately, MOS Note: 2118136.2 – Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases hasn’t been updated either by the time I write this.
Do I need a new OPatch?
First check while the download is progressing: Do I need to refresh my OPatch versions?
- 19.8.0 requires opatch 12.2.0.1.21 or later
- 12.2.0.1 requires opatch 12.2.0.1.21 or later
- 11.2.0.4 requires opatch 11.2.0.3.23 or later (same requirement as in April 2020)
Patch download for OPatch is: 6880880. I wipe out my current OPatch
directories in all my three homes. Once the new OPatch bundles have been unzipped into each home, I can proceed. The 12.2.0.1.21 OPatch needs to go into both, the 12.2.0.1 and the 19c homes.
Applying RU 19.8.0 to my 19c home
At first, I unzip the patch into a separate directory.
- opatch conflict check
[CDB2] oracle@hol:/u01/app/oracle/product/19 $ cd 31281355/ [CDB2] oracle@hol:/u01/app/oracle/product/19/31281355 $ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./ Oracle Interim Patch Installer version 12.2.0.1.21 Copyright (c) 2020, Oracle Corporation. All rights reserved. PREREQ session Oracle Home : /u01/app/oracle/product/19 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/19/oraInst.loc OPatch version : 12.2.0.1.21 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2020-07-15_10-11-15AM_1.log Invoking prereq "checkconflictagainstohwithdetail" Prereq "checkConflictAgainstOHWithDetail" passed. OPatch succeeded.
- opatch apply
[CDB2] oracle@hol:/u01/app/oracle/product/19/31281355 $ $ORACLE_HOME/OPatch/opatch apply Oracle Interim Patch Installer version 12.2.0.1.21 Copyright (c) 2020, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/oracle/product/19 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/19/oraInst.loc OPatch version : 12.2.0.1.21 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2020-07-15_10-14-43AM_1.log Verifying environment and performing prerequisite checks... -------------------------------------------------------------------------------- Start OOP by Prereq process. Launch OOP... Oracle Interim Patch Installer version 12.2.0.1.21 Copyright (c) 2020, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/oracle/product/19 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/19/oraInst.loc OPatch version : 12.2.0.1.21 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2020-07-15_10-15-39AM_1.log Verifying environment and performing prerequisite checks... OPatch continues with these patches: 31281355 Do you want to proceed? [y|n] y User Responded with: Y All checks passed. Please shutdown Oracle instances running out of this ORACLE_HOME on the local system. (Oracle Home = '/u01/app/oracle/product/19') Is the local system ready for patching? [y|n] y User Responded with: Y Backing up files... Applying interim patch '31281355' to OH '/u01/app/oracle/product/19' ApplySession: Optional component(s) [ oracle.network.gsm, 19.0.0.0.0 ] , [ oracle.rdbms.ic, 19.0.0.0.0 ] , [ oracle.rdbms.tg4db2, 19.0.0.0.0 ] , [ oracle.tfa, 19.0.0.0.0 ] , [ oracle.oraolap.mgmt, 19.0.0.0.0 ] , [ oracle.xdk.parser.java.jaxb2, 19.0.0.0.0 ] , [ oracle.options.olap.awm, 19.0.0.0.0 ] , [ oracle.net.cman, 19.0.0.0.0 ] , [ oracle.assistants.asm, 19.0.0.0.0 ] , [ oracle.network.cman, 19.0.0.0.0 ] , [ oracle.sqlj, 19.0.0.0.0 ] , [ oracle.assistants.usm, 19.0.0.0.0 ] , [ oracle.options.olap, 19.0.0.0.0 ] , [ oracle.jdk, 1.8.0.191.0 ] not present in the Oracle Home or a higher version is found. Patching component oracle.rdbms, 19.0.0.0.0... Patching component oracle.rdbms.util, 19.0.0.0.0... Patching component oracle.rdbms.rsf, 19.0.0.0.0... Patching component oracle.assistants.acf, 19.0.0.0.0... [...] Patching component oracle.xdk.parser.java, 19.0.0.0.0... Patching component oracle.rdbms.rsf.ic, 19.0.0.0.0... Patching component oracle.precomp.common, 19.0.0.0.0... Patching component oracle.precomp.lang, 19.0.0.0.0... Patching component oracle.jdk, 1.8.0.201.0... Patch 31281355 successfully applied. Sub-set patch [30869156] has become inactive due to the application of a super-set patch [31281355]. Please refer to Doc ID 2161861.1 for any possible further required actions. Log file location: /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2020-07-15_10-15-39AM_1.log OPatch succeeded.
- datapatch
As final action, I will start my database and all pluggable databases again. The next step,datapatch
, requires my databases and PDBs to be open.$ $ORACLE_HOME/OPatch/datapatch -verbose SQL Patching tool version 19.8.0.0.0 Production on Wed Jul 15 10:25:31 2020 Copyright (c) 2012, 2020, Oracle. All rights reserved. Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_13501_2020_07_15_10_25_31/sqlpatch_invocation.log Connecting to database...OK Gathering database info...done Note: Datapatch will only apply or rollback SQL fixes for PDBs that are in an open state, no patches will be applied to closed PDBs. Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation (Doc ID 1585822.1) Bootstrapping registry and package to current versions...done Determining current state...done Current state of interim SQL patches: No interim patches found Current state of release update SQL patches: Binary registry: 19.8.0.0.0 Release_Update 200703031501: Installed PDB CDB$ROOT: Applied 19.7.0.0.0 Release_Update 200404035018 successfully on 15-APR-20 12.17.51.919174 AM PDB PDB$SEED: Applied 19.7.0.0.0 Release_Update 200404035018 successfully on 15-APR-20 12.17.52.317976 AM Adding patches to installation queue and performing prereq checks...done Installation queue: For the following PDBs: CDB$ROOT PDB$SEED No interim patches need to be rolled back Patch 31281355 (Database Release Update : 19.8.0.0.200714 (31281355)): Apply from 19.7.0.0.0 Release_Update 200404035018 to 19.8.0.0.0 Release_Update 200703031501 No interim patches need to be applied Installing patches... Patch installation complete. Total patches installed: 2 Validating logfiles...done Patch 31281355 apply (pdb CDB$ROOT): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/31281355/23688465/31281355_apply_CDB2_CDBROOT_2020Jul15_10_27_58.log (no errors) Patch 31281355 apply (pdb PDB$SEED): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/31281355/23688465/31281355_apply_CDB2_PDBSEED_2020Jul15_10_28_50.log (no errors) SQL Patching tool complete on Wed Jul 15 10:29:50 2020
- AutoUpgrade
As there is a new AutoUpgrade 19.9.1 available via MOS Note: 2485457.1 – AutoUpgrade Tool, I apply this right away to my home as well. And of course, if you have no intention to do any database upgrade on this host, you can safely skip this step.$ cp /media/sf_TEMP/July2020/autoupgrade1991/autoupgrade.jar $OH19/rdbms/admin $ java -jar $OH19/rdbms/admin/autoupgrade.jar -version build.hash 3b51369 build.version 19.9.1 build.date 2020/07/10 11:20:49 build.max_target_version 19 build.supported_target_versions 12.2,18,19 build.type production
- opatch util cleanup
As somebody asked me the other day about whether it is ok to remove the directory where the patch has been unziped into? Yes, of course, this is ok. The information which is necessary to rollback the patch is kept in .patch_storage. And you can cleanup a little bit of it with “opatch util cleanup” – but be aware to be on a newer version of opatch.$ $ORACLE_HOME/OPatch/opatch util cleanup Oracle Interim Patch Installer version 12.2.0.1.21 Copyright (c) 2020, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/oracle/product/19 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/19/oraInst.loc OPatch version : 12.2.0.1.21 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2020-07-15_10-41-51AM_1.log Invoking utility "cleanup" OPatch will clean up 'restore.sh,make.txt' files and 'scratch,backup' directories. You will be still able to rollback patches after this cleanup. Do you want to proceed? [y|n] y User Responded with: Y Backup area for restore has been cleaned up. For a complete list of files/directories deleted, Please refer log file. OPatch succeeded.
Don’t expect miracles please.
Everything looks good.
But generally I recognize that especially the datapatch run, but also opatch apply itself took longer than in April 2020. Datapatch ran 1 minute longer than for 19.7.0.
Applying RU 12.2.0.1.200714 to my 12.2.0.1 home
I won’t copy/paste all steps as the output is similar to the above.
- opatch conflict check
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
- opatch apply
$ORACLE_HOME/OPatch/opatch apply
Then I will need to startup my databases and all PDBs.
- datapatch -verbose
Final steps is “datapatch”. It requires the databases and all its PDBs to be up and running.$ORACLE_HOME/OPatch/datapatch -verbose
Applying PSU 11.2.0.4.200714 to my Oracle 11.2 home
For Oracle 11.2 I can only take the PSU. Bundle patches (BP) in Oracle 11.2 were only meant for Exadata systems. But the path to apply them is the same as for later bundles.
Again, I won’t copy/paste all steps as the output is similar to the above.
- opatch conflict check
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
- opatch apply
$ORACLE_HOME/OPatch/opatch apply
Then I will need to startup my databases (
FTEX
andUPGR
). - catbundle.sql
Final steps is “catbudle.sql”. It requires the databases to be up and running.cd $ORACLE_HOME/rdbms/admin sqlplus / as sysdba @?/rdbms/admin/catbundle.sql psu apply
Everything fine now. No major issues seen. But as you know, my environment is simple and doesn’t include RAC or standbys.
Delayed?
Please don’t complain to me about missing patches. The section 2.2 Post Release Patches of MOS Note: 2664876.1 – Critical Patch Update (CPU) Program Jul 2020 Patch Availability Document (PAD) lists the delayed bundles. You will find that a lot of them are supposed to be published either tonight (July 15) in my CEST time zone or within the next days (Windows for instance). From the responsible people for MOS Note: 2664876.1 I know that they are updating the note in case there are further delays.
Side Track
This is the list of new underscore parameters I detected compared to Oracle 19.7.0. I won’t offer further comments or explanations as underscores are underscores. Hence, this section is for documentation purposes only.
Parameter |
_bigdata_offload_flag |
_bug28322973_asm_ownerid_trace_timeout |
_bug29290173_securefiles_dealloc_cfs |
_bug30196629_dbopen_breakpoint |
_bug30316897_allow_fallback_to_dbkey |
_bug30346330_hang_sess_enq_wait_blocked_session_threshold |
_bug30346330_hang_sess_enq_wait_resltn_trig_time |
_bug30382982_keep_relocated_source_pdb |
_bug30624792_hang_px_resolution_on_asm_enabled |
_cell_offload_vector_groupby_external |
_disable_ilm_internal |
_ignore_svc_name_conv_mismatch |
_kks_always_check_bind_equivalence |
_ninth_spare_parameter |
_zonemap_use_enabled |
Besides that, I didn’t see any significant parameter default value changes compared to 19.7.0.
Further Links and Information
- Security Alert for July 2020
- Oracle Database Server, versions 11.2.0.4, 12.1.0.2, 12.2.0.1, 18c, 19c, [Spatial Studio] prior to 19.2.1]
- Risk Matrix for the database – July 2020
- Do you love unexpected surprises – the SYS_AUTO_STS in Oracle 19.7.0
- MOS Note: 2664876.1 – Critical Patch Update (CPU) Program Jul 2020 Patch Availability Document (PAD)
- Patching all my environments with the April 2020 Patch Bundles
- MOS Note: 2485457.1 – AutoUpgrade Tool
Hi Mike
Do you know why the “Combo OJVM Release Update 19.8.0.0.200714 and GI Release Update 19.8.0.0.200714 Patch 31326369” ist not available and will be provided a week later (21.07.2020)?
The not-combo version of the patches “GI Release Update 19.8.0.0.200714 Patch 31305339” and “OJVM Release Update 19.8.0.0.200714 Patch 31219897 for all platforms” are already available.. so only the Combo has an delay.
thx
Suli
Hi Suli,
no – I can tell you exactly what you see in the note, too.
Cheers,
Mike
And again Java VM tops the CVE Risk Score hitlist 😉
Yet another reason to kick out JAVA VM out of the databases …
Can’t comment 🙂
Cheers,
Mike
Hi Mike!
Thank you for your quarterly update demo and the helpful additional infos.
I am looking forward to see the updated bugs fixed list in Note 2523220.1 in due course.
Keep up the good work!
Best regards,
Martin
Patch # 31113348
p31113348_121020_Linux-x86-64.zip
This is the quarterly patch for Oracle Database SE 12.1.0.2.200114 running on x86-64 Linux, correct?
Patch Bundles are valid always for SE and EE.
Cheers,
Mike
Thx
Hello Mike,
2 Questions regarding the 19.x track :
1) Why the autoupgrade.jar ?
2) Do you patch out of place and if yes , how do you create the second home ? If we use read only homes a simple cp -r should suffice, shouldn’t it ?
Thanks a lot for your work and detailed explanations !
Norbert
Hi Norbert,
because I upgrade quite often – and you may, too 🙂
But if you have no intention to do any database upgrades to 19c on this box, you can safely ignore my advice. I will add a comment in brackets 🙂
I patch in place due to space issues – but in reality, you’d please patch always out-of-place 🙂
Cheers,
Mike
Hello Mike, I was under the Impression that you were already on 19 in this Scenario. And in this context only the autoupgrade.jar seems redundant. Is this correct ?
That’s why I added a note – I have 3 different homes in my env, and I do upgrades every day 🙂
But if your env is 19c-only already, of course you don’t need to download the most recent AU.
Cheers,
Mike
Hi Mike!
Thank you for your update demos!
You mentioned that Bug 30260530 (CONTENT INCLUSION OF 30001331 IN DATABASE RU 19.7.0.0.0) is also fixed in 19.8.0.0.DBRU:200714.
Unfortunately I cannot find a hint in release notes regarding this fix:
Database 19 Release Updates and Revisions Bugs Fixed Lists (Doc ID 2523220.1)
Could you please clarify this issue?
Best regards,
Martin
Hi Martin,
please open an SR for such questions.
I can tell you that the fix they guys did disables the Auto Task window – the SYS_AUTO_STS will be there but it won’t be enabled by default nor will it collect anything automatically.
I updated the blog post:
https://mikedietrichde.com/2020/05/28/do-you-love-unexpected-surprises-sys_auto_sts-in-oracle-19-7-0/
But I can’t tell you why it is not documented in the note.
Cheers,
Mike
hi
i am planning to download the the latest patches for 12cR2 & 19c GRIDPATCHES & DBPATCHES for linux environment. could you please assist with the patch numbers or any direct link from oracle.
See here please:
https://mikedietrichde.com/2017/10/13/download-assistant-for-rus-rurs-bps-psus-patch-sets-and-releases/
Cheers,
Mike
Hi Mike,
We generally use OPatchAuto to apply GI and DBPSU. Do you see any disadvantages with OpatchAuto ?
Thanks,
Saravanan
Clearly “no” disadvantages 🙂
Cheers,
Mike
I wonder why 31281355 DATABASE RELEASE UPDATE 19.8.0.0.0 is after two weeks of release available ONLY for Linux, not other platforms. It breaks our patching plans!
Please log an SR with Oracle Support, inform your sales contact – but I don’t know why this is the case.
Sorry for the inconvenience – I seriously think this is very bad. You WANT to patch – and the patch is not available 🙁 🙁 🙁
Thanks,
Mike
Hi Mike
thanks for your great work.
With Patch 31305339 I’m faceing some problem.
I would like to set up an oracle restart instance on 19.8:
If I install grid with ./gridSetup -applyRU it runs fine.
After unziping ORACLE_HOME and updating OPatch the next step would be
./runinstaller -applyRU
However, no patching of the ORACLE_HOME is done.
The installer comes up directly
Regards
Christian
Hi Christian,
can you check the OUI logs? Maybe something gets skipped here?
This should work regardless of Restart or not.
Thanks,
Mike
Hi Mike,
Yes, an other “admin to stupid error again.”
I removed the ORACLE_HOME, unzipped HOME and OPatch again – and it worked.
Guess something went wrong when unzipping. 🙁
Sorry for this one.
Cheers
Christian
Thanks for the feedback, Christian!
Cheers,
Mike