Patching all my environments with the October 2022 Bundle Patches

Posted on November 9, 2022 by Patch Recommendation 55

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.

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.

Patching most of my environments with the October 2022 Bundle Patches

Oracle Database Server Risk Matrix – October 2022

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
  • Oracle Database 19c
  • 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.

  1. 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.

     

  2.  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.

  3. 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

     

  4. 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.

  1. 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.
    .

  2. 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.

  3. 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.

     

  4. 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.

  5. 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

     

  6. 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.

  7. 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

–Mike

Share this:

Tags:

You may also like...

55 Responses

  1. Dhiren Singh says:
    November 9, 2022 at 13:31

    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 ?

    Reply
    • Mike.Dietrich says:
      November 9, 2022 at 17:29

      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

      Reply
  2. Ben says:
    November 9, 2022 at 14:24

    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?

    Reply
    • Mike.Dietrich says:
      November 9, 2022 at 17:04

      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

      Reply
  3. Ed Cleary says:
    November 9, 2022 at 16:33

    Mike, looks like a copy and past error in 19c section. You have “July” instead of “October”.

    Reply
  4. Peter says:
    November 10, 2022 at 12:57

    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!

    Reply
    • Mike.Dietrich says:
      November 14, 2022 at 16:03

      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

      Reply
      • Peter says:
        November 14, 2022 at 16:44

        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

        Reply
        • Mike.Dietrich says:
          November 14, 2022 at 16:53

          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

          Reply
          • Peter says:
            November 14, 2022 at 16:59

            Sure thing, Mike!
            3-31199378881

          • Mike.Dietrich says:
            November 14, 2022 at 17:05

            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

          • Peter says:
            November 14, 2022 at 17:11

            Awesome, thanks a lot!
            Cheers,
            Peter

          • Mike.Dietrich says:
            November 14, 2022 at 21:46

            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

          • Peter says:
            November 15, 2022 at 15:46

            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

          • Mike.Dietrich says:
            November 15, 2022 at 16:20

            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

          • Peter says:
            November 16, 2022 at 15:33

            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

          • Mike.Dietrich says:
            November 17, 2022 at 14:49

            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

    • Peter says:
      November 17, 2022 at 15:36

      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

      Reply
  5. Andrew says:
    November 11, 2022 at 11:38

    is OJVM released at the same time as the Windows Bundle? Can find Bundle 19.17 but not the related OJVM.

    Reply
  6. Uwe says:
    November 11, 2022 at 15:05

    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

    Reply
  7. Andrew Henry says:
    November 15, 2022 at 22:49

    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?

    Reply
  8. Laurent Schneider says:
    November 21, 2022 at 10:23

    Hi Mike
    Doc 2888497.1 mentions patching perl to 5.32-1. Could you advise on patching perl?

    Thanks

    Reply
  9. Hans-Martin Ruff says:
    November 22, 2022 at 08:32

    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

    Reply
    • Mike.Dietrich says:
      November 23, 2022 at 14:31

      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

      Reply
  10. Hans-Martin Ruff says:
    November 23, 2022 at 17:55

    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

    Reply
  11. Arun Gupta says:
    December 9, 2022 at 14:43

    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

    Reply
  12. Davide says:
    January 18, 2023 at 15:53

    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

    Reply
    • Mike.Dietrich says:
      January 19, 2023 at 11:47

      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

      Reply
  13. Christian Floreck says:
    January 30, 2023 at 11:16

    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

    Reply
    • Mike.Dietrich says:
      January 30, 2023 at 11:38

      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

      Reply
  14. Christian Floreck says:
    February 1, 2023 at 12:41

    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

    Reply
  15. Adnan Naseem says:
    March 3, 2023 at 21:19

    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.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Mike Dietrich
Oracle Senior Director of Product Manager for Database Upgrade, Migrations and Patching writing just another blog.

Opinions certainly are my own as is this page.

Archives

Categories

Upgrade @YouTube

Subscribe via Email

Join 7,887 other subscribers

Follow me on Twitter