It’s patching day again. Hurray! Or not. I realize that at patching day, the 19c bundles are all missing. So wrote this blog post a bit after the usual release day. In my case this will include Oracle 19.12.0 RU and the July 2021 RU for Oracle 12.2.0.1. Please find the details about Patching all my environments with the July 2021 Patch Bundles below.
Photo by Piron Guillaume on Unsplash
As usual, 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. Please see this blog post about how to apply the RU directly when you provision a new home with OUI.
Security Alert July 2021
You will find the July 2021 Security Alerts for all products here. And as usual, please pay close attention to the Database Server Products Risk Matrix. There are several 7+ issues with Oracle Advanced Networking, Oracle TEXT and XML DB. So it is highly advised to apply this patch bundle.
You may realize that neither 11.2.0.4 nor 18c are mentioned in the risk matrix anymore. As both are out of Premier or Extended Support, there are no regular patch bundles anymore. But the issues noted in the risk matrix may happen in both these releases, and potentially in older releases as well.
In addition, Oracle 19.12.0 delivers again a very high number of fixes.
Database Patch Bundles
You will find the links to the individual patch bundles in MOS Note: 2773670.1 – Critical Patch Update (CPU) Program Jul 2021 Patch Availability Document (PAD). But you can use as well MOS Note: 2118136.2 – Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases to download “your” bundle.
- Oracle Database 19c
- Database Release Update 19.12.0.0.210720 Patch 32904851 for UNIX
- README
- List of fixes: MOS Note: 2523220.1
- Oracle Database 12.2.0.1
- Database Jul2021 Release Update 12.2.0.1.210720 Patch 32916808 for UNIX
- README
- List of fixes: MOS Note: 2245178.1
Do I need a new OPatch?
First check while the download is progressing: Do I need to refresh my OPatch versions?
- 19.12.0 requires opatch 12.2.0.1.25 or later
- 12.2.0.1 July 2021 requires opatch 12.2.0.1.25 or later
In my case I need to update opatch in both homes. The 6880880 link from the readmes takes you directly to the correct download. And it may not wonder you, but both opatch releases are identical even though both sail with different display labels on MOS. So it is fairly enough in my case to download it only once.
Wipe out your current OPatch directory in your homes. Once you unzip the new OPatch bundles. you can proceed.
Applying RU 19.12.0 to my 19c home
I always do something you shouldn’t do. I apply the patch to my existing home. This has to do with the available space in my lab environment. You please provide a new home and apply the patch(es) right away as I describe here.
Applying RU 12.2.0.1 July 2021 to my 12.2.0.1 home
I won’t copy/paste all steps as the output is similar to the above. And I can still use the opatch from my January 2021 patch apply operation.
- Patch conflict and space checks
$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./ Oracle Interim Patch Installer version 12.2.0.1.25 Copyright (c) 2021, 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.25 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-07-26_23-01-11PM_1.log Invoking prereq "checkconflictagainstohwithdetail" Prereq "checkConflictAgainstOHWithDetail" passed. OPatch succeeded.
$ $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -ph ./ Oracle Interim Patch Installer version 12.2.0.1.25 Copyright (c) 2021, 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.25 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-07-26_23-05-55PM_1.log Invoking prereq "checksystemspace" Prereq "checkSystemSpace" passed. OPatch succeeded.
At least in my environment, both checks with the new opatch 25 take an awful long time. I think I waited 3 minutes for each check to return back to the command prompt. And since opatch does the checks again when I call the apply in the next stage, the wait time happens again when it tells me “Verifying environment and performing prerequisite checks…“.
Now I was curious and checked the logfile /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-07-26_23-14-10PM_1.log:
[Jul 26, 2021 11:14:23 PM] [INFO] [OPSR-TIME] Loading cooked inventory [Jul 26, 2021 11:14:23 PM] [INFO] [OPSR-MEMORY] : Loading cooked one offs. Heap memory used 514 (MB) [Jul 26, 2021 11:14:28 PM] [INFO] [OPSR-MEMORY] : Loaded cooked oneoffs. Heap memory used : 348 (MB) [Jul 26, 2021 11:14:28 PM] [INFO] [OPSR-TIME] Cooked inventory loaded successfully [Jul 26, 2021 11:14:28 PM] [INFO] CUP_LOG: Found poh CUP 30557433 is a subset of other poh CUP: 30869156 [Jul 26, 2021 11:14:28 PM] [INFO] CUP_LOG: Found poh CUP 30557433 is a subset of other poh CUP: 31281355 [Jul 26, 2021 11:14:28 PM] [INFO] CUP_LOG: Found poh CUP 32218454 is a subset of other poh CUP: 32545013 [Jul 26, 2021 11:17:43 PM] [INFO] Checking if Oracle Home has components required by patches... [Jul 26, 2021 11:17:43 PM] [INFO] CheckMissingComps: Cached file does not exist or is invalid, re-build prereq result. [Jul 26, 2021 11:17:43 PM] [INFO] Checking conflict among patches... [Jul 26, 2021 11:17:43 PM] [INFO] Running prereq checkConflictAmongPatchesWithDetail [Jul 26, 2021 11:17:44 PM] [INFO] Following patches can be applied: 32904851
No idea what it takes over 3 minutes to check for Oracle components which require patching. My guess is that is has to do with updating the inventory as you can see below.
Just a hint: It is always good to tail -f this logfile because it tells you much more about what opatch is doing than you’ll see on the command prompt.
- opatch apply
$ $ORACLE_HOME/OPatch/opatch apply Oracle Interim Patch Installer version 12.2.0.1.25 Copyright (c) 2021, 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.25 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-07-26_23-10-05PM_1.log Verifying environment and performing prerequisite checks... -------------------------------------------------------------------------------- Start OOP by Prereq process. Launch OOP... Oracle Interim Patch Installer version 12.2.0.1.25 Copyright (c) 2021, 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.25 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-07-26_23-14-10PM_1.log Verifying environment and performing prerequisite checks... OPatch continues with these patches: 32904851 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 '32904851' 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.oid.client, 19.0.0.0.0 ] , [ oracle.network.cman, 19.0.0.0.0 ] , [ oracle.options.olap, 19.0.0.0.0 ] , [ oracle.options.olap.api, 19.0.0.0.0 ] , [ oracle.xdk.companion, 19.0.0.0.0 ] , [ oracle.rdbms.tg4ifmx, 19.0.0.0.0 ] , [ oracle.ons.eons.bwcompat, 19.0.0.0.0 ] , [ oracle.rdbms.tg4tera, 19.0.0.0.0 ] , [ oracle.ons.cclient, 19.0.0.0.0 ] , [ oracle.rdbms.tg4sybs, 19.0.0.0.0 ] , [ oracle.net.cman, 19.0.0.0.0 ] , [ oracle.rdbms.tg4msql, 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.perlint, 5.28.1.0.0... Patching component oracle.rdbms.locator, 19.0.0.0.0... Patching component oracle.rdbms.rsf, 19.0.0.0.0... Patching component oracle.rdbms.util, 19.0.0.0.0... Patching component oracle.rdbms, 19.0.0.0.0... [...] Patching component oracle.mgw.common, 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 32904851 successfully applied. Sub-set patch [32545013] has become inactive due to the application of a super-set patch [32904851]. Please refer to Doc ID 2161861.1 for any possible further required actions. Log file location: /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-07-26_23-14-10PM_1.log OPatch succeeded.
This part of the patch (cut from the logfile) took so long – see the timestamps:
[Jul 26, 2021 11:29:28 PM] [INFO] [OPSR-MEMORY] : Loaded cooked oneoffs. Heap memory used : 959 (MB) [Jul 26, 2021 11:29:28 PM] [INFO] [OPSR-TIME] Cooked inventory loaded successfully [Jul 26, 2021 11:29:28 PM] [INFO] CUP_LOG: Found poh CUP 30557433 is a subset of other poh CUP: 30869156 [Jul 26, 2021 11:29:28 PM] [INFO] CUP_LOG: Found poh CUP 30557433 is a subset of other poh CUP: 31281355 [Jul 26, 2021 11:29:28 PM] [INFO] CUP_LOG: Found poh CUP 32218454 is a subset of other poh CUP: 32545013 [Jul 26, 2021 11:29:28 PM] [INFO] CUP_LOG: Found poh CUP 32218454 is a subset of other poh CUP: 32904851 [Jul 26, 2021 11:29:28 PM] [INFO] CUP_LOG: Found poh CUP 32545013 is a subset of other poh CUP: 32904851 [Jul 26, 2021 11:33:47 PM] [INFO] [OPSR-TIME] Patch 32904851 saved to inventory [Jul 26, 2021 11:33:47 PM] [INFO] ApplySession: Skip patch verification. [Jul 26, 2021 11:33:47 PM] [INFO] [OPSR-TIME] Finished applying patch "32904851" to local system [Jul 26, 2021 11:33:48 PM] [INFO] The following re-links will eventually be skipped because they are duplicates: client_sharedlib, iorion, libasmclntsh19.ohso, itnsping,
- datapatch
$ $ORACLE_HOME/OPatch/datapatch -verbose SQL Patching tool version 19.12.0.0.0 Production on Mon Jul 26 23:38:30 2021 Copyright (c) 2012, 2021, Oracle. All rights reserved. Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_18299_2021_07_26_23_38_30/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.12.0.0.0 Release_Update 210716141810: Installed PDB CDB$ROOT: Applied 19.11.0.0.0 Release_Update 210413004009 successfully on 21-APR-21 02.43.40.035316 PM PDB PDB$SEED: Applied 19.11.0.0.0 Release_Update 210413004009 successfully on 21-APR-21 02.43.41.532161 PM 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 32904851 (Database Release Update : 19.12.0.0.210720 (32904851)): Apply from 19.11.0.0.0 Release_Update 210413004009 to 19.12.0.0.0 Release_Update 210716141810 No interim patches need to be applied Installing patches... Patch installation complete. Total patches installed: 2 Validating logfiles...done Patch 32904851 apply (pdb CDB$ROOT): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/32904851/24343243/32904851_apply_CDB2_CDBROOT_2021Jul26_23_39_36.log (no errors) Patch 32904851 apply (pdb PDB$SEED): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/32904851/24343243/32904851_apply_CDB2_PDBSEED_2021Jul26_23_41_03.log (no errors) SQL Patching tool complete on Mon Jul 26 23:42:00 2021 - Enabling new optimizer fixes
Finally I will enable the new optimizer fixes which are disabled by default with DBMS_OPTIM_BUNDLE.SQL> set serveroutput on; SQL> execute dbms_optim_bundle.getBugsforBundle; 19.12.0.0.210720DBRU: Bug: 31459242, fix_controls: 31459242 Bug: 31082719, fix_controls: 31082719 Bug: 28708585, fix_controls: 28708585 Bug: 31821701, fix_controls: 31821701 Bug: 32107621, fix_controls: 32107621 Bug: 26758837, fix_controls: 26758837 Bug: 31558194, fix_controls: 31558194 Bug: 30781970, fix_controls: 30781970 Bug: 30142527, fix_controls: 30142527 Bug: 31143146, fix_controls: 31143146 Bug: 31961578, fix_controls: 31961578 Bug: 31496840, fix_controls: 31496840 Bug: 22387320, fix_controls: 22387320 PL/SQL procedure successfully completed.The list is much shorter than in 19.11.0.
I will enable them:
SQL> execute dbms_optim_bundle.enable_optim_fixes('ON','BOTH', 'YES')Afterwards I have this entry in my SPFILE:
*._fix_control='29331066:1','28965084:1','28776811:1','28498976:1','28567417:1','28558645:1','29132869:1','29450812:1','29687220:1','29939400:1','30232638:1','30001331:0','29304314:1','29930457:1','30028663:1','28144569:1','28776431:1','27261477:1','31069997:1','31077481:1','28602253:1','29653132:0','29937655:1','30347410:1','30602828:1','30896685:0','29487407:1','30998035:1','30786641:1','31444353:0','30486896:1','28999046:1','30902655:1','30681521:1','29302565:1','30972817:1','30222669:1','31668694:1','31001490:1','30198239:7','30980115:1','30616738:0','31895670:0','19138896:1','31670824:0','9876287:1','30564898:1','32075777:0','30570982:1','32037237:1','30927440:1','30822446:1','24561942:1','31625959:1','31579233:1','29696242:1','31626438:1','30228422:1','17295505:1','29725425:1','30618230:1','30008456:1','30537403:1','30235878:1','30646077:1','29657973:1','29712727:1','20922160:1','30006705:1','29463553:1','30751171:1','31009032:1','30063629:1','30207519:1','31517502:1','30617002:1','30483217:1','30235691:1','30568514:1','28414968:3','32014520:1','30249927:1','31580374:1','29590666:0','29435966:1','28173995:1','29867728:1','30776676:1','26577716:1','30470947:1','30979701:1','30483184:1','31001295:1','31191224:1','31974424:1','29385774:1','28234255:3','31459242:0','31082719:1','28708585:1','31821701:1','32107621:1','26758837:1','31558194:1','30781970:0','30142527:1','31143146:1','31961578:0','31496840:1','22387320:1'#added through dbms_optim_bundle package
- Additional Patches
In addition, you may please consider the patches mentioned on top of 19.12.0 in the MOS Notes I listed here:
Some very important MOS Notes when you upgrade and patch including MOS Note:555.1.
Applying RU 12.2.0.1.210720 to my 12.2.0.1 home
I won’t copy/paste all steps as the output is similar to the above. As I wrote above, I had to exchange my opatch with a newer one.
- Patch conflict check
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
- opatch apply
$ORACLE_HOME/OPatch/opatch apply
- datapatch
$ORACLE_HOME/OPatch/datapatch -verbose
All steps worked fine and flawless.
But there may be a bit more to do in addition.
Further Links and Information
- Security Alert July 2021
- Database Server Products Risk Matrix
- MOS Note: 2773670.1 – Critical Patch Update (CPU) Program Jul 2021 Patch Availability Document (PAD)
- MOS Note: 2118136.2 – Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases
- Opatch 6880880
- Install and apply patches in one pass with -applyRU and -applyOneOffs
- Applying the April 2021 Bundle Patches to my environments
- Some very important MOS Notes when you upgrade and patch including MOS Note:555.1.
–Mike
hi Mike. I don’t know if you can help with this question, but I’m looking into the ANO vulnerability CVE-2021-2351.
I checked a few documents and they mention changes to prevent the use of weaker ciphers, including new sqlnet.ora parameters.
Since we’re not even using network encryption and don’t have plans to do so, do you think applying this patch will make our environment more secure? I asked Oracle Support and the recommendation is to just apply the patch, without addressing that question.
Hopefully you can provide some insight, but if not I understand.
Hi Elisabeth,
below the risk matrix there is a link to a MOS note giving more information:
The July 2021 Critical Patch Update introduces a number of Native Network Encryption changes to deal with vulnerability CVE-2021-2351 and prevent the use of weaker ciphers. Customers should review: “Changes in Native Network Encryption with the July 2021 Critical Patch Update” (Doc ID 2791571.1).
Thanks,
Mike
Done with my Linux patches, but as every quarter, I have to wait for the Windows CPU patches
Details for Patch 32832237 not found. – 19c
Details for Patch 32775037 not found. – 12.2.x
Details for Patch 32774982 not found. – 12.1.x
I am glad I do not run Oracle on Novell NetWare…. LOL
Haha 🙂
Jorge, you are right. And my first Oracle was Oracle 7.0 in university on a Novell Netware 3.11 server if I remember correctly 😀
Mike
jorge – any problems w/the windows patch? I’m getting “Superset Patch 32832237 has subset patch which has overlay patches 32399816” when I run prereq checks….fortunately I snapshotted the home so I simply reverted to the snapshot….
Hi Mike,
I’m just testing RU12 in a RAC-env.
opatchauto-version 12.2.0.1.25 causes OPATCHAUTO-72009 invalid ARU-ID (not supported platform).
The MOS 2783608.1 gives the workaround to falback an older version (12.2.0.1.23/24)
Cheers Peter
Hi Mike/Peter,
I am also facing OPATCHAUTO-72009 invalid ARU-ID (not supported platform) error in RAC 12cR2 and 19c. Oracle support said to follow MOS 2783608.1, the opatchauto says use .25 version. then again i used .25. it is working for some RAC environment. Still failing for some RAC environment.
I know, Jozer – and thanks for sharing the MOS note.
I received several comments from customers about it.
Cheers,
Mike
Hi Mike and Jozer,
regarding updated MOS 2783608.1
Patch 6880880: OPatch 12.2.0.1.27 for DB 19.0.0.0.0 (Aug 2021) fixes this ARU-ID error.
This opatch version is available now. Hope, bug is fixed.
Cheers Peter
In addition to my last comment, there are no older opatch versions available for Patch-ID 6880880. You have to restore it from backup or another system.
I know – this has been done for convenience and usability (sounds sarcastic but is real since people complained about too many opatch versions on MOS).
Did you get a solution for your GI patching topic?
Thanks,
Mike
Hi Mike,
the error occured on a testlab while patching the GRID home as part of opatchauto. When I hit into this error, the log says: Platform is Linux x68-x64 but Patch 32918050 is for [ Generic Platform].
I haven’t seen any reason for this error. Why “Generic Platform” shouldn’t match with “Linux x86-x64” (Testlab is Oracle Linux 7.9) and as a result raising the ARU-ID error?
Interestingly there is no MOS note about this patch available. From readme:
It is a Tomcat Patch for the GRID Home. Interestingly I dont’ found any infos about this patch in MOS.
As solution in my patch testlab:
I’ve tried to reinstall opatch V25, made an Opatch lsinventory and patched directly the GRID home with the -oh option in “opatchauto apply”.
I don’t know which of these actions realy solved the problem.
Cheers Peter
Hi Peter,
i think this is the MOS note you are looking for:
OPatchauto fails with OPATCHAUTO-72009: Invalid ARU id for the platform (Doc ID 2783608.1)
Hope this helps – cheers,
Mike
Hi Mike,
Note 1 on the database server server products risk matrix refers to some new sqlnet.ora parameters. But I didn’t see anything in the patch instructions about setting them. Is it required for the Advanced Networking Option fix to take effect?
Hi Karen,
please see this note below the risk matrix:
The July 2021 Critical Patch Update introduces a number of Native Network Encryption changes to deal with vulnerability CVE-2021-2351 and prevent the use of weaker ciphers. Customers should review: “Changes in Native Network Encryption with the July 2021 Critical Patch Update” (Doc ID 2791571.1).
In the MOS Note you’ll find way more information.
Cheers,
Mike
Hi Mike,
in addition to my comments from yesterday:
as recommended in
“OPatchauto fails with OPATCHAUTO-72009: Invalid ARU id for the platform (Doc ID 2783608.1)”
I try to install the RU on our RAC with opatch 12.2.0.1.24.
But this is not possible. too. While checking patch applicable to GRID home you will hit:
“The OPatch being used has version 12.2.0.1.24 while the following patch(es) require higher versions:
Patch 32904851 requires OPatch version 12.2.0.1.25.
Please download latest OPatch from My Oracle Support.
]
After fixing the cause of failure Run opatchauto resume
]
”
Does anybody already installed RU12 on GI? Currently I see no chance to do this.
I will open a SR
Cheers Peter
Thanks Peter!
Mike
When running datapatch on my 19c database, I got this error:
Error: prereq checks failed!
verify_queryable_inventory returned ORA-20016: Unable to get the lock : get_pending_activity : 1
Prereq check failed, exiting without installing any patches.
I found a Bug 23314180 in MOS which looked like it might apply, so I set the _diag_patch_cap_enabled to false as indicated in the bug and retried datapatch. This time it worked. Has anyone else seen this?
Thanks Tom – you are referring to:
Oracle Support Document 23314180.8 (Bug 23314180 – Queryable Inventory does not release lock with event 18219841 set (ORA-20016 from DBMS_QOPATCH)) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=23314180.8
Description
When event 18219841 is set (to use the GV$ implemenation rather than the
dbms_job implementation), opatch_run_job does not release the lock.
Rediscovery Notes
Queryable inventory could not determine the current opatch status.
The error returned from queryable inventory “verify_queryable_inventory” is “ORA-20016: Unable to get the lock : get_pending_activity :1”
eg:
SQL> select dbms_qopatch.get_pending_activity from dual;
^
ERROR:
ORA-20016: Unable to get the lock : get_pending_activity :1
ORA-06512: at “SYS.DBMS_QOPATCH”, line 1268
Workaround
Set “_diag_patch_cap_enabled” to FALSE
Cheers,
Mike
Hi Mike,
I am thinking the first time about using
execute dbms_optim_bundle.enable_optim_fixes(‘ON’,’BOTH’, ‘YES’)
with 19.12 since you mentioned it here. I am wondering about if those optimizer fixes are 19.12 specific or cumlumative 19.4 – 19.12? If not, how to enable the fixes from previous RUs?
Thanks and best regards,
Robert
Hi Robert,
they are cumulative. You will recognize that the _fix_control gets longer with each release potentially.
Cheers.
Mike
In addition to my last comments:
As mentioned in MOS 2783608.1 but unsuccessfully testing to install the RU12 with opatchauto 12.2.0.1.24. I’ve reinstalled opatch 12.2.0.1.25 in all homes and I tried it again to analyze and apply the patch again with the newest opatchauto 12.2.1.25.0
The error OPATCHAUTO-72009: Invalid ARU-ID disapeared and applying of RU12 was successfull.
I don’t know the cause of former failed opatchauto V25. If you are interested to get the logfile of this failed session I can send it to you.
Cheers Peter
Hi Mike,
Does your test setup uses TDE?
19.11 introduced bug 29528184 (also there on 19.12) which prints the following on the alert log when TDE is used.
DEVPDB(3):ALTER PLUGGABLE DATABASE OPEN detects that an encrypted tablespace has been restored but the master key has not been set for the database, or the database has been flashback’ed prior to first set key of the master key (pdb 3) .
DEVPDB(3): Resetting the master key is required. Please execute ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY command, or select the latest master key from V$ENCRYPTION_KEYS and execute ADMINISTER KEY MANAGEMENT USE KEY command if the SET ENCRYPTION KEY command cannot find and decide the master key to use.
The message is bit misleading. You don’t need a encrypted tablespace to get it. Simply creating a key store is enough to get the above. Happens on on-prem and DBCS VM DB. If no key store (not using TDE) is created then no issue.
Running the ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY as the messages says doesn’t do anything to resolve it either.
After an SR, I was told this is just a warning but at the same time it could be a legitimate message as well. No way to distinguish between the two situations unless you know that you haven’t done a tablespace restore and etc.
Backport for 29528184 is available for 19.11 (not yet on 19.12). I was told this won’t be fixed on 19c but 20.1 (guess this means 21c).
This means years of requesting backport for bug 29528184 if planning to go from one long term support to another long term support (19c -> 23c) if you don’t want to live with the above message.
Do you have other customers who face the same issue?
thanks,
Asanga
Hi Asanga,
thanks for this hint.
I checked bug 29528184 now and can tell you:
– it will be included in 19.13.0 (October 2021 RU)
– the patch is available for 19.12. as well ( One Off Fix
And yes, fixed in 20c meant really fixed in 21c – but the bug says still “fixed in 20c” so the support engineer just read this and communicated it.
Cheers,
Mike
Noticed this since applying the July 2021 19.12 patches. After applying the July patches, it seems that new directories under our fast_recovery_area from RMAN backups are being created as 747 (rwxr–rwx) instead of 750 (rwxr-x—):
drwxr-x—. 2 oracle oinstall 8.0K Jul 23 23:49 2021_07_23
drwxr–rwx. 2 oracle oinstall 8.0K Jul 24 23:54 2021_07_24 <– latest patches applied earlier this day
drwxr–rwx. 2 oracle oinstall 8.0K Jul 25 23:49 2021_07_25
drwxr–rwx. 2 oracle oinstall 8.0K Jul 26 23:53 2021_07_26
umask for Oracle user remains the same, 0022 which creates directories as 755 (rwxr-x-r-x)
Anyone else seen this?
Hi Lance,
I tested this on my OL 7.9 environment, and I can’t reproduce it. Patch applied on 3rd of August – no change in the permissions of FRA subdirectories, e.g.:
drwxr-x—. 2 oracle dba 4096 Aug 3 21:29 2021_08_03
drwxr-x—. 2 oracle dba 70 Aug 4 14:22 2021_08_04
Cheers,
Mike
Thanks Mike. Attempting to track down how this is happening, I’m trying to figure out what RMAN uses to create the new directories. I can’t seem to locate this information anywhere. Do you have any idea how that happens?
Hi Lance,
no, unfortunately I have no idea 🙁
Cheers,
Mike
Hi
We are seeing the same “OPATCHAUTO-72009: Invalid ARU id for the platform.” errors with 12.2.0.1.210720 for 12.2 GI and DB Homes
The initial patch run failed due to apparently file in use errors with crsctl.bin
I confirmed there was no file usage with lsof and tried to resumt the patch but I now get the following
“# /u01/app/grid/12.2.0.1/OPatch/opatchauto resume
OPatchauto session is initiated at Wed Aug 4 12:56:13 2021
Session log file is /u01/app/grid/12.2.0.1/cfgtoollogs/opatchauto/opatchauto2021-08-04_12-56-14PM.log
Resuming existing session with id P3X1
The oracle home /u01/app/grid/12.2.0.1 has a platform Linux x86-64 that is not one of the supported platform for the given patch: [ Generic Platform]
OPATCHAUTO-72009: Invalid ARU id for the platform.
OPATCHAUTO-72009: ARU id value not recognized as a valid id for the platform.
OPATCHAUTO-72009: Check system configuration.
OPatchAuto failed.
“
Hi Paul,
I think this is because of:
OPatchauto fails with OPATCHAUTO-72009: Invalid ARU id for the platform (Doc ID 2783608.1)
https://support.oracle.com/epmos/faces/DocContentDisplay?id=2783608.1
Cheers,
Mike
Thanks Mike. Yeah, I had a couple of others report they also could not reproduce it. Very strange. Not sure what to make of it at this point. I guess I’ll find out Friday if it happens on our production machines or not ¯\_(ツ)_/¯
Why did Oracle not release a Patch set for 18c ( a final version ) in July 2021 ?
Why does the AIX & other OS patch versions come out 2+ weeks later ?
Hi Marty,
because Premier Support for 18c ended before the next patching cycle:
https://mikedietrichde.com/2021/06/10/bug-fixing-support-for-oracle-18c-ends-june-30-2021/
And regarding the later arrival of other bundles, I don’t know the individual reasons but I can only recommend this post here:
https://mikedietrichde.com/2020/11/09/why-is-the-19-9-0-release-update-not-available-yet-for-my-platform/
Cheers,
Mike
I have this error in the alert log when applying 19.12 datapatch
“KUP-04020: found record longer than buffer size supported, 8388608, in /opt/oracle/product/19c/dbhome_1/QOpatch/qopiprep.bat (offset=0)”
However, datapatch reports success for all 4 PDBs and I can query dba_registry_sqlpatch and OPATCH_XML_INV
Do I still need to rebuilt OPATCH_XML_INV (and rerun datapatch) as recommended in Doc ID 1948198.1
Hi Hemant,
you please need to check this via an SR – I can’t answer this since I’m not the owner of the patching process/tool.
Cheers,
Mike
The README for the Database Jul-21 RU Patch 32904851 doesn’t make it clear that the utlrp.sql step may be required for each *PDB* (it just says “Any databases that have invalid objects”, which might mean to be interpreted as querying only the CDBROOT DBA_OBJECTS for status).
I found that my PDBs had more than 300 (threshold) (359 and 360) Invalid Objects as reported in the autorecomp log files under /opt/oracle/cfgtoollogs/sqlpatch/sqlpatch..date..time so I mnually reran utlrp.sql for the 3 PDBs (except for PDB$SEED which was READ ONLY)
Oh yes, you are very right – I didn’t pay attention yet on it.
The README says:
Any databases that have invalid objects after the execution of datapatch should have utlrp.sql run to revalidate those objects.
For example:
cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @utlrp.sql
And of course, this would be a terrible way in a multitenant environment with 200 PDBs.
Of course, it needs to be kicked off by catcon.pl instead.
cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d ”’.”’ utlrp.sql
Cheers,
Mike
Hello Mike,
Greetings, Is it really necessary to execute and enable the new optimizer fixes on all the production databases after apply this July patch.? Is it specific to July 2021 patch or a generic process to all patches.?
Hi Shahid,
it is not a requirement – and it is independent from the July RU.
We recommend it but I see also reasons why you won’t do it without deeper testing.
I do it on my internal systems since we didn’t include the fixes just for fun. But I can see situations where this may have an impact.
Cheers,
Mike
It has fixes for ‘CVE-2021-2351’, which can ‘disable’ non-patched clients when using Native Network Encryption. When clients are not patched, some parts of the database ‘are forced’ to run less-secure.
Patching clients is one of the things people to tend to forget…
I agree – this often will be forgotten quite easily …
Cheers,
Mike
If I need to rollback the patch, do I need to disable the optimizer fix first?
That is a very good question – and I asked the owners of the package because it brings immediately some interesting scenarios to my mind.
Cheers,
Mike
Hi Mike,
As you mentioned “This part of the patch (cut from the logfile) took so long – see the timestamps:” part takes very long time. If you have many RU applied previously, it takes longer. We need enhancement here. Could you notify related team?
Thanks
Hi Numan,
you can notify the team via an SR followed by a bug.
I personally have no access to this team unfortunately.
Cheers,
Mike
Hi Mike,
Does Oracle release CPU July 2021 patch for Windows platform.If yes what is the expected date.
Hi,
please see this blog post:
https://mikedietrichde.com/2020/11/09/why-is-the-19-9-0-release-update-not-available-yet-for-my-platform/
Cheers,
Mike
Hi Mike,
When I query DBA_REGISTRY_SQLPATCH, the OJVM patch always shows as INTERIM under patch_type. Why does it now show as RU like the DB patch?
Thanks,
Arun
Hi Arun,
I seriously have no idea. I guess, somebody decided that calling it “INTERIM” patch is totally incorrect since an interim patch is equal to a one-off patch – so called it RU is much better. But i know that such undocumented name changes puzzle scripts etc 🙁
Cheers,
Mike