Patching all my environments with the July 2020 Patch Bundles

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

Photo by Piron Guillaume on Unsplash

And just an important annotation upfront: I patch in-place due to space issues. But in reality, you please patch always out-of-place with a separate home.

Security Alert July 2020

This is the Security Alert for July 2020 listing all affected platforms and products. But as usual, I watch out for Oracle Database Server, versions 11.2.0.4, 12.1.0.2, 12.2.0.1, 18c, 19c, [Spatial Studio] prior to 19.2.1]. This link guides you to the Risk Matrix for the database.

And this time, it is a longer list than usual. It contains the usual OJVM fix but also a good number of APEX ones.

Risk Matrix Oracle Database Server – July 2020

But regardless of what’s included, you should apply the RUs anyway as there are a lot more fixes in it.

For instance, it contains a fix which disables the autotask window for the SYS_AUTO_STS I wrote about a few weeks ago.

Database Patch Bundles

You will find the links to the database patches in MOS Note: 2664876.1 – Critical Patch Update (CPU) Program Jul 2020 Patch Availability Document (PAD). In my case, this is the list of bundles:

• Oracle Database 19c
  • Database Release Update 19.8.0.0.200714 Patch 31281355 for UNIX (1.4GB)
    
  • Readme
  • List of fixes: MOS Note: 2523220.1 (does not include any 19.8.0 fixes yet unfortunately)
• Oracle Database 12.2.0.1
  • Database Jul2020 Release Update 12.2.0.1.200714 Patch 31312468 for UNIX (845MB)
    
  • Readme
• Oracle Database 11.2.0.4
  • Database PSU 11.2.0.4.200714 Patch 31103343 for UNIX (355MB)
    
  • Readme

Unfortunately, MOS Note: 2118136.2 – Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases hasn’t been updated either by the time I write this.

Do I need a new OPatch?

First check while the download is progressing: Do I need to refresh my OPatch versions?

• 19.8.0 requires opatch 12.2.0.1.21 or later
• 12.2.0.1 requires opatch 12.2.0.1.21 or later
• 11.2.0.4 requires opatch 11.2.0.3.23 or later (same requirement as in April 2020)

Patch download for OPatch is: 6880880. I wipe out my current OPatch directories in all my three homes. Once the new OPatch bundles have been unzipped into each home, I can proceed. The 12.2.0.1.21 OPatch needs to go into both, the 12.2.0.1 and the 19c homes.

Applying RU 19.8.0 to my 19c home

At first, I unzip the patch into a separate directory.

1. opatch conflict check

   [CDB2] oracle@hol:/u01/app/oracle/product/19
   $ cd 31281355/
   [CDB2] oracle@hol:/u01/app/oracle/product/19/31281355
   $ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
   Oracle Interim Patch Installer version 12.2.0.1.21
   Copyright (c) 2020, Oracle Corporation.  All rights reserved.
   
   PREREQ session
   
   Oracle Home       : /u01/app/oracle/product/19
   Central Inventory : /u01/app/oraInventory
      from           : /u01/app/oracle/product/19/oraInst.loc
   OPatch version    : 12.2.0.1.21
   OUI version       : 12.2.0.7.0
   Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2020-07-15_10-11-15AM_1.log
   
   Invoking prereq "checkconflictagainstohwithdetail"
   
   Prereq "checkConflictAgainstOHWithDetail" passed.
   
   OPatch succeeded.

2. opatch apply

   [CDB2] oracle@hol:/u01/app/oracle/product/19/31281355
   $ $ORACLE_HOME/OPatch/opatch apply
   Oracle Interim Patch Installer version 12.2.0.1.21
   Copyright (c) 2020, Oracle Corporation.  All rights reserved.
   
   
   Oracle Home       : /u01/app/oracle/product/19
   Central Inventory : /u01/app/oraInventory
      from           : /u01/app/oracle/product/19/oraInst.loc
   OPatch version    : 12.2.0.1.21
   OUI version       : 12.2.0.7.0
   Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2020-07-15_10-14-43AM_1.log
   
   Verifying environment and performing prerequisite checks...
   
   --------------------------------------------------------------------------------
   Start OOP by Prereq process.
   Launch OOP...
   
   Oracle Interim Patch Installer version 12.2.0.1.21
   Copyright (c) 2020, Oracle Corporation.  All rights reserved.
   
   
   Oracle Home       : /u01/app/oracle/product/19
   Central Inventory : /u01/app/oraInventory
      from           : /u01/app/oracle/product/19/oraInst.loc
   OPatch version    : 12.2.0.1.21
   OUI version       : 12.2.0.7.0
   Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2020-07-15_10-15-39AM_1.log
   
   Verifying environment and performing prerequisite checks...
   OPatch continues with these patches:   31281355  
   
   Do you want to proceed? [y|n]
   y
   User Responded with: Y
   All checks passed.
   
   Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
   (Oracle Home = '/u01/app/oracle/product/19')
   
   
   Is the local system ready for patching? [y|n]
   y
   User Responded with: Y
   Backing up files...
   Applying interim patch '31281355' to OH '/u01/app/oracle/product/19'
   ApplySession: Optional component(s) [ oracle.network.gsm, 19.0.0.0.0 ] , [ oracle.rdbms.ic, 19.0.0.0.0 ] , [ oracle.rdbms.tg4db2, 19.0.0.0.0 ] , [ oracle.tfa, 19.0.0.0.0 ] , [ oracle.oraolap.mgmt, 19.0.0.0.0 ] , [ oracle.xdk.parser.java.jaxb2, 19.0.0.0.0 ] , [ oracle.options.olap.awm, 19.0.0.0.0 ] , [ oracle.net.cman, 19.0.0.0.0 ] , [ oracle.assistants.asm, 19.0.0.0.0 ] , [ oracle.network.cman, 19.0.0.0.0 ] , [ oracle.sqlj, 19.0.0.0.0 ] , [ oracle.assistants.usm, 19.0.0.0.0 ] , [ oracle.options.olap, 19.0.0.0.0 ] , [ oracle.jdk, 1.8.0.191.0 ]  not present in the Oracle Home or a higher version is found.
   
   Patching component oracle.rdbms, 19.0.0.0.0...
   
   Patching component oracle.rdbms.util, 19.0.0.0.0...
   
   Patching component oracle.rdbms.rsf, 19.0.0.0.0...
   
   Patching component oracle.assistants.acf, 19.0.0.0.0...
   
   [...]
   Patching component oracle.xdk.parser.java, 19.0.0.0.0...
   
   Patching component oracle.rdbms.rsf.ic, 19.0.0.0.0...
   
   Patching component oracle.precomp.common, 19.0.0.0.0...
   
   Patching component oracle.precomp.lang, 19.0.0.0.0...
   
   Patching component oracle.jdk, 1.8.0.201.0...
   Patch 31281355 successfully applied.
   Sub-set patch [30869156] has become inactive due to the application of a super-set patch [31281355].
   Please refer to Doc ID 2161861.1 for any possible further required actions.
   Log file location: /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2020-07-15_10-15-39AM_1.log
   
   OPatch succeeded.

3. datapatch
   As final action, I will start my database and all pluggable databases again. The next step, datapatch, requires my databases and PDBs to be open.

   $ $ORACLE_HOME/OPatch/datapatch -verbose
   SQL Patching tool version 19.8.0.0.0 Production on Wed Jul 15 10:25:31 2020
   Copyright (c) 2012, 2020, Oracle.  All rights reserved.
   
   Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_13501_2020_07_15_10_25_31/sqlpatch_invocation.log
   
   Connecting to database...OK
   Gathering database info...done
   
   Note:  Datapatch will only apply or rollback SQL fixes for PDBs
          that are in an open state, no patches will be applied to closed PDBs.
          Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation
          (Doc ID 1585822.1)
   
   Bootstrapping registry and package to current versions...done
   Determining current state...done
   
   Current state of interim SQL patches:
     No interim patches found
   
   Current state of release update SQL patches:
     Binary registry:
       19.8.0.0.0 Release_Update 200703031501: Installed
     PDB CDB$ROOT:
       Applied 19.7.0.0.0 Release_Update 200404035018 successfully on 15-APR-20 12.17.51.919174 AM
     PDB PDB$SEED:
       Applied 19.7.0.0.0 Release_Update 200404035018 successfully on 15-APR-20 12.17.52.317976 AM
   
   Adding patches to installation queue and performing prereq checks...done
   Installation queue:
     For the following PDBs: CDB$ROOT PDB$SEED
       No interim patches need to be rolled back
       Patch 31281355 (Database Release Update : 19.8.0.0.200714 (31281355)):
         Apply from 19.7.0.0.0 Release_Update 200404035018 to 19.8.0.0.0 Release_Update 200703031501
       No interim patches need to be applied
   
   Installing patches...
   Patch installation complete.  Total patches installed: 2
   
   Validating logfiles...done
   Patch 31281355 apply (pdb CDB$ROOT): SUCCESS
     logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/31281355/23688465/31281355_apply_CDB2_CDBROOT_2020Jul15_10_27_58.log (no errors)
   Patch 31281355 apply (pdb PDB$SEED): SUCCESS
     logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/31281355/23688465/31281355_apply_CDB2_PDBSEED_2020Jul15_10_28_50.log (no errors)
   SQL Patching tool complete on Wed Jul 15 10:29:50 2020
   

4. AutoUpgrade
   As there is a new AutoUpgrade 19.9.1 available via MOS Note: 2485457.1 – AutoUpgrade Tool, I apply this right away to my home as well. And of course, if you have no intention to do any database upgrade on this host, you can safely skip this step.

   $ cp /media/sf_TEMP/July2020/autoupgrade1991/autoupgrade.jar $OH19/rdbms/admin
   
   $ java -jar $OH19/rdbms/admin/autoupgrade.jar -version
   build.hash 3b51369
   build.version 19.9.1
   build.date 2020/07/10 11:20:49
   build.max_target_version 19
   build.supported_target_versions 12.2,18,19
   build.type production
   

5. opatch util cleanup
   As somebody asked me the other day about whether it is ok to remove the directory where the patch has been unziped into? Yes, of course, this is ok. The information which is necessary to rollback the patch is kept in .patch_storage. And you can cleanup a little bit of it with “opatch util cleanup” – but be aware to be on a newer version of opatch.

   $ $ORACLE_HOME/OPatch/opatch util cleanup
   Oracle Interim Patch Installer version 12.2.0.1.21
   Copyright (c) 2020, Oracle Corporation.  All rights reserved.
   
   
   Oracle Home       : /u01/app/oracle/product/19
   Central Inventory : /u01/app/oraInventory
      from           : /u01/app/oracle/product/19/oraInst.loc
   OPatch version    : 12.2.0.1.21
   OUI version       : 12.2.0.7.0
   Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2020-07-15_10-41-51AM_1.log
   
   Invoking utility "cleanup"
   OPatch will clean up 'restore.sh,make.txt' files and 'scratch,backup' directories.
   You will be still able to rollback patches after this cleanup.
   Do you want to proceed? [y|n]
   y
   User Responded with: Y
   
   Backup area for restore has been cleaned up. For a complete list of files/directories
   deleted, Please refer log file.
   
   OPatch succeeded.

   Don’t expect miracles please.

Everything looks good.

But generally I recognize that especially the datapatch run, but also opatch apply itself took longer than in April 2020. Datapatch ran 1 minute longer than for 19.7.0.

Applying RU 12.2.0.1.200714 to my 12.2.0.1 home

I won’t copy/paste all steps as the output is similar to the above.

1. opatch conflict check

   $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./

2. opatch apply

   $ORACLE_HOME/OPatch/opatch apply

   Then I will need to startup my databases and all PDBs.

3. datapatch -verbose
   Final steps is “datapatch”. It requires the databases and all its PDBs to be up and running.

   $ORACLE_HOME/OPatch/datapatch -verbose

Applying PSU 11.2.0.4.200714 to my Oracle 11.2 home

For Oracle 11.2 I can only take the PSU. Bundle patches (BP) in Oracle 11.2 were only meant for Exadata systems. But the path to apply them is the same as for later bundles.

Again, I won’t copy/paste all steps as the output is similar to the above.

1. opatch conflict check

   $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./

2. opatch apply

   $ORACLE_HOME/OPatch/opatch apply

   Then I will need to startup my databases (FTEX and UPGR).

3. catbundle.sql
   Final steps is “catbudle.sql”. It requires the databases to be up and running.

   cd $ORACLE_HOME/rdbms/admin
   sqlplus / as sysdba
   @?/rdbms/admin/catbundle.sql psu apply

Everything fine now. No major issues seen. But as you know, my environment is simple and doesn’t include RAC or standbys.

Delayed?

Please don’t complain to me about missing patches. The section 2.2 Post Release Patches of MOS Note: 2664876.1 – Critical Patch Update (CPU) Program Jul 2020 Patch Availability Document (PAD) lists the delayed bundles. You will find that a lot of them are supposed to be published either tonight (July 15) in my CEST time zone or within the next days (Windows for instance). From the responsible people for MOS Note: 2664876.1 I know that they are updating the note in case there are further delays.

Side Track

This is the list of new underscore parameters I detected compared to Oracle 19.7.0. I won’t offer further comments or explanations as underscores are underscores. Hence, this section is for documentation purposes only.

Besides that, I didn’t see any significant parameter default value changes compared to 19.7.0.

Further Links and Information

• Security Alert for July 2020
• Oracle Database Server, versions 11.2.0.4, 12.1.0.2, 12.2.0.1, 18c, 19c, [Spatial Studio] prior to 19.2.1]
• Risk Matrix for the database – July 2020
• Do you love unexpected surprises – the SYS_AUTO_STS in Oracle 19.7.0
• MOS Note: 2664876.1 – Critical Patch Update (CPU) Program Jul 2020 Patch Availability Document (PAD)
• Patching all my environments with the April 2020 Patch Bundles
• MOS Note: 2485457.1 – AutoUpgrade Tool