Oh yes, it is patching time (again). And this time I somehow missed the slot since the quarterly critical patch updates got released right during Oracle Cloud World. Since I didn’t want to stretch the hotel WiFi too much – and since I wouldn’t have had enough time to install and write-up this blog post, I do it now with a week of delay. So as usual every quarter, follow me for patching all my environments with the October 2022 Bundle Patches.

Photo by Olga Guryanova 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 October 2022
It’s always a surprise for me to have a quick look into the quarterly security alert: October 2022 Critical Patch Updates, Security Alerts and Third Party Bulletin. From there I navigate straight (after a little bit of scrolling) to Oracle Database Server, versions 19c, 21c to check the risk matrix.
VERY important is the column Supported Versions Affected. You will spot only Oracle 19c and Oracle 21c there. Now that does not mean that any of these issues may not exist in previous versions as well, for instance in your Oracle 10.2.0.4, Oracle 11.2.0.4 or Oracle 12.1.0.2 databases. It just means that those systems aren’t under any standard support agreement anymore, so they aren’t listed. In reverse, you can almost always assume that something happening in 19c with a very high probability is happening in the previous releases, too.
Do I need to tell you again? It’s time to upgrade to Oracle Database 19c.
Database Patch Bundles
In my last blog post about the quarterly patches in July you may have seen that I didn’t complete the blog post. Several patches were not available, others are not easy to download, even for us. This time I try to create a more complete picture. So let me start with a quick overview on the bundles I’m going to apply. The key document to find the right bundle is either MOS Note: 2888497.1 – Database Critical Patch Update Oct 2022 Patch Availability Document or the Patch Download Assistant.
- Oracle Database 21c
- Database Release Update 21.8.0.0.221018 Patch 34527084 for UNIX
- README
- List of fixes: MOS Note: 2814015.1
- Contents: 94 new fixes on top of 21.7.0
- Database Release Update 21.8.0.0.221018 Patch 34527084 for UNIX
- Oracle Database 19c
- Database Release Update 19.17.0.0.221018 Patch 34419443 for UNIX
- README
- List of fixes: MOS Note: 2523220.1
- Contents: 654 fixes on top of 19.16.0
- OJVM Release Update 19.17.0.0.221018 Patch 34411846 for all platforms
- README
- Contents: 7 fixes on top of OJVM 19.16.0
- Data Pump Bundle Patch 19.17.0 Patch 34734035 for all platforms
- README
- Contents: 75 fixes
- Database Release Update 19.17.0.0.221018 Patch 34419443 for UNIX
- Oracle Database 12.1.0.2
- Since this release is under MDS (Market Driven Support), the bundles are only available to customers with ES contracts. Hence, I will apply it but won’t blog about it anymore. But I will mention if anything unusual happens.
- Oracle Database 11.2.0.4
- Since this release is under MDS (Market Driven Support), the bundles are only available to customers with MDS contracts. Hence, I will apply it but won’t blog about it anymore. But I will mention if anything unusual happens.
Do I need a new OPatch?
And then it is time again for the opatch check. Without even seeing the number, I can tell you that you MUST refresh your opatch since there are some significant performance improvements in the 30 version on all platforms. But let me double check with the READMEs:
- 21.8.0 requires opatch 12.2.0.1.32 or later
- 19.17.0 requires opatch 12.2.0.1.32 or later
The most recent opatch version is already 33. And since I know that there may be some improvements included, I will update opatch in all my homes. The 6880880 link from the readmes takes you directly to the correct download. It may not wonder you, all opatch releases for 12.1 – 21c are identical even though all sail with different display labels on MOS. So it is fairly enough in my case to download it only once.
Hence, action no.1 for all my environments before I will start patching:
- Either wipe out the current
OPatch
directory in each home, then unzip the new OPatch bundles – or use unzip -o option instead
Applying the RU 21.8.0 to my Oracle 21c 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.
Patching my 21c database home to RU 21.8.0 is again pretty straight forward.
- Conflict and space checks
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./ Oracle Interim Patch Installer version 12.2.0.1.33 Copyright (c) 2022, Oracle Corporation. All rights reserved. PREREQ session Oracle Home : /u01/app/oracle/product/21 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/21/oraInst.loc OPatch version : 12.2.0.1.33 OUI version : 12.2.0.9.0 Log file location : /u01/app/oracle/product/21/cfgtoollogs/opatch/opatch2022-11-09_12-12-43PM_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.33 Copyright (c) 2022, Oracle Corporation. All rights reserved. PREREQ session Oracle Home : /u01/app/oracle/product/21 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/21/oraInst.loc OPatch version : 12.2.0.1.33 OUI version : 12.2.0.9.0 Log file location : /u01/app/oracle/product/21/cfgtoollogs/opatch/opatch2022-11-09_12-15-01PM_1.log Invoking prereq "checksystemspace" Prereq "checkSystemSpace" passed. OPatch succeeded.
-
Apply the 21.8.0 Release Update
$ $ORACLE_HOME/OPatch/opatch apply Oracle Interim Patch Installer version 12.2.0.1.33 Copyright (c) 2022, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/oracle/product/21 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/21/oraInst.loc OPatch version : 12.2.0.1.33 OUI version : 12.2.0.9.0 Log file location : /u01/app/oracle/product/21/cfgtoollogs/opatch/opatch2022-11-09_12-16-41PM_1.log Verifying environment and performing prerequisite checks... OPatch continues with these patches: 34527084 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/21') Is the local system ready for patching? [y|n] y User Responded with: Y Backing up files... Applying interim patch '34527084' to OH '/u01/app/oracle/product/21' ApplySession: Optional component(s) [ oracle.network.gsm, 21.0.0.0.0 ] , [ oracle.tfa, 21.0.0.0.0 ] , [ oracle.oraolap.mgmt, 21.0.0.0.0 ] , [ oracle.rdbms.tg4sybs, 21.0.0.0.0 ] , [ oracle.rdbms.tg4msql, 21.0.0.0.0 ] , [ oracle.network.cman, 21.0.0.0.0 ] , [ oracle.rdbms.ic, 21.0.0.0.0 ] , [ oracle.rdbms.tg4db2, 21.0.0.0.0 ] , [ oracle.rdbms.tg4ifmx, 21.0.0.0.0 ] , [ oracle.rdbms.tg4ifxm, 21.0.0.0.0 ] , [ oracle.duma, 21.0.0.0.0 ] , [ oracle.rdbms.tg4tera, 21.0.0.0.0 ] , [ oracle.sdo.companion, 21.0.0.0.0 ] , [ oracle.ons.cclient, 21.0.0.0.0 ] , [ oracle.ons.eons.bwcompat, 21.0.0.0.0 ] , [ oracle.net.cman, 21.0.0.0.0 ] , [ oracle.jdk, 1.8.0.271.00 ] not present in the Oracle Home or a higher version is found. Patching component oracle.rdbms, 21.0.0.0.0... Patching component oracle.network.rsf, 21.0.0.0.0... Patching component oracle.rdbms.rsf, 21.0.0.0.0... Patching component oracle.rdbms.util, 21.0.0.0.0... ... Patching component oracle.ctx, 21.0.0.0.0... Patching component oracle.assistants.server, 21.0.0.0.0... Patching component oracle.precomp.lang, 21.0.0.0.0... Patching component oracle.precomp.common, 21.0.0.0.0... Patching component oracle.jdk, 1.8.0.291.09... Patch 34527084 successfully applied. Sub-set patch [34160444] has become inactive due to the application of a super-set patch [34527084]. Please refer to Doc ID 2161861.1 for any possible further required actions. Log file location: /u01/app/oracle/product/21/cfgtoollogs/opatch/opatch2022-11-09_12-16-41PM_1.log OPatch succeeded.
-
Invoking datapatch
SQL*Plus: Release 21.0.0.0.0 - Production on Wed Nov 9 12:29:22 2022 Version 21.8.0.0.0 Copyright (c) 1982, 2022, Oracle. All rights reserved. Connected to an idle instance. SQL> startup ORACLE instance started. Total System Global Area 1845489680 bytes Fixed Size 9687056 bytes Variable Size 536870912 bytes Database Buffers 1291845632 bytes Redo Buffers 7086080 bytes Database mounted. Database opened. SQL> alter pluggable database all open; Pluggable database altered. SQL> exit Disconnected from Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production Version 21.8.0.0.0 [CDB3] oracle@hol:~/34527084 $ $ORACLE_HOME/OPatch/datapatch -verbose SQL Patching tool version 21.8.0.0.0 Production on Wed Nov 9 12:29:51 2022 Copyright (c) 2012, 2022, Oracle. All rights reserved. Log file for this invocation: /u01/app/oracle/homes/OraDB21Home1/cfgtoollogs/sqlpatch/sqlpatch_30270_2022_11_09_12_29_51/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: 21.8.0.0.0 Release_Update 220930172918: Installed PDB CDB$ROOT: Applied 21.7.0.0.0 Release_Update 220628175910 successfully on 20-JUL-22 05.46.17.557131 PM PDB PDB$SEED: Applied 21.7.0.0.0 Release_Update 220628175910 successfully on 20-JUL-22 05.46.18.586743 PM Adding patches to installation queue and performing prereq checks...done Installation queue: For the following PDBs: CDB$ROOT No interim patches need to be rolled back Patch 34527084 (Database Release Update : 21.8.0.0.221018 (34527084)): Apply from 21.7.0.0.0 Release_Update 220628175910 to 21.8.0.0.0 Release_Update 220930172918 No interim patches need to be applied For the following PDBs: PDB$SEED No interim patches need to be rolled back Patch 34527084 (Database Release Update : 21.8.0.0.221018 (34527084)): Apply from 21.7.0.0.0 Release_Update 220628175910 to 21.8.0.0.0 Release_Update 220930172918 No interim patches need to be applied Installing patches... Patch installation complete. Total patches installed: 2 Validating logfiles...done Patch 34527084 apply (pdb CDB$ROOT): SUCCESS logfile: /u01/app/oracle/homes/OraDB21Home1/cfgtoollogs/sqlpatch/34527084/24956767/34527084_apply_CDB3_CDBROOT_2022Nov09_12_30_03.log (no errors) Patch 34527084 apply (pdb PDB$SEED): SUCCESS logfile: /u01/app/oracle/homes/OraDB21Home1/cfgtoollogs/sqlpatch/34527084/24956767/34527084_apply_CDB3_PDBSEED_2022Nov09_12_30_57.log (no errors) SQL Patching tool complete on Wed Nov 9 12:31:33 2022
-
Enabling new optimizer fixes
Let me clarify beforehand: You don’t have to enable the fixes, especially when you patch. You should definitely enable the fixes when you upgrade, migrate or deploy a new database. But patching is different. And I would recommend careful testing before you do this, going for instance from 19.15.0 to 19.17.0.
SQL*Plus: Release 21.0.0.0.0 - Production on Wed Nov 9 12:33:22 2022 Version 21.8.0.0.0 Copyright (c) 1982, 2022, Oracle. All rights reserved. Connected to: Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production Version 21.8.0.0.0 SQL> set serveroutput on; SQL> execute dbms_optim_bundle.getBugsforBundle; 21.7.0.0.220719DBRU: Bug: 30771009, fix_controls: 30771009 Bug: 29413205, fix_controls: 29413205 Bug: 28044739, fix_controls: 28044739 Bug: 33089096, fix_controls: 31545400 PL/SQL procedure successfully completed. SQL> execute dbms_optim_bundle.enable_optim_fixes('ON','BOTH', 'YES') DBMS_OPTIM command: dbms_optim_bundle.enable_optim_fixes('ON', 'BOTH', 'YES') Bundle's _fix_control setting as per action:ON 31988833:1 32800137:0 32408640:1 29738374:1 33325981:1 32913527:0 32766397:0 31912834:1 33145153:1 31843716:0 32212062:0 31880080:0 32856375:1 33297275:1 33323903:1 32302470:1 32851615:1 32754044:1 30771009:1 29413205:1 28044739:1 31545400:1 Taking current instance CDB3 as base, details on _fix_control setting for CON_ID 1 : 1) Current _fix_control setting for spfile: 31988833:1 32800137:0 32408640:1 29738374:1 33325981:1 32913527:0 32766397:0 31912834:1 33145153:1 31843716:0 32212062:0 31880080:0 32856375:1 33297275:1 33323903:1 32302470:1 32851615:1 32754044:1 30771009:1 29413205:1 28044739:1 31545400:1 2) Final _fix_control setting for spfile considering current_setting_precedence is YES 31988833:1 32800137:0 32408640:1 29738374:1 33325981:1 32913527:0 32766397:0 31912834:1 33145153:1 31843716:0 32212062:0 31880080:0 32856375:1 33297275:1 33323903:1 32302470:1 32851615:1 32754044:1 30771009:1 29413205:1 28044739:1 31545400:1 3) Current _fix_control setting in memory: 31988833:1 32800137:0 32408640:1 29738374:1 33325981:1 32913527:0 32766397:0 31912834:1 33145153:1 31843716:0 32212062:0 31880080:0 32856375:1 33297275:1 33323903:1 32302470:1 32851615:1 32754044:1 30771009:1 29413205:1 28044739:1 31545400:1 4) Final _fix_control setting for memory considering current_setting_precedence is YES 31988833:1 32800137:0 32408640:1 29738374:1 33325981:1 32913527:0 32766397:0 31912834:1 33145153:1 31843716:0 32212062:0 31880080:0 32856375:1 33297275:1 33323903:1 32302470:1 32851615:1 32754044:1 30771009:1 29413205:1 28044739:1 31545400:1 PL/SQL procedure successfully completed.
Now if you check the above output – I created it with 21.8.0 – you may spot immediately that the fixes being displayed are the 21.7.0 ones. We’ve had a similar issue in 19c in the past already. I filed Bug 34782416 – AFTER MOVING TO RU 21.8.0 DBMS_OPTIM_BUNDLE STILL LISTS THE 21.7.0 FIXES for it.
Applying RU and OJVM 19.17.0 October 2022 to my 19c home
Next exercise is my 19c home, the one I am using the most often. And here I have also OJVM installed to reproduce several cases crossing my radar from time to time.
-
Prechecks
Without massaging my oui-patch.xml as in the previous quarter with this workaround, this part is very slow of course. Since the opatch documentation usually is not very informative about improvements, I can’t tell you whether the fixes they’d like to do are in, or not. I’d guess, at least for this part of the patching process, there aren’t any improvements I could see/feel in my environment.To be very frank, this is the most annoying part of the entire patching experience to me. I know why it takes so long. And since the prechecks will get repeated for no obvious reason again later, it is frustrating at best. I know that the opatch team has committed to deliver a solution. And I keep the faith that this will happen soon. Still, I don’t know any ETA date. Let’s keep our fingers crossed.
. -
opatch apply for the 19.17.0 RU
$ $ORACLE_HOME/OPatch/opatch apply Oracle Interim Patch Installer version 12.2.0.1.33 Copyright (c) 2022, 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.33 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2022-11-08_22-07-19PM_1.log Verifying environment and performing prerequisite checks... -------------------------------------------------------------------------------- Start OOP by Prereq process. Launch OOP... Oracle Interim Patch Installer version 12.2.0.1.33 Copyright (c) 2022, 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.33 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2022-11-08_22-12-55PM_1.log Verifying environment and performing prerequisite checks... OPatch continues with these patches: 34419443 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 '34419443' 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.options.olap.api, 19.0.0.0.0 ] , [ oracle.sdo.companion, 19.0.0.0.0 ] , [ oracle.ons.eons.bwcompat, 19.0.0.0.0 ] , [ oracle.rdbms.tg4msql, 19.0.0.0.0 ] , [ oracle.oid.client, 19.0.0.0.0 ] , [ oracle.ons.cclient, 19.0.0.0.0 ] , [ oracle.rdbms.tg4sybs, 19.0.0.0.0 ] , [ oracle.network.cman, 19.0.0.0.0 ] , [ oracle.net.cman, 19.0.0.0.0 ] , [ oracle.options.olap, 19.0.0.0.0 ] , [ oracle.rdbms.tg4tera, 19.0.0.0.0 ] , [ oracle.rdbms.tg4ifmx, 19.0.0.0.0 ] , [ oracle.xdk.companion, 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.ordim.jai, 19.0.0.0.0... Patching component oracle.bali.jewt, 11.1.1.6.0... Patching component oracle.bali.ewt, 11.1.1.6.0... Patching component oracle.help.ohj, 11.1.1.7.0... ... Patching component oracle.rdbms.lbac, 19.0.0.0.0... Patching component oracle.rdbms.install.plugins, 19.0.0.0.0... Patching component oracle.oraolap, 19.0.0.0.0... Patching component oracle.network.listener, 19.0.0.0.0... Patching component oracle.odbc, 19.0.0.0.0... Patching component oracle.ovm, 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 34419443 successfully applied. Sub-set patch [34133642] has become inactive due to the application of a super-set patch [34419443]. Please refer to Doc ID 2161861.1 for any possible further required actions. Log file location: /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2022-11-08_22-12-55PM_1.log OPatch succeeded.
Fine.
-
OJVM apply
Until Oracle Database 19c, the OJVM bundle must be applied separately. From Oracle 21c it is part of the standard RU.
$ $ORACLE_HOME/OPatch/opatch apply Oracle Interim Patch Installer version 12.2.0.1.33 Copyright (c) 2022, 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.33 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2022-11-08_22-27-54PM_1.log Verifying environment and performing prerequisite checks... OPatch continues with these patches: 34411846 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 '34411846' to OH '/u01/app/oracle/product/19' Patching component oracle.javavm.server, 19.0.0.0.0... Patching component oracle.javavm.server.core, 19.0.0.0.0... Patching component oracle.rdbms.dbscripts, 19.0.0.0.0... Patching component oracle.rdbms, 19.0.0.0.0... Patching component oracle.javavm.client, 19.0.0.0.0... Patch 34411846 successfully applied. Sub-set patch [34086870] has become inactive due to the application of a super-set patch [34411846]. Please refer to Doc ID 2161861.1 for any possible further required actions. Log file location: /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2022-11-08_22-27-54PM_1.log OPatch succeeded.
-
Data Pump Bundle Patch apply
I definitely like to include this one as well since it contains about 75 data pump fixes.
$ cd 34734035/ [CDB2] oracle@hol:~/34734035 $ $ORACLE_HOME/OPatch/opatch apply Oracle Interim Patch Installer version 12.2.0.1.33 Copyright (c) 2022, 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.33 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2022-11-08_22-37-28PM_1.log Verifying environment and performing prerequisite checks... OPatch continues with these patches: 34734035 Do you want to proceed? [y|n] y User Responded with: Y All checks passed. Backing up files... Applying interim patch '34734035' to OH '/u01/app/oracle/product/19' Patching component oracle.rdbms, 19.0.0.0.0... Patching component oracle.rdbms.dbscripts, 19.0.0.0.0... Patch 34734035 successfully applied. Log file location: /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2022-11-08_22-37-28PM_1.log OPatch succeeded.
-
datapatch
And then it is time to run datapatch.
$ $ORACLE_HOME/OPatch/datapatch -verbose SQL Patching tool version 19.17.0.0.0 Production on Tue Nov 8 22:55:39 2022 Copyright (c) 2012, 2022, Oracle. All rights reserved. Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_3251_2022_11_08_22_55_39/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: Interim patch 33192694 (OJVM RELEASE UPDATE: 19.13.0.0.211019 (33192694)): Binary registry: Not installed PDB CDB$ROOT: Rolled back successfully on 19-JAN-22 10.14.44.327180 PM PDB PDB$SEED: Rolled back successfully on 19-JAN-22 10.14.44.347566 PM Interim patch 33561310 (OJVM RELEASE UPDATE: 19.14.0.0.220118 (33561310)): Binary registry: Not installed PDB CDB$ROOT: Rolled back successfully on 20-JUL-22 09.17.02.767339 PM PDB PDB$SEED: Rolled back successfully on 20-JUL-22 09.17.02.812896 PM Interim patch 34086870 (OJVM RELEASE UPDATE: 19.16.0.0.220719 (34086870)): Binary registry: Not installed PDB CDB$ROOT: Applied successfully on 20-JUL-22 09.17.02.777722 PM PDB PDB$SEED: Applied successfully on 20-JUL-22 09.17.02.816875 PM Interim patch 34411846 (OJVM RELEASE UPDATE: 19.17.0.0.221018 (34411846)): Binary registry: Installed PDB CDB$ROOT: Not installed PDB PDB$SEED: Not installed Interim patch 34734035 (MERGE ON DATABASE RU 19.17.0.0.0 OF 34650250 34660465 24338134 25143018 26565187): Binary registry: Installed PDB CDB$ROOT: Not installed PDB PDB$SEED: Not installed Current state of release update SQL patches: Binary registry: 19.17.0.0.0 Release_Update 220924224051: Installed PDB CDB$ROOT: Applied 19.16.0.0.0 Release_Update 220703022223 successfully on 20-JUL-22 08.30.37.698095 PM PDB PDB$SEED: Applied 19.16.0.0.0 Release_Update 220703022223 successfully on 20-JUL-22 08.30.38.297082 PM Adding patches to installation queue and performing prereq checks...done Installation queue: For the following PDBs: CDB$ROOT PDB$SEED The following interim patches will be rolled back: 34086870 (OJVM RELEASE UPDATE: 19.16.0.0.220719 (34086870)) Patch 34419443 (Database Release Update : 19.17.0.0.221018 (34419443)): Apply from 19.16.0.0.0 Release_Update 220703022223 to 19.17.0.0.0 Release_Update 220924224051 The following interim patches will be applied: 34411846 (OJVM RELEASE UPDATE: 19.17.0.0.221018 (34411846)) 34734035 (MERGE ON DATABASE RU 19.17.0.0.0 OF 34650250 34660465 24338134 25143018 26565187) Installing patches... Patch installation complete. Total patches installed: 8 Validating logfiles...done Patch 34086870 rollback (pdb CDB$ROOT): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/34086870/24803071/34086870_rollback_CDB2_CDBROOT_2022Nov08_22_56_27.log (no errors) Patch 34419443 apply (pdb CDB$ROOT): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/34419443/24972075/34419443_apply_CDB2_CDBROOT_2022Nov08_22_56_57.log (no errors) Patch 34411846 apply (pdb CDB$ROOT): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/34411846/24917919/34411846_apply_CDB2_CDBROOT_2022Nov08_22_56_57.log (no errors) Patch 34734035 apply (pdb CDB$ROOT): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/34734035/24992341/34734035_apply_CDB2_CDBROOT_2022Nov08_22_57_29.log (no errors) Patch 34086870 rollback (pdb PDB$SEED): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/34086870/24803071/34086870_rollback_CDB2_PDBSEED_2022Nov08_23_01_16.log (no errors) Patch 34419443 apply (pdb PDB$SEED): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/34419443/24972075/34419443_apply_CDB2_PDBSEED_2022Nov08_23_01_16.log (no errors) Patch 34411846 apply (pdb PDB$SEED): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/34411846/24917919/34411846_apply_CDB2_PDBSEED_2022Nov08_23_01_16.log (no errors) Patch 34734035 apply (pdb PDB$SEED): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/34734035/24992341/34734035_apply_CDB2_PDBSEED_2022Nov08_23_01_31.log (no errors) SQL Patching tool complete on Tue Nov 8 23:05:41 2022
- Optimizer fixes
And finally I will enable the new (disabled) optimizer fixes.SQL*Plus: Release 19.0.0.0.0 - Production on Wed Nov 9 08:59:43 2022 Version 19.17.0.0.0 Copyright (c) 1982, 2022, Oracle. All rights reserved. Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.17.0.0.0 SQL> set serverout on SQL> execute dbms_optim_bundle.getBugsforBundle; 19.17.0.0.221018DBRU: Bug: 31582179, fix_controls: 31582179 Bug: 30978868, fix_controls: 30978868 Bug: 33381775, fix_controls: 33381775 Bug: 33906515, fix_controls: 33906515 Bug: 33443834, fix_controls: 33443834 Bug: 33730024, fix_controls: 33730024 Bug: 33649782, fix_controls: 33649782 Bug: 33236729, fix_controls: 33236729 Bug: 34092979, fix_controls: 34092979 Bug: 33987911, fix_controls: 33987911 Bug: 34028486, fix_controls: 34028486 Bug: 32874571, fix_controls: 32874571 Bug: 31304975, fix_controls: 26491973 Bug: 30675651, fix_controls: 30675651 Bug: 10123661, fix_controls: 10123661 Bug: 30887435, fix_controls: 30887435 Bug: 33547527, fix_controls: 30231086, 30195773, 31091402, 33547527 Bug: 30222187, fix_controls: 18101156 Bug: 34428819, fix_controls: 34428819 PL/SQL procedure successfully completed. SQL> execute dbms_optim_bundle.enable_optim_fixes('ON','BOTH', 'YES') DBMS_OPTIM command: dbms_optim_bundle.enable_optim_fixes('ON', 'BOTH', 'YES')
That’s quite a long number of disabled fixes in the 19.17.0 RU.
-
Copying in a new version of AutoUpgrade
Since AutoUpgrade can do database patching now as well (I will show you in the next round of patches in January), I will download and deploy the most recent AutoUpgrade version from MOS Note: 2485457.1 – AutoUpgrade Tool and copy it into my $ORACLE_HOME/rdbms/admin directory overwriting the previous version. The output you should see right now tells you:
$ java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar -version build.version 22.5.221011 build.date 2022/10/11 14:23:59 -0400 build.hash e9428661 build.hash_date 2022/10/11 12:55:45 -0400 build.supported_target_versions 12.2,18,19,21 build.type production
Applying RUs, BPs and PSUs to older releases
Since the previous releases, Oracle Database 11.2.0.4, Oracle Database 12.1.0.2 and Oracle Database 12.2.0.1 are not under Extended Support anymore, I won’t list them here. But I applied the available fixes to my environments as well without any issues.
Further Links and Information
- October 2022 Critical Patch Updates, Security Alerts and Third Party Bulletin
- Risk Matrix Oct 2022 for Oracle Database Server, versions 19c, 21c
- MOS Note: 2888497.1 – Database Critical Patch Update Oct 2022 Patch Availability Document
- Patching most of my environments with the July 2022 Patch Bundles
–Mike
Hi ,
Do we always have to enable_optim_fixes post RU patches ?
We usually apply GRID + RDBMS RU like 19.16 which also handles datapatch using opatchauto.
But we never enable any optim_fixes. Am I missing something ?
Hi Dhiren,
thanks for the hint – I added a “disclaimer” since you don’t have to enable them – and if you do for patching, then you should test carefully please.
Thanks
Mike
Patch 34734035… This is new. It’s not listed in the MOS Note 2888497.1. The Download Assistant also doesn’t list it when I select Database Updates (12.2 and higher). Also not listed in Note 555.1 for recommended one-off patches. If it does include 75 fixes one would think that it’d be higher up on the priority list.
Can we trust that this patch will be bundled into the January 2023 Release Update, for those of us who don’t really have time to dig into 15 levels of Oracle support notes?
Hi Ben,
it is brand new – just became available yesterday night – and we need to wait for the MOS note being updated since we can’t do this unfortunately by ourselves. And please take note that the README is not fully correct about the patch contents. If time allows (but no promise here) I will reveal a bit more details in the next weeks.
Cheers,
Mike
Mike, looks like a copy and past error in 19c section. You have “July” instead of “October”.
Thanks Ed!!!
Cheers,
Mike
Hi Mike, it seems that out of place patching of Oracle Restart (per cloning the GI home) isn´t supported anymore – can you confirm? This still used to work when applying the 19.16 RU, now (19.17) the clone process fails.
Many thanks!
Hi Peter,
can you feed me please with a bit more information such as:
a) which platform
b) where did you find that out-of-place patching isn’t supported for RESTART anymore
c) do you have an SR for the logs
d) which errors did you get
e) which procedure did you use
Thanks
Mike
Hi Mike,
many thanks for your reply, much appreciated! Well, I have to admit that my initial message indeed didn´t contain much information…here are my answers:
a) Linux x86-64
b) let me re-phrase it: could it be that this isn´t supported anymore?
c) yes, I´ve opened an SR. I´ll update this thread once I get feedback.
d) “An error occurred while executing the command ‘crsctl query crs releasepatch'” during the prepare-clone step (crsctl doesn´t support crs type commands in RESTART environments)
e) using the two-step out-of-place procedure, running opatchauto -prepare-clone initially and then opatchauto -switch-clone
Thanks,
Peter
Hi Peter,
can you share the SR number with me please, either via the blog or via email (mike.dietrich —-a—- oracle.com)?
Thanks
Mike
Sure thing, Mike!
3-31199378881
Thanks Peter – I have informed the RAC PM who is looking into it as well.
My guess is that this is an issue with the opatchauto automation – but just my guess.
And as far as we are aware, out-of-place patching for RESTART is still supported.
Cheers
Mike
Awesome, thanks a lot!
Cheers,
Peter
Hi Peter,
directly from the RAC PM, Anil Nair:
This is unfortunately a known (and new) issue. MOS Note:555.1 will be updated with it asap.
34732777 – (G) – 80 – ORACLE RESTART OOP FAILS WITH CLSRSC-180: AN ERROR OCCURRED WHILE EXECUTING THE COMMAND ‘CRSCTL QUERY CRS RELEASEPATCH’
34789953 – (Z) – 11 – JAN2023 CONTENT INCLUSION OF 34732777 IN OCW RU 21.0.0.0.0
34792163 – (Z) – 11 – CONTENT INCLUSION OF 34732777 IN OCW RU 19.18.0.0.0
34779450 – (B) – 35 – BACKPORT OF 34732777 ON OCW RU 19.17.0.0.0 (BLR #10207077)
So a backport is available on top of 19.17.0.
Thanks, and sorry for the inconvenience,
Mike
Thank you so much Mike, I really appreciate that!
However, I´m wondering what exactly I need to apply and where. Patch 34732777 is for 19.17, which is the target home and obviously doesn´t exist yet.
I guess I´m missing something rather obvious…
Cheers,
Peter
Hi Peter,
please see here:
https://support.oracle.com/epmos/faces/PatchDetail?patchId=34732777&requestId=24999242
So you need to unzip your 19.17.0 GI software.
And then please see the README for the above one off – it tells you to unzip this fix into:
/u01/oracle/patches/34732777
My guess is that when you clone the home with:
“opatchauto apply ./34416665 -prepare-clone”
then it will pick up the fix and do the right thing.
So the fix is intentionally for 19.17.0, and not for 19.16.0.
It will be included in the 19.18.0 GI RU as far as I see.
Cheers,
Mike
Mike,
I still don´t get it, sorry. I´ll try to figure out with support how to get this running, as I don´t want to bother you anymore (and maybe this is a misunderstanding – just realized that I never mentioned that I want to patch an existing 19.16 GI home by cloning/switching)
Cheers,
Peter
Hi Peter,
no worries – I try to understand the correct approach as well.
But in my understanding, what you’d do is what I tried to explain below. And my understanding was that you want to clone from a 19.16.0 home to a 19.17.0 home, right?
But please let me know how you finally did it.
Thanks,
Mike
Hi Mike,
yes, I´m trying to clone from a 19.16.0 home to a 19.17.0 home – so we´re still on the same page 😉
What I´m still struggling with is how to tell opatchauto to pick up the fix when cloning. Tried it using the “-phBaseDir” option – but this fails as both 34416665 and 34732777 are system patches. (I studied the README, of course, but didn´t find anything related).
I´ll keep you posted, but it might take a while until I can share something.
Cheers,
Peter
Hi Peter,
in my understanding you need to unzip it into your 19.17.0 home you’re providing as described in the README.
At least this was my understanding when I read the README.
But let me check back with the RAC expert.
Cheers,
Mike
Hi Mike,
I’m also confused on how to apply the fix when cloning db- and grid-homes from 19.16.0 to 19.17.0 using opatchauto apply prepare-clone.
Did you find out how to do this ?
– Thomas
Hi Thomas,
no, and I am not a fan of cloning since you carry around the entire patch history with you. I think it is much better to do this:
https://mikedietrichde.com/2022/05/17/simple-database-installation-with-applyru-and-applyoneoffs/
Cheers
Mike
Hi Mike,
support made me aware of a new document: 2909364.1
The doc includes a workaround using the gridSetup.sh OOP approach – actually your preferred approach, as one can get rid of the patch history.
Still need to test this, but it looks promising.
Thanks again for your help!
Cheers,
Peter
Hi Peter,
let me know if this solves it for you.
Thanks for letting me know – cheers!
Mike
is OJVM released at the same time as the Windows Bundle? Can find Bundle 19.17 but not the related OJVM.
Hi Andrew,
usually it is – but see here:
https://mikedietrichde.com/2020/11/09/why-is-the-19-9-0-release-update-not-available-yet-for-my-platform/
When you check in:
https://support.oracle.com/epmos/faces/DocumentDisplay?id=2888497.1
under section 2.2 (Post Release Patches) you will see that OJVM for win (last entry in the list) is currently set for Nov 14 (actually today).
Cheers, and sorry for the inconvenience,
Mike
Hi Mike,
Database RU 19.15.0, 19.16.0 and 19.17.0 is affected by CVE-2022-42889. Until now there is no Patch available.
RU 19.15
./33806152/files/sqldeveloper/sqldeveloper/lib/ext/liquibase-core.jar
RU 19.16
./34133642/files/sqldeveloper/sqldeveloper/lib/ext/liquibase-core.jar
RU 19.17
./34419443/files/sqldeveloper/sqldeveloper/lib/ext/liquibase-core.jar
OMS and EM 13.5 Client are affected too. I’m sure this is not the end of the story.
Regards
Uwe
Thanks Uwe – but please go through an SR regarding security patches and contents. I can’t comment anything here.
Cheers, and thanks for the information,
Mike
Service Request was opened a week ago
Regards
Uwe
Thanks Uwe!
Cheers
Mike
Uwe I’ve noticed the same, please tell us when you got an answer about this from Oracle.
Regards
Jocke
Hi Jocke,
SR is opened 14 days. No confirmation that Database RU 19.15.0, 19.16.0 and 19.17.0 is affected by CVE-2022-42889. Status: Development Working.
Regards
Uwe
12.2.0.1 is under Extended Support? I’m guessing that’s a copy-paste error. And at this point isn’t 12.1 under Market Driven Support?
Thanks for the hint, Andrew.
Not even a copy/paste error but too many parallel thoughts 🙂
Cheers
Mike
Hi Mike
Doc 2888497.1 mentions patching perl to 5.32-1. Could you advise on patching perl?
Thanks
Hi Laurent,
we always ship versions n-1 – and regarding PERL, I’m not 100% certain whether this is part of the RU. The JDK for sure is, but only n-1 since this is the last version from the code freeze for the RU.
Cheers,
Mike
Thanks Mike
This is why I asked, the Patch appeared in CPU April but isn’t included yet
Hi Laurent,
that is strange – the patch usually contains “n-1”, so the July one contains the April version, the October one contains the July version etc.
Please check with Support since I have no influence or voice regarding the packaging.
Cheers
Mike
https://twitter.com/cgohmannde/status/1616472661370048512
Oh, thanks for the hint!!
Cheers,
Mike
Hi Mike,
I am wondering about the following new remark in the October 2022 – Oracle Database Server Risk Matrix
“Oracle has released client Database fixes for CVEs which we believe are not exploitable in the context of the Database.
The Database server includes a full copy of all the client bits, so any patch that is client applicable, also has to be applied on the server side.”
Do you know, what this remark wants to tell us ?
Regards
Hans-Martin
Hi Hans-Martin,
thanks for spotting this. And my understanding is that – if an issue is labeled as “client”, it applies to the database server installation as well. Of course, it is fixed in the RU. So I don’t read this as “I have to apply another fix” but only as informational that my server installation potentially is affected as well since the software pieces are there.
For further clarification, you may please need to open an SR.
Cheers
Mike
Hi Mike,
thanks for your reply !!
In the meantime I’ve opened an SR and got the following answer:
“What this basically means is that we check internally if the security fixes we are including in the single DB RU for both Client and Server homes has any CPU changes included that can be exploited from the client DB Home.
We do this check so that customers do not need to update all their clients immediately.
It is always advisable to install the RU to the Client and Server homes as there are other fixes that will be present but not doing so will not cause any exploits from a compliance perspective.”
So with this clarification from you and support it means for me, that I don’t have to do additional checks or additional patching, because we apply the RUs to Database and Client Homes.
Regards
Hans-Martin
Thanks Hans-Martin!
Cheers,
Mike
Mike,
Please see MOS note 2912069.1. The Data Pump patch for 19.17 will have to be re-applied if it was downloaded prior to Nov 21.
Thanks,
Arun
Thanks for the heads-up, Arun.
And yes, it missed 3 essential PLB files unfortunately.
Mike
And I will have a blog post about it on Monday, Dec 12.
Thanks!
Mike
Hi Mike,
applying RU 19.17 on 19.5 OH the database queries started to use a huge amount of temp segments causing ORA-1652: unable to extend temp segment by 128 in tablespace TEMP.
the _fix_control workaround didn’t work. Are you aware of any bugs/issues with that? we had the same issues when we tried to apply RU 19.14 but there was explicit reference to fix control.
Thanks a lot
Davide
Hi Davide,
not out of my head – but I hope you did open an SR already.
Please feel free to share the SR number with me since I’d like to learn about potential issues and changes, too.
Cheers,
Mike
Hi Mike,
one question about “one-off” Patches.
We’ve got a 19.10 system with LOTs off applied.
We would build an 19.3 system, apply the 17 Patch on top off it.
But:
Is there a fast way to find out, we if this patches are includes in 19.17?
In my mind, they should be.
It would be quite timeconsuming to check the readmes of 19.17 to figure it out.
Thanks
Christian
Hi Christian,
the general problem with your strategy is that you have over 100 open security issues you won’t fix.
This is why 19.17.0 is the much better strategy going forward instead of adding just the 17 fixes.
Is there a way to check?
We have setup a system allowing such a check.
Do you have an 19.17.0 installation already?
Can you copy/paste the list of fixes you are looking for whether they are included in 19.17.0 or not already?
Then I can show you what to do.
Cheers,
Mike
Hi Mike
Thanks for the fast response and the helping hand.
That’s me and my colleagues LOVE this blog.
We will gather the list of Fixes an deliver them to You.
Cheers
Christian
Thanks Christian!
Cheers
Mike
Hi Mike,
I hope you doing well, I am new to patching I have 19c db environment the third party tools showing vulnerability Oracle database 19 critical path update -junuary 2023 can I apply the latest 19.18.0.0 release update patch for this or we need to cpu patch.
My confusion is in between cpu patch vs release update in 19c
Thank you in advance.
Hi Adnan,
there are no CPU patches anymore since the Oracle 11g days. You need to apply the most recent RU please.
Cheers
Mike