My calendar has no error or NLS conversion issue – I was just way to busy the past two months with seminars. But today a colleague asked me whether my 21.4 install reports a 21.3 Build Label in the trace files. And this reminded me that I should now finally apply the patch bundles from October 2021 to our Hands-On Lab environment. So again, another blog post about Patching all my environments with the October 2021 Patch Bundles.
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 2021
You will find the October 2021 Security Alerts for all products here. And as usual, please pay close attention to the Database Server Products Risk Matrix. You will find the usual suspects. And again, my advice would be to apply the patch bundles to your environments if you haven’t done so already.
Risk Matrix – Oracle Database Server – October 2021
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.
Database Patch Bundles
You will find the links to the individual patch bundles in MOS Note:2796575.1 – Critical Patch Update (CPU) Program Oct 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 21c
- Database Release Update 21.4.0.0.211019 Patch 33239276 for UNIX
- README
- List of fixes: MOS Note: 2814015.1
- New fixes: 229
- Database Release Update 21.4.0.0.211019 Patch 33239276 for UNIX
- Oracle Database 19c
- Database Release Update 19.13.0.0.211019 Patch 33192793 for UNIX
- README
- List of fixes: MOS Note: 2523220.1
- New fixes: 714
- OJVM Release Update 19.13.0.0.211019 Patch 33192694 for all platforms
- README
- New fixes: 31
- Database Release Update 19.13.0.0.211019 Patch 33192793 for UNIX
- Oracle Database 12.2.0.1
- Database Oct2021 Release Update 12.2.0.1.211019 Patch 33261817 for UNIX
- README
- List of fixes: MOS Note: 2245178.1
- New fixes: 18
- Database Oct2021 Release Update 12.2.0.1.211019 Patch 33261817 for UNIX
Do I need a new OPatch?
First check while the download is progressing: Do I need to refresh my OPatch versions?
- 21.4.0 requires opatch 12.2.0.1.27 or later
- 19.13.0 requires opatch 12.2.0.1.27 or later
- 12.2.0.1 October 2021 requires opatch 12.2.0.1.27 or later
In my case I need to update opatch in all three homes. Interestingly, while I write this blog post, the most recent opatch available on MOS is not 27anymore but 28. The 6880880 link from the readmes takes you directly to the correct download. And it may not wonder you, all three opatch releases 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.
Wipe out your current OPatch directory in your homes. Once you unzip the new OPatch bundles. you can proceed.
Applying RU 21.4.0 to my 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.
Be very aware: Patching my 21c database home to RU 21.4 is a really simple and VERY fast exercise.
- Conflict and space check
$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./ Oracle Interim Patch Installer version 12.2.0.1.28 Copyright (c) 2021, 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.28 OUI version : 12.2.0.9.0 Log file location : /u01/app/oracle/product/21/cfgtoollogs/opatch/opatch2021-12-15_22-13-21PM_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.28 Copyright (c) 2021, 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.28 OUI version : 12.2.0.9.0 Log file location : /u01/app/oracle/product/21/cfgtoollogs/opatch/opatch2021-12-15_22-15-10PM_1.log Invoking prereq "checksystemspace" Prereq "checkSystemSpace" passed. OPatch succeeded.
This work smoothly and fast.
- opatch apply
$ $ORACLE_HOME/OPatch/opatch apply Oracle Interim Patch Installer version 12.2.0.1.28 Copyright (c) 2021, 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.28 OUI version : 12.2.0.9.0 Log file location : /u01/app/oracle/product/21/cfgtoollogs/opatch/opatch2021-12-15_22-16-11PM_1.log Verifying environment and performing prerequisite checks... OPatch continues with these patches: 33239276 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 '33239276' to OH '/u01/app/oracle/product/21' ApplySession: Optional component(s) [ oracle.tfa, 21.0.0.0.0 ] , [ oracle.network.cman, 21.0.0.0.0 ] , [ oracle.net.cman, 21.0.0.0.0 ] , [ oracle.rdbms.ic, 21.0.0.0.0 ] , [ oracle.duma, 21.0.0.0.0 ] , [ oracle.network.gsm, 21.0.0.0.0 ] , [ oracle.sdo.companion, 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.javavm.server, 21.0.0.0.0... Patching component oracle.javavm.server.core, 21.0.0.0.0... Patching component oracle.ldap.rsf.ic, 21.0.0.0.0... Patching component oracle.rdbms.rsf, 21.0.0.0.0... Patching component oracle.network.rsf, 21.0.0.0.0... Patching component oracle.rdbms, 21.0.0.0.0... Patching component oracle.dbjava.ic, 21.0.0.0.0... Patching component oracle.dbjava.jdbc, 21.0.0.0.0... Patching component oracle.dbjava.ucp, 21.0.0.0.0... Patching component oracle.has.common.cvu, 21.0.0.0.0... Patching component oracle.ldap.rsf, 21.0.0.0.0... Patching component oracle.rdbms.dbscripts, 21.0.0.0.0... Patching component oracle.rdbms.deconfig, 21.0.0.0.0... Patching component oracle.rdbms.rman, 21.0.0.0.0... Patching component oracle.rdbms.rsf.ic, 21.0.0.0.0... Patching component oracle.sqlplus, 21.0.0.0.0... Patching component oracle.sdo.locator, 21.0.0.0.0... Patching component oracle.xdk, 21.0.0.0.0... Patching component oracle.sdo, 21.0.0.0.0... Patching component oracle.xdk.rsf, 21.0.0.0.0... Patching component oracle.assistants.acf, 21.0.0.0.0... Patching component oracle.ctx.rsf, 21.0.0.0.0... Patching component oracle.assistants.server, 21.0.0.0.0... Patching component oracle.xdk.parser.java, 21.0.0.0.0... Patching component oracle.nlsrtl.rsf, 21.0.0.0.0... Patching component oracle.rdbms.util, 21.0.0.0.0... Patching component oracle.ons, 21.0.0.0.0... Patching component oracle.rdbms.dv, 21.0.0.0.0... Patching component oracle.ctx, 21.0.0.0.0... Patching component oracle.ldap.owm, 21.0.0.0.0... Patching component oracle.rdbms.crs, 21.0.0.0.0... Patching component oracle.assistants.deconfig, 21.0.0.0.0... Patching component oracle.precomp.common, 21.0.0.0.0... Patching component oracle.precomp.lang, 21.0.0.0.0... Patching component oracle.jdk, 1.8.0.291.09... Patch 33239276 successfully applied. Log file location: /u01/app/oracle/product/21/cfgtoollogs/opatch/opatch2021-12-15_22-16-11PM_1.log OPatch succeeded.
This went incredibly fast. And be aware that with Oracle Database 21c there is no separate OJVM bundle anymore.
- datapatch
$ $ORACLE_HOME/OPatch/datapatch -verbose SQL Patching tool version 21.4.0.0.0 Production on Wed Dec 15 22:21:07 2021 Copyright (c) 2012, 2021, Oracle. All rights reserved. Log file for this invocation: /u01/app/oracle/homes/OraDB21Home1/cfgtoollogs/sqlpatch/sqlpatch_15670_2021_12_15_22_21_07/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.4.0.0.0 Release_Update 211006052306: Installed PDB CDB$ROOT: No release update patches installed PDB PDB$SEED: No release update patches installed 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 33239276 (Database Release Update : 21.4.0.0.211019 (33239276)): Apply from 21.1.0.0.0 Feature Release to 21.4.0.0.0 Release_Update 211006052306 No interim patches need to be applied Installing patches... Patch installation complete. Total patches installed: 2 Validating logfiles...done Patch 33239276 apply (pdb CDB$ROOT): SUCCESS logfile: /u01/app/oracle/homes/OraDB21Home1/cfgtoollogs/sqlpatch/33239276/24468932/33239276_apply_CDB3_CDBROOT_2021Dec15_22_21_16.log (no errors) Patch 33239276 apply (pdb PDB$SEED): SUCCESS logfile: /u01/app/oracle/homes/OraDB21Home1/cfgtoollogs/sqlpatch/33239276/24468932/33239276_apply_CDB3_PDBSEED_2021Dec15_22_21_59.log (no errors) SQL Patching tool complete on Wed Dec 15 22:22:36 2021Don’t forget to startup the database and all PDBs at first.
- Enabling new optimizer fixes
SQL*Plus: Release 21.0.0.0.0 - Production on Wed Dec 15 22:25:32 2021 Version 21.4.0.0.0 Copyright (c) 1982, 2021, Oracle. All rights reserved. Connected to: Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production Version 21.4.0.0.0 SQL> set serveroutput on; SQL> execute dbms_optim_bundle.getBugsforBundle; 21.4.0.0.211019DBRU: Bug: 31988833, fix_controls: 31988833 Bug: 32800137, fix_controls: 32800137 Bug: 32408640, fix_controls: 32408640 Bug: 32312412, fix_controls: 29738374 Bug: 33325981, fix_controls: 33325981 PL/SQL procedure successfully completed. 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 Taking current instance CDB3 as base, details on _fix_control setting for CON_ID 1 : 1) Current _fix_control setting for spfile: None 2) Final _fix_control setting for spfile considering current_setting_precedence is YES 31988833:1 32800137:0 32408640:1 29738374:1 33325981:1 3) Current _fix_control setting in memory: 31988833:0 32800137:0 32408640:0 29738374:0 33325981:0 4) Final _fix_control setting for memory considering current_setting_precedence is YES 31988833:0 32800137:0 32408640:0 29738374:0 33325981:0 WARNING: final _fix_control setting for memory is not same as final _fix_control setting for spfile. Please look at point 2 and 4 above to see the differences. PL/SQL procedure successfully completed.Yes, I do this since I see no point of having new optimizer fixes but keep them disabled. Of course, the situation may be different in your environment.
Applying RU 19.13.0 to my 19c home
And here the patch apply process is different compared to 21.4.0. It takes significantly longer. Of course there are several reasons for it. 19.13.0 contains several hundred binary fixes. And my inventory has a loooong history since I applied almost all bundles, one after another, for 19c before. Hence, reading the inventory takes much longer. It takes so much longer that it is almost disturbing. While a simple space check in the 21c home takes 15 seconds, the same check with the same opatch takes 10x as long in my 19c home. Quite disturbing.
- Conflict and space checks
$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./ Oracle Interim Patch Installer version 12.2.0.1.28 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.28 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-12-15_22-41-12PM_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.28 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.28 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-12-15_22-45-35PM_1.log Invoking prereq "checksystemspace" Prereq "checkSystemSpace" passed. OPatch succeeded.
Just a quick comparison with the logs showing what happens in 21c versus 19c when opatch seems to go into a nap-mode.
This is the 19c log – see the time stamps – it seems to sleep for 3 minutes:
[Dec 15, 2021 10:41:23 PM] [INFO] CUP_LOG: Found poh CUP 32545013 is a subset of other poh CUP: 32904851 [Dec 15, 2021 10:44:16 PM] [INFO] Running prereq checkConflictAgainstOHWithDetail [Dec 15, 2021 10:44:16 PM] [INFO] CUP_LOG: Found pi CUP 33192793 is a superset of poh CUP: 32904851 [Dec 15, 2021 10:44:17 PM] [INFO] Following patches can be applied: 33192793
And this is the 21c log in comparison:
[Dec 15, 2021 10:13:21 PM] [INFO] [OPSR-TIME] Raw inventory loaded successfully [Dec 15, 2021 10:13:22 PM] [INFO] Running prereq checkConflictAgainstOHWithDetail [Dec 15, 2021 10:13:22 PM] [INFO] [OPSR-TIME] Loading cooked inventory [Dec 15, 2021 10:13:22 PM] [INFO] [OPSR-MEMORY] : Loading cooked one offs. Heap memory used 42 (MB) [Dec 15, 2021 10:13:22 PM] [INFO] [OPSR-MEMORY] : Loaded cooked oneoffs. Heap memory used : 42 (MB) [Dec 15, 2021 10:13:22 PM] [INFO] [OPSR-TIME] Cooked inventory loaded successfully [Dec 15, 2021 10:13:22 PM] [INFO] Following patches can be applied: 33239276 [Dec 15, 2021 10:13:22 PM] [INFO] Following patches are not required: [Dec 15, 2021 10:13:22 PM] [INFO] Following patches are auto rollbackable: [Dec 15, 2021 10:13:22 PM] [INFO] Finished checking prereq checkConflictAgainstOHWithDetail [Dec 15, 2021 10:13:22 PM] [INFO] Prereq "checkConflictAgainstOHWithDetail" passed.
Quite obscure, isn’t it?
- opatch apply
$ $ORACLE_HOME/OPatch/opatch apply Oracle Interim Patch Installer version 12.2.0.1.28 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.28 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-12-15_22-54-10PM_1.log Verifying environment and performing prerequisite checks... y y -------------------------------------------------------------------------------- Start OOP by Prereq process. Launch OOP... Oracle Interim Patch Installer version 12.2.0.1.28 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.28 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-12-15_22-58-22PM_1.log Verifying environment and performing prerequisite checks... OPatch continues with these patches: 33192793 Do you want to proceed? [y|n] 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 '33192793' 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.ons.eons.bwcompat, 19.0.0.0.0 ] , [ oracle.oid.client, 19.0.0.0.0 ] , [ oracle.rdbms.tg4ifmx, 19.0.0.0.0 ] , [ oracle.options.olap.api, 19.0.0.0.0 ] , [ oracle.net.cman, 19.0.0.0.0 ] , [ oracle.options.olap, 19.0.0.0.0 ] , [ oracle.rdbms.tg4sybs, 19.0.0.0.0 ] , [ oracle.rdbms.tg4tera, 19.0.0.0.0 ] , [ oracle.ons.cclient, 19.0.0.0.0 ] , [ oracle.rdbms.tg4msql, 19.0.0.0.0 ] , [ oracle.xdk.companion, 19.0.0.0.0 ] , [ oracle.network.cman, 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.perlint.expat, 2.0.1.0.4... 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.assistants.acf, 19.0.0.0.0... Patching component oracle.assistants.deconfig, 19.0.0.0.0... Patching component oracle.assistants.server, 19.0.0.0.0... Patching component oracle.buildtools.rsf, 19.0.0.0.0... Patching component oracle.ctx, 19.0.0.0.0... Patching component oracle.dbjava.ic, 19.0.0.0.0... Patching component oracle.dbjava.jdbc, 19.0.0.0.0... Patching component oracle.dbjava.ucp, 19.0.0.0.0... Patching component oracle.duma, 19.0.0.0.0... Patching component oracle.javavm.client, 19.0.0.0.0... Patching component oracle.ldap.owm, 19.0.0.0.0... Patching component oracle.ldap.rsf, 19.0.0.0.0... Patching component oracle.marvel, 19.0.0.0.0... Patching component oracle.network.rsf, 19.0.0.0.0... Patching component oracle.odbc.ic, 19.0.0.0.0... Patching component oracle.oracore.rsf, 19.0.0.0.0... Patching component oracle.precomp.common.core, 19.0.0.0.0... Patching component oracle.rdbms.dbscripts, 19.0.0.0.0... Patching component oracle.rdbms.deconfig, 19.0.0.0.0... Patching component oracle.rdbms.oci, 19.0.0.0.0... Patching component oracle.rhp.db, 19.0.0.0.0... Patching component oracle.sdo, 19.0.0.0.0... Patching component oracle.sdo.locator.jrf, 19.0.0.0.0... Patching component oracle.sqlplus, 19.0.0.0.0... Patching component oracle.sqlplus.ic, 19.0.0.0.0... Patching component oracle.wwg.plsql, 19.0.0.0.0... Patching component oracle.rdbms.crs, 19.0.0.0.0... Patching component oracle.network.listener, 19.0.0.0.0... Patching component oracle.network.client, 19.0.0.0.0... Patching component oracle.ctx.rsf, 19.0.0.0.0... Patching component oracle.rdbms.scheduler, 19.0.0.0.0... Patching component oracle.rdbms.hs_common, 19.0.0.0.0... Patching component oracle.xdk, 19.0.0.0.0... Patching component oracle.ons.ic, 19.0.0.0.0... Patching component oracle.xdk.xquery, 19.0.0.0.0... Patching component oracle.rdbms.drdaas, 19.0.0.0.0... Patching component oracle.javavm.server, 19.0.0.0.0... Patching component oracle.ovm, 19.0.0.0.0... Patching component oracle.dbdev, 19.0.0.0.0... Patching component oracle.rdbms.dv, 19.0.0.0.0... Patching component oracle.precomp.rsf, 19.0.0.0.0... Patching component oracle.ctx.atg, 19.0.0.0.0... Patching component oracle.ldap.security.osdt, 19.0.0.0.0... Patching component oracle.ldap.client, 19.0.0.0.0... Patching component oracle.ldap.rsf.ic, 19.0.0.0.0... Patching component oracle.xdk.parser.java, 19.0.0.0.0... Patching component oracle.oraolap.dbscripts, 19.0.0.0.0... Patching component oracle.odbc, 19.0.0.0.0... Patching component oracle.sdo.locator, 19.0.0.0.0... Patching component oracle.dbtoolslistener, 19.0.0.0.0... Patching component oracle.ons, 19.0.0.0.0... Patching component oracle.oraolap.api, 19.0.0.0.0... Patching component oracle.rdbms.hsodbc, 19.0.0.0.0... Patching component oracle.rdbms.rman, 19.0.0.0.0... Patching component oracle.rdbms.install.common, 19.0.0.0.0... Patching component oracle.nlsrtl.rsf, 19.0.0.0.0... Patching component oracle.rdbms.install.plugins, 19.0.0.0.0... Patching component oracle.rdbms.lbac, 19.0.0.0.0... Patching component oracle.mgw.common, 19.0.0.0.0... Patching component oracle.xdk.rsf, 19.0.0.0.0... Patching component oracle.oraolap, 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 33192793 successfully applied. Sub-set patch [32904851] has become inactive due to the application of a super-set patch [33192793]. Please refer to Doc ID 2161861.1 for any possible further required actions. Log file location: /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-12-15_22-58-22PM_1.log OPatch succeeded.
And again, the precheck embedded into the apply took an awful long 4 minutes.
- datapatch
$ $ORACLE_HOME/OPatch/datapatch -verbose SQL Patching tool version 19.13.0.0.0 Production on Wed Dec 15 23:29:47 2021 Copyright (c) 2012, 2021, Oracle. All rights reserved. Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_25729_2021_12_15_23_29_47/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.13.0.0.0 Release_Update 211004165050: Installed PDB CDB$ROOT: Applied 19.12.0.0.0 Release_Update 210716141810 successfully on 09-AUG-21 04.06.00.130815 PM PDB PDB$SEED: Applied 19.12.0.0.0 Release_Update 210716141810 successfully on 09-AUG-21 04.06.00.343720 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 33192793 (Database Release Update : 19.13.0.0.211019 (33192793)): Apply from 19.12.0.0.0 Release_Update 210716141810 to 19.13.0.0.0 Release_Update 211004165050 No interim patches need to be applied Installing patches... Patch installation complete. Total patches installed: 2 Validating logfiles...done Patch 33192793 apply (pdb CDB$ROOT): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/33192793/24462514/33192793_apply_CDB2_CDBROOT_2021Dec15_23_30_21.log (no errors) Patch 33192793 apply (pdb PDB$SEED): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/33192793/24462514/33192793_apply_CDB2_PDBSEED_2021Dec15_23_31_29.log (no errors) SQL Patching tool complete on Wed Dec 15 23:32:52 2021Smooth and quick.
- Enabling optimizer fixes in my database
SQL*Plus: Release 19.0.0.0.0 - Production on Wed Dec 15 23:34:26 2021 Version 19.13.0.0.0 Copyright (c) 1982, 2021, Oracle. All rights reserved. Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.13.0.0.0 SQL> set serverout on SQL> execute dbms_optim_bundle.getBugsforBundle; 19.13.0.0.211019DBRU: Bug: 25979242, fix_controls: 25979242 Bug: 32578113, fix_controls: 32578113 Bug: 32205825, fix_controls: 32205825 Bug: 32408640, fix_controls: 32408640 Bug: 31988833, fix_controls: 31988833 Bug: 32800137, fix_controls: 32800137 Bug: 31360214, fix_controls: 31360214 Bug: 32913527, fix_controls: 32913527 Bug: 32312412, fix_controls: 29738374 Bug: 33325981, fix_controls: 33325981 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 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 30652595:1 25979242:1 32578113:1 32205825:1 32408640:1 31988833:1 32800137:0 31360214:1 32913527:0 29738374:1 33325981:1 Taking current instance CDB2 as base, details on _fix_control setting for CON_ID 1 : 1) Current _fix_control setting for spfile: 28567417:0 28558645:0 29132869:0 30028663:0 31077481:0 29487407:0 31444353:0 29302565:0 31625959:0 31579233:0 30207519:0 30979701:0 28234255:0 29450812:0 30001331:0 29653132:0 30602828:0 30786641:0 30486896:0 30972817:0 19138896:0 30927440:0 30646077:0 29712727:0 30617002:0 30568514:0 30249927:0 29590666:0 30483184:0 31961578:0 31496840:0 22387320:0 30681521:0 9876287:0 30822446:0 24561942:0 31626438:0 30751171:0 31009032:0 28414968:0 30470947:0 31821701:0 32107621:0 28498976:0 30232638:0 29937655:0 30896685:0 31668694:0 31001490:0 30980115:0 30616738:0 30483217:0 26577716:0 28965084:0 28144569:0 28776431:0 30222669:0 30570982:0 29696242:0 30228422:0 17295505:0 30618230:0 29657973:0 30063629:0 28173995:0 31001295:0 31974424:0 31459242:0 29304314:0 27261477:0 30902655:0 30198239:0 32037237:0 29725425:0 30008456:0 30235878:0 30235691:0 29435966:0 29867728:0 30776676:0 28708585:0 30142527:0 31143146:0 29939400:0 31069997:0 32075777:0 30537403:0 20922160:0 30006705:0 29463553:0 31517502:0 29385774:0 31082719:0 26758837:0 30781970:0 29331066:0 28776811:0 29687220:0 29930457:0 28602253:0 30347410:0 30998035:0 28999046:0 31895670:0 31670824:0 30564898:0 32014520:0 31580374:0 31191224:0 31558194:0 2) Final _fix_control setting for spfile considering current_setting_precedence is YES 29331066:0 28965084:0 28776811:0 28498976:0 28567417:0 28558645:0 29132869:0 29450812:0 29687220:0 29939400:0 30232638:0 30001331:0 29304314:0 29930457:0 30028663:0 28144569:0 28776431:0 27261477:0 31069997:0 31077481:0 28602253:0 29653132:0 29937655:0 30347410:0 30602828:0 30896685:0 29487407:0 30998035:0 30786641:0 31444353:0 30486896:0 28999046:0 30902655:0 30681521:0 29302565:0 30972817:0 30222669:0 31668694:0 31001490:0 30198239:0 30980115:0 30616738:0 31895670:0 19138896:0 31670824:0 9876287:0 30564898:0 32075777:0 30570982:0 32037237:0 30927440:0 30822446:0 24561942:0 31625959:0 31579233:0 29696242:0 31626438:0 30228422:0 17295505:0 29725425:0 30618230:0 30008456:0 30537403:0 30235878:0 30646077:0 29657973:0 29712727:0 20922160:0 30006705:0 29463553:0 30751171:0 31009032:0 30063629:0 30207519:0 31517502:0 30617002:0 30483217:0 30235691:0 30568514:0 28414968:0 32014520:0 30249927:0 31580374:0 29590666:0 29435966:0 28173995:0 29867728:0 30776676:0 26577716:0 30470947:0 30979701:0 30483184:0 31001295:0 31191224:0 31974424:0 29385774:0 28234255:0 31459242:0 31082719:0 28708585:0 31821701:0 32107621:0 26758837:0 31558194:0 30781970:0 30142527:0 31143146:0 31961578:0 31496840:0 22387320:0 30652595:1 25979242:1 32578113:1 32205825:1 32408640:1 31988833:1 32800137:0 31360214:1 32913527:0 29738374:1 33325981:1 3) Current _fix_control setting in memory: 29331066:0 28965084:0 28776811:0 28498976:0 28567417:0 28558645:0 29132869:0 29450812:0 29687220:0 29939400:0 30232638:0 30001331:0 29304314:0 29930457:0 30028663:0 28144569:0 28776431:0 27261477:0 31069997:0 31077481:0 28602253:0 29653132:0 29937655:0 30347410:0 30602828:0 30896685:0 29487407:0 30998035:0 30786641:0 31444353:0 30486896:0 28999046:0 30902655:0 30681521:0 29302565:0 30972817:0 30222669:0 31668694:0 31001490:0 30198239:0 30980115:0 30616738:0 31895670:0 19138896:0 31670824:0 9876287:0 30564898:0 32075777:0 30570982:0 32037237:0 30927440:0 30822446:0 24561942:0 31625959:0 31579233:0 29696242:0 31626438:0 30228422:0 17295505:0 29725425:0 30618230:0 30008456:0 30537403:0 30235878:0 30646077:0 29657973:0 29712727:0 20922160:0 30006705:0 29463553:0 30751171:0 31009032:0 30063629:0 30207519:0 31517502:0 30617002:0 30483217:0 30235691:0 30568514:0 28414968:0 32014520:0 30249927:0 31580374:0 29590666:0 29435966:0 28173995:0 29867728:0 30776676:0 26577716:0 30470947:0 30979701:0 30483184:0 31001295:0 31191224:0 31974424:0 29385774:0 28234255:0 31459242:0 31082719:0 28708585:0 31821701:0 32107621:0 26758837:0 31558194:0 30781970:0 30142527:0 31143146:0 31961578:0 31496840:0 22387320:0 30652595:0 25979242:0 32578113:0 32205825:0 32408640:0 31988833:0 32800137:0 31360214:0 32913527:0 29738374:0 33325981:0 4) Final _fix_control setting for memory considering current_setting_precedence is YES 29331066:0 28965084:0 28776811:0 28498976:0 28567417:0 28558645:0 29132869:0 29450812:0 29687220:0 29939400:0 30232638:0 30001331:0 29304314:0 29930457:0 30028663:0 28144569:0 28776431:0 27261477:0 31069997:0 31077481:0 28602253:0 29653132:0 29937655:0 30347410:0 30602828:0 30896685:0 29487407:0 30998035:0 30786641:0 31444353:0 30486896:0 28999046:0 30902655:0 30681521:0 29302565:0 30972817:0 30222669:0 31668694:0 31001490:0 30198239:0 30980115:0 30616738:0 31895670:0 19138896:0 31670824:0 9876287:0 30564898:0 32075777:0 30570982:0 32037237:0 30927440:0 30822446:0 24561942:0 31625959:0 31579233:0 29696242:0 31626438:0 30228422:0 17295505:0 29725425:0 30618230:0 30008456:0 30537403:0 30235878:0 30646077:0 29657973:0 29712727:0 20922160:0 30006705:0 29463553:0 30751171:0 31009032:0 30063629:0 30207519:0 31517502:0 30617002:0 30483217:0 30235691:0 30568514:0 28414968:0 32014520:0 30249927:0 31580374:0 29590666:0 29435966:0 28173995:0 29867728:0 30776676:0 26577716:0 30470947:0 30979701:0 30483184:0 31001295:0 31191224:0 31974424:0 29385774:0 28234255:0 31459242:0 31082719:0 28708585:0 31821701:0 32107621:0 26758837:0 31558194:0 30781970:0 30142527:0 31143146:0 31961578:0 31496840:0 22387320:0 30652595:0 25979242:0 32578113:0 32205825:0 32408640:0 31988833:0 32800137:0 31360214:0 32913527:0 29738374:0 33325981:0 WARNING: final _fix_control setting for memory is not same as final _fix_control setting for spfile. Please look at point 2 and 4 above to see the differences. PL/SQL procedure successfully completed.Not this many fixes in 19.13.0 compared to some previous RUs.
- OJVM patch
Since I have the JavaVM in my 19c environment, I add the OJVM RU from October 2021 to the home, too.$ $ORACLE_HOME/OPatch/opatch apply Oracle Interim Patch Installer version 12.2.0.1.28 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.28 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-12-15_23-38-00PM_1.log Verifying environment and performing prerequisite checks... -------------------------------------------------------------------------------- Start OOP by Prereq process. Launch OOP... Oracle Interim Patch Installer version 12.2.0.1.28 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.28 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-12-15_23-42-08PM_1.log Verifying environment and performing prerequisite checks... OPatch continues with these patches: 33192694 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 '33192694' 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 33192694 successfully applied. Log file location: /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-12-15_23-42-08PM_1.log OPatch succeeded. [CDB2] oracle@hol:/u01/app/oracle/product/19/33192694 $ $ORACLE_HOME/OPatch/datapatch -verbose SQL Patching tool version 19.13.0.0.0 Production on Thu Dec 16 00:09:28 2021 Copyright (c) 2012, 2021, Oracle. All rights reserved. Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_30410_2021_12_16_00_09_28/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: Installed PDB CDB$ROOT: Not installed PDB PDB$SEED: Not installed Current state of release update SQL patches: Binary registry: 19.13.0.0.0 Release_Update 211004165050: Installed PDB CDB$ROOT: Applied 19.13.0.0.0 Release_Update 211004165050 successfully on 15-DEC-21 11.32.48.559776 PM PDB PDB$SEED: Applied 19.13.0.0.0 Release_Update 211004165050 successfully on 15-DEC-21 11.32.49.191356 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 No release update patches need to be installed The following interim patches will be applied: 33192694 (OJVM RELEASE UPDATE: 19.13.0.0.211019 (33192694)) Installing patches... Patch installation complete. Total patches installed: 2 Validating logfiles...done Patch 33192694 apply (pdb CDB$ROOT): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/33192694/24421575/33192694_apply_CDB2_CDBROOT_2021Dec16_00_09_49.log (no errors) Patch 33192694 apply (pdb PDB$SEED): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/33192694/24421575/33192694_apply_CDB2_PDBSEED_2021Dec16_00_10_22.log (no errors) SQL Patching tool complete on Thu Dec 16 00:10:23 2021In between opatch and datapatch of course I started my database and all PDBs again.
Applying RU 12.2.0.1.211019 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
And of course I enable the disabled optimizer fixes in my 12.2.0.1 databases, too.
All steps worked fine and flawless.
Your patch is not available?
In case you miss the patch bundle for your release and platform, please read this blog post.
Further Links and Information
- October 2021 Security Alerts for all products
- Database Server Products Risk Matrix October 2021
- MOS Note:2796575.1 – Critical Patch Update (CPU) Program Oct 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
- Why is this Release Update not available for my environment yet?
- Patching all my environments with the July 2021 Patch Bundles
–Mike
Hey Mike,
Could you please shed some light on this fantastic info “And be aware that with Oracle Database 21c there is no separate OJVM bundle anymore” ?
Cheers, Nariman
I will 🙂
In brief, it is part of the regular RU. Things have changed to allow fully rolling patching now.
When time allows, I will blog a bit more about it.
Cheers,
Mike
Hi, Mike!
I had an issue with 19.13 on Solaris SPARC. Neither -applyRU nor opatchauto didn’t work for GI / DB homes. There were no any errors during setup*.sh with applyRU, it said that patch installed successfuly , but RU didn’t installed. #opatchauto said that patch wasn’t suitable or smth like that. The solution was not to update opatch (unzip to directory), but i had to delete all files from $OH/OPatch directory and unzip fresh Opatch .28 to it. After that opatchauto worked
And i dint caught such problem on Linux 🙂
Hi Sergey,
thanks for the feedback – and since I don’t test on Solaris unfortunately, I haven’t seen this.
Did you open an SR or did you find the workaround by yourself?
In case you opened an SR, would you mind to share the SR number with me so I can add this misbehavior to the bug I have opened anyway for the -applyRU problem when you pass on the OJVM in addition (then it will fail as well).
Thanks,
Mike
I setup a new V12.1.0.2 home and patched it as usual (in AIX)
But I see issue (I believe):
set serverout on
execute dbms_optim_bundle.getBugsforBundle;
12.1.0.2.210720DBBP: <<<<<<< Shouldn't this list something like 12.1.0.2.211020DBBP for October??
Bug: 31444353, fix_controls: 31444353
PL/SQL procedure successfully completed.
+++
(partial OPatch lsinventory listing)
Even though this is installed…
Patch 33114885 : applied on Thu Nov 04 09:42:56 GMT+10:00 2021
Unique Patch ID: 24464895
Patch description: "Database Bundle Patch : 12.1.0.2.211019 (33114885)"
Created on 18 Oct 2021, 08:54:35 hrs PST8PDT
Sub-patch 32768230; "Database Bundle Patch : 12.1.0.2.210720 (32768230)"
Sub-patch 32328632; "Database Bundle Patch : 12.1.0.2.210420 (32328632)"
Sub-patch 31965033; "Database Bundle Patch : 12.1.0.2.210119 (31965033)"
…..
Was there no upgrade to the getBugsforBundle (12.1.0.2.211019 Bundle Patch (OCT2021-BP))
I also note that the OCW patch looks wrong as well.
Patch 32758932 : applied on Thu Nov 04 09:54:13 GMT+10:00 2021
Unique Patch ID: 24362670
Patch description: "OCW PATCH SET UPDATE 12.1.0.2.210720 (32758932)" <<< Shouldn't this refer to October too?
Created on 2 Aug 2021, 13:58:41 hrs UTC
Bugs fixed:
21339083, 24831217, 18589889, 20768643, 19061429, 26512962, 26147987
…….
Hi VSmith,
actually I have a lot of doubts that DBMS_OPTIM_BUNDLE was implemented fully and correctly with every BP on 12.1.0.2. “Officially”, it should – but please browse the blog for DBMS_OPTIM_BUNDLE, and you will find all sorts of strange misbehavior. Your other option would be an SR – but if this misbehavior is unknown you would need Extended Support for 12.1.0.2 in order to be able to get a bug filed. If Support knows about it, they will help you regardless of Extended Support yes/no.
In addition, regarding your OCW question, please check with Oracle Support, too.
Thanks,
Mike
We have extended support & I logged a ticket (Service Request # 3-28068395271), now closed.
The reply was:
There are no “installed but disabled” module bug fixes included in the 12.1.0.2.211019DBBP, hence that would not be listed.
Please check the details in
Managing “installed but disabled” bug fixes in Database Release Updates using DBMS_OPTIM_BUNDLE ( Doc ID 2147007.1 )
Section – Appendix E: Execution plan related bugs inclusion list 12.1.0.2
… a reference to that document ID in the v12 DBBP’s readme.html would have helped – at least next time I’ll know where to check first.
It can be problematic when a software supplier states they will only certify and support their product against a DB version that is years into Extended Support territory!
Hi VSmith,
sure – and agree – you are in the hands of a software supplier (I wonder which software this is).
And thanks for the update.
Cheers,
Mike
Hi Mike,
Sometimes, when I run datapatch, I get hit with ORA-00054. Following MOS note 2793549.1, I can run datapatch with database in UPGRADE mode.
I am in the process of migrating databases to Exadata Cloud@Customer using Data Guard. The ExaCC is at higher patch level (19.13) and the on-premises Exadata are at 19.9. So, after failover, I will have to run datapatch.
Instead of first running datapatch, potentially hitting ORA-00054, then switching over to UPGRADE mode, re-running datapatch, is it ok if I just start the DB in non-RAC, UPGRADE mode and run datapatch? It is slightly more downtime, but the customer is fine with it.
Thanks,
Arun
Hi Arun,
yes, this will work. And the reason for the ORA-54 has to do with concurrency. There were several issues seen in the previous RUs. It looks a bit as if there were changes in the RU’s sql/plsql portion which require exclusive dictionary access (which shouldn’t be the case in RUs). The normal workaround would be to run datapatch again – and then it should clear up everything. But your proposed W/A works fine, too.
Cheers,
Mike
Hi Mike,
Thanks for sharing useful info.
Is the below one applicable for Linux environment only or Windows too?
execute dbms_optim_bundle.enable_optim_fixes(‘ON’,’BOTH’, ‘YES’);
Thanks
Hi vsn,
this works on Windows as well.
Just see more blog posts about it here:
https://mikedietrichde.com/?s=DBMS_OPTIM_BUNDLE
Cheers,
Mike
Hello Mike,
I am a big fan of you. Thanks for all your posts. I was wondering if you have a point of running the ./datapatch -verbose after the database RU patch once and then after the OJVM RU patch. Wouldn’t it be less time-consuming to run it one time after applying both patches?
On another note, I am applying the 19.13 patch on Windows (Database RU p33155330_190000_MSWIN-x86-64.zip, OJVM p33192694_190000_MSWIN-x86-64.zip). However, the opatch lsinv keeps throwing the following errors:
Jan 04, 2022 2:34:38 PM oracle.opatch.wrappers.WrapperFactory loadWrapperProvider
WARNING: Unable to get determine fmw platform version.
java.lang.NullPointerException at java.nio.file.Files.provider(Files.java:97)
Hi Jean-Jules,
yes, you need to run it only once, not twice.
But regarding the opatch error, you please need to open an SR and check with Oracle Support.
Cheers,
Mike
Ran into this same issue on Windows Oracle Client with OPatch 12.2.0.1.28/29/30/32/? when the ORACLE_HOME has a space in it (e.g. C:\Program Files). Workaround is to place the affected OPatch in a directory without a space and execute it from there.
Thanks for sharing this workaround, Mike!
Cheers,
Mike
Mike,
Quick questions. Shouldn’t we run utlrp after patching? I thought this was required as per patching documentation.
Also, in the patching documentation, I do not see any reference to enabling optimizer fixes. Any reason why this is omitted?
Thanks,
Arun
Hi Arun,
no but before patching – you don’t need to run it afterwards.
Datapatch triggers it.
Thanks
Mike
Actually, many times I have seen datapatch will not run utlrp and throws a message at the end of datapatch session asking that utlrp must be run to complete compilation. This typically happens when database has too many invalid application objects.
I am thinking that datapatch has some sort of mechanism built into it which determines whether it will run utlrp or not.
Thanks,
Arun
Hi Arun,
it has a threshold parameter – see our slides here:
Recompilation threshold for invalid objects
=> Now: 300 invalid objects
===>> No recompilation attempted when less than 300 objects are invalid
=> Can be controlled by -recomp_threshold parameter
==>>>> Oracle 12.2.0.1 and higher since RU July 2019
==>>>>> Bug 30485255 – Datapatch: Increase Automatic Revalidation Threshold To 300
CHeers
Mike