Patching all my environments with the April 2020 Patch Bundles

Posted on April 14, 2020 by Patch Recommendation 54

My quarterly routine happens when the new security alerts get published. And it is time again. I’ll show you as usual how Patching all my environments with the April 2020 Patch Bundles works.

Patching all my environments with the April 2020 Patch Bundles

Photo by Kristin Brown on Unsplash

Security Alert April 2020

Let’s start with the Security Alerts for April 2020. It leads me to the April 2020 Critical Patch Advisory. I’m a database guy, so I’m interested in: Oracle Database Server, versions 11.2.0.4, 12.1.0.2, 12.2.0.1, 18c, 19c. And this link brings me directly to the Risk Matrix for the database products.

You will spot three >7 CVE score issues, one of them in the usual OJVM vulnerability. Basically for me this means: You must apply it if you have either OJVM and/or Oracle Multimedia installed. But there are more very important fixes included.

Patching all my environments with the April 2020 Patch Bundles

Oracle Database Server Risk Matrix – April 2020

The next click on Database brings me directly into MOS Note: 2633852.1 – Critical Patch Update (CPU) Program Apr 2020 Patch Availability Document. Section 3.1.4 covers the database patch downloads.

I download the following patch bundles:

  • Oracle Database 19c
  •  Oracle Database 12.2.0.1
  • Oracle Database 11.2.0.4 (non-Engineered System => PSU!)

Do I need a new OPatch?

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

  • 19.7.0 requires opatch 12.2.0.1.19 or later
  • 12.2.0.1 requires opatch 12.2.0.1.19 or later
  • 11.2.0.4 requires opatch 11.2.0.3.23 or later

So there has been a change to the previous patch round in January.

With $ORACLE_HOME/OPatch/opatch version I can quickly check whether I need to refresh my opatch installations. And Jackpot! I have 11.2.0.3.21 in my 11.2.0.4 home, and 12.2.0.1.17 in both, my 12.2.0.1 and my 19.6.0 homes. As the link to the patch magically disappeared from the 11.2.0.4 Readme, I use the other ones: patch 6880880. Oh, how much I like this chaos in the download screen for OPatch. Every time I ask myself why this can’t be cleaned up. Well, I blogged about this a long while ago already.

So basically, I wipe out my current OPatch directories in all my three homes. And once the new OPatch bundles have been unzipped, I can proceed. The 12.2.0.1.19 OPatch needs to go into both, the 12.2.0.1 and the 19c home.

And thanks to Miguel Anjo (see the comments section) for pointing me to this issue with the current OPatch mentioned in the  OPatch README:

CUSTOMERS ARE REQUESTED NOT TO RUN CLEANUP UTILITY COMMAND (./opatch util cleanup)
AS THE CLEANUP UTILITY HAS A BUG WHICH MAY POTENTIALLY DELETE SYSTEM FILES.

AFFECTED OPATCH RELEASES : 12.2.0.1.19 / 11.2.0.3.23
FIX WILL BE AVAILABLE IN RELEASE : 12.2.0.1.21/11.2.0.3.25 (Last week of April 2020)

Note: No other opatch functionalities are impacted and customers can continue to use.

Applying RU 19.7.0 to my 19c home

As usual, at first I apply 19.7.0 to my existing Oracle 19c home (currently at 19.6.0).

After I unzipped the patch into a separate directory, I run:

  1. opatch conflict check 
    $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
Oracle Interim Patch Installer version 12.2.0.1.19
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.19
OUI version       : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2020-04-15_00-07-38AM_1.log

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.
[CDB2] oracle@hol:~/30869156
  2. opatch apply 
    $ORACLE_HOME/OPatch/opatch apply
Oracle Interim Patch Installer version 12.2.0.1.19
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.19
OUI version       : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2020-04-15_00-08-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.19
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.19
OUI version       : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2020-04-15_00-09-19AM_1.log

Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   30869156  

Do you want to proceed? [y|n]
Y (auto-answered by -silent)
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 (auto-answered by -silent)
User Responded with: Y
Backing up files...
Applying interim patch '30869156' 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.tfa, 19.0.0.0.0 ] , [ oracle.oraolap.mgmt, 19.0.0.0.0 ] , [ oracle.rdbms.tg4db2, 19.0.0.0.0 ] , [ oracle.options.olap.awm, 19.0.0.0.0 ] , [ oracle.sqlj, 19.0.0.0.0 ] , [ oracle.net.cman, 19.0.0.0.0 ] , [ oracle.network.cman, 19.0.0.0.0 ] , [ oracle.assistants.asm, 19.0.0.0.0 ] , [ oracle.options.olap, 19.0.0.0.0 ] , [ oracle.xdk.parser.java.jaxb2, 19.0.0.0.0 ] , [ oracle.assistants.usm, 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.rsf, 19.0.0.0.0...

Patching component oracle.rdbms, 19.0.0.0.0...

...

Patching component oracle.precomp.common, 19.0.0.0.0...

Patching component oracle.nlsrtl.rsf.core, 19.0.0.0.0...

Patching component oracle.perlint, 5.28.1.0.0...

Patching component oracle.precomp.lang, 19.0.0.0.0...

Patching component oracle.jdk, 1.8.0.201.0...
Patch 30869156 successfully applied.
Sub-set patch [30557433] has become inactive due to the application of a super-set patch [30869156].
Please refer to Doc ID 2161861.1 for any possible further required actions.
Log file location: /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2020-04-15_00-09-19AM_1.log

OPatch succeeded.
[CDB2] oracle@hol:~/30869156

    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.

  3. datapatch 
    $ORACLE_HOME/OPatch/datapatch -verbose
SQL Patching tool version 19.7.0.0.0 Production on Wed Apr 15 00:14:23 2020
Copyright (c) 2012, 2020, Oracle.  All rights reserved.

Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_18226_2020_04_15_00_14_23/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.7.0.0.0 Release_Update 200404035018: Installed
  PDB CDB$ROOT:
    Applied 19.6.0.0.0 Release_Update 191217155004 successfully on 21-JAN-20 09.23.28.157993 PM
  PDB PDB$SEED:
    Applied 19.6.0.0.0 Release_Update 191217155004 successfully on 21-JAN-20 09.23.29.338333 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 30869156 (Database Release Update : 19.7.0.0.200414 (30869156)):
      Apply from 19.6.0.0.0 Release_Update 191217155004 to 19.7.0.0.0 Release_Update 200404035018
    No interim patches need to be applied

Installing patches...
Patch installation complete.  Total patches installed: 2

Validating logfiles...done
Patch 30869156 apply (pdb CDB$ROOT): SUCCESS
  logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/30869156/23493838/30869156_apply_CDB2_CDBROOT_2020Apr15_00_16_11.log (no errors)
Patch 30869156 apply (pdb PDB$SEED): SUCCESS
  logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/30869156/23493838/30869156_apply_CDB2_PDBSEED_2020Apr15_00_17_02.log (no errors)
SQL Patching tool complete on Wed Apr 15 00:17:57 2020
[CDB2] oracle@hol:~/30869156

Applying RU 12.2.0.1.200414 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.200414 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.

Microsoft Windows

Since some of you commented, either here on the blog or on Twitter, I realized as well that all the Windows Bundle Patches are missing right now. I can’t tell you why that is. And I see as well that none of them – except the 11.2.0.4 ones – is mentioned in the section 2.2 of MOS Note: 2633852.1. I fully understand when you get angry about this. But you have to raise your voice to your Oracle contacts about this please. And open SRs.

More Information and Links

–Mike

 

Share this:

Tags:

You may also like...

54 Responses

  1. Marcus Höll says:
    April 15, 2020 at 06:50

    Opatch download is like an adventure. They don’t even get it to do a sort in the dropdown. So badly developed.
    Even more it is an adventure when using Oracle on Windows. The patch is as always not available on Release Date. Anyway, you get a Post Release Date … normally … but this time, they forgot the patch and also the post release date.
    This is so disappointing as we can not plan anything.

    Reply
    • Mike.Dietrich says:
      April 15, 2020 at 16:45

      Marcus,

      I can only recommend to comment this to the people who are in charge.
      And I added a comment in the blog post, too, about the missing Windows bundle patches.

      You are not the only one – others have complained on twitter as well.

      Cheers,
      Mike

      Reply
    • Martin J S says:
      May 6, 2020 at 18:35

      According to Note 2633852.1 the April 2020 Bundle Patch (197.0.0.200414) for Windows will not be available before 12-May-2020 …

      Reply
      • Mike.Dietrich says:
        May 7, 2020 at 20:01

        Yes, they updated it again – I know what has happened … 🙁
        And the dev team is aware that customers are not amused about it.

        Thanks,
        Mike

        Reply
        • Martin J S says:
          May 13, 2020 at 06:21

          Update to Note 2633852.1 -> 19-May-2020 is the new date hopefully.

          Reply
          • Mike.Dietrich says:
            May 14, 2020 at 07:33

            Yes, I saw this – thanks!
            And the Win team is fully aware of the disappointment.
            I asked yesterday if the “patch is not available” message in MOS can be changed, but this seems to be impossible right now.
            And thanks for sharing the note number.

            Cheers,
            Mike

  2. Miguel Anjo says:
    April 15, 2020 at 08:18

    Hi Mike,

    Maybe is also important to point out that the now required version of OPatch (and currently the latest available) has this dangerous bug of deleting system files if you run ‘opatch util cleanup’ command.

    This is a bug I reported to Oracle end of January and now there is a warning in OPatch readme.

    See: https://anjo.pt/wp/keyword-oracle/2020/04/15/attention-opatch-12-2-0-1-19-opatch-cleanup-command-deletes-files-from-etc-bin-lib/

    The bug will be fixed on the next Opatch version, to be released until end of April.

    Cheers,
    Miguel Anjo

    Reply
    • Mike.Dietrich says:
      April 15, 2020 at 16:35

      Thank you, Miguel – this is very good to know!
      And I updated the blog post

      Cheers,
      Mike

      Reply
    • Peter says:
      April 16, 2020 at 09:29

      Many, many thanks for this hint Miguel,
      one additional info:
      the hint is only described in the online readme on the downloadpage.
      You won’t find it in the downloaded opatch readme.
      Cheers Peter

      Reply
      • Mike.Dietrich says:
        April 16, 2020 at 13:27

        OMG … I think then a blog post may be needed …

        Thanks for this hint, Peter!
        Mike

        Reply
      • Peter says:
        April 17, 2020 at 06:49

        Correction: the actual downloaded README contains this important hint. I’ve read an older readme of opatch version 19. The updated downloadable README is from 2020-04-03.
        I’m sorry!

        Reply
  3. Jonas Persson says:
    April 15, 2020 at 10:38

    Hi Mike and thanks for as always a great post!

    Why is the OPatch package using an older java version than the JDK patch provides?

    e.g for 19c
    Opatch 12.2.0.1.19 is using Oracle JRE 1.8.0.191
    whereas the latest JDK patch is updating to Oracle JRE 1.8.0.251

    Our security vulnerability scans are reporting on CVE-2019-11068 for Oracle JRE 1.8.0.191 in OPatch path but not for the usual patched jdk/jre path!

    After completed patching can I remove OPatch directory, in both GI_HOME and DB_HOME since it’s a RAC installation?

    Thanks and regards
    Jonas

    Reply
    • Mike.Dietrich says:
      April 15, 2020 at 12:59

      Hi Jonas,

      I see what you mean. I will drop an email to the guys who are (hopefully) responsible.

      This is the opatch java:

      $ ./java -version
      java version “1.8.0_191”
      Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
      Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
      [CDB2] oracle@hol:/u01/app/oracle/product/19/OPatch/jre/bin

      and this is the patched one in the home:

      $ ./java -version
      java version “1.8.0_241”
      Java(TM) SE Runtime Environment (build 1.8.0_241-b07)
      Java HotSpot(TM) 64-Bit Server VM (build 25.241-b07, mixed mode)
      [CDB2] oracle@hol:/u01/app/oracle/product/19/jdk/bin

      Cheers,
      Mike

      PS: For GI you shouldn’t need to care.

      Reply
  4. Mike S says:
    April 16, 2020 at 16:34

    Hi Mike,

    The link for “Risk Matrix for the database products” isn’t pointing to the Risk Matrix. Can you check that link?

    Thanks,
    Mike

    Reply
  5. Sadiq says:
    April 17, 2020 at 07:14

    Hi Mike,

    My Oracle database version is 12.1.0.2 is running on windows 64bit server.

    Can you please provide me the patch details required to be applied as part of april 2020 patch release as suggested above

    Thanks in advance..!!

    Sadiq

    Reply
    • Mike.Dietrich says:
      April 17, 2020 at 18:08

      Hi Sadiq,

      once the windows patches are available (should be Tuesday/wednesday next week), there is a readme associated with the patch which gives you step by step details.

      Let me know if it doesn’t work.

      Cheers,
      Mike

      Reply
  6. Neha says:
    May 7, 2020 at 06:29

    I have applied 30869156 Patch description: “Database Release Update : 19.7.0.0.200414 (30869156)” on 19.3.0.0 database .Is this okay ?
    or I have to apply on top of 19.0.0.0 . What is 19.3.0.0 s/w

    Reply
  7. Peter says:
    May 18, 2020 at 07:56

    Hi Mike,
    FYI:
    Since Saturday there is an MOS-Alert:
    “ALERT: Databases using ASM may crash after applying 12.2.0.1 April 2020 RU or 12.2.0.1 Apr2020 QFSDP for Exadata (Doc ID 2670164.1)”

    Patch is available.

    Cheers Peter

    Reply
    • Mike.Dietrich says:
      May 20, 2020 at 09:17

      Thanks Peter!

      I saw it as well 🙁 Uhhhh …

      Solution is:
      Apply patch 31341859 on all databases using ASM and running on 12.2.0.1 April 2020 RU or 12.2.0.1 Apr2020 QFSDP for Exadata.
      The patch has to be applied only to DB HOME.

      Mike

      Reply
      • Mike.Dietrich says:
        May 20, 2020 at 19:45

        Hi Peter,

        this applies to the April 2020 RU for 12.2.0.1 only – no other RU is affected.
        The inclusion of the fix for the July 2020 RU for 12.2.0.1 has been approved already.

        Sorry for the inconvenience – cheers,
        Mike

        Reply
  8. senthil says:
    May 18, 2020 at 10:21

    Hi Mike,

    We have Oracle 12.2.0.1 standalone with ASM ( Oracle Grid Infrastructure for a standalone) with Data guard.
    Do we need to apply patch – 30886680 or 30920127. we are new to CPU oracle patches.

    Thanks

    Reply
    • Mike.Dietrich says:
      May 20, 2020 at 09:20

      You should – but please be aware of this issue – you need an additional patch in your DB Homes.
      “ALERT: Databases using ASM may crash after applying 12.2.0.1 April 2020 RU or 12.2.0.1 Apr2020 QFSDP for Exadata (Doc ID 2670164.1)”

      This applies to you.

      Thanks
      Mike

      Reply
  9. Martin J S says:
    May 21, 2020 at 22:24

    WINDOWS DATABASE BUNDLE PATCH 19.7.0.0.200414 (Patch 30901317) is now available!
    https://support.oracle.com/epmos/faces/ui/patch/PatchDetail.jspx?patchId=30901317

    Unfortunately Patch 30835853: DBMS_JOB.SUBMIT PROCEDURE BEHAVIOR CHANGE IN 19C is not available for Windows!
    See https://mikedietrichde.com/2020/05/21/dbms_job-one-off-patch-needed-for-oracle-19-3-0-19-7-0/

    Patch 30994996: PROBLEMS IN CATMVRS.SQL OF BUG:30083002
    Would also recommend to install this patch on top of the bundle patch.

    The following bugs are annoying as well:
    * Bug 30352715 – JOB PROCESSES FILL THE FILESYSTEM WITH TRACE FILES AFTER INSTALLING BUG 29541742 (Patch 30352715 only available for Linux/Solaris/IBM, but not for Windows!)
    * Bug 30284751 – Many trace files with “Required IPC RDMAV_FORK_SAFE environment not set” fill Windows filesystem (according to Oracle support this bug is fixed in 20.1, but not in 19.x yet)

    In general it would be really helpful to include these fixes/patches in one of the next database bundle patches, e.g. 19.8.0.

    Reply
    • Mike.Dietrich says:
      May 24, 2020 at 18:22

      Martin,

      you have to request the Backport on Windows. And the fix will be included in 19.9.0, the Oct2020 RU. I received confirmation already from our folks.

      And as a special service for you (please ask Oracle Support in the future, it is their job to tell you):

      bug30994996 ==> Inclusion for 12.2.0.1, 18 and 19 requested on March 20 ==> no status yet
      bug30352715 ==> Requested for 19.7., 19.8 and many others ==> only approved for 20.3 yet
      bug30284751 ==> No request yet

      This means:
      1. Open an SR and request a merge patch including all those 3
      2. As you have no influence to trigger the inclusion, you can only try to escalate the SR, request a management callback and discuss with a support manager.
      I have no influence on what gets included on Win for OS specific content in future RUs/BPs

      Cheers,
      Mike

      Reply
      • Martin J S says:
        May 25, 2020 at 16:18

        Hi Mike!

        Thank you for you detailed update!

        I have already opened SRs for these problems and ask for inclusion.

        Sorry, it was not my intend to cast a slur at you.
        The last sentence was meant more in general way. I feel confident that we are not the only customer experiencing these annoying issues!

        As always, thanks for your help!

        Reply
  10. Karthik says:
    June 12, 2020 at 01:26

    Hi Mike,

    We have applied Database RU 19.7 on top of 19.5. OPatch completed successfully. While running datapatch, we are facing “ORA-38824: a create or replace command may not change the editionable property of an existing object.” error. Our database details: SE2 standalone database. Recently upgraded our database from 11.2.0.4 to 19.5

    Thanks,
    Karthik

    Reply
    • Mike.Dietrich says:
      June 14, 2020 at 16:08

      Hi Karthik,

      I fear you will need to open an SR. I checked on MOS, but I didn’t find a clear error pattern for this patch bundle (which could be also caused by the useless search functionality in MOS which makes it very hard to find what you are looking for).

      Thanks,
      Mike

      Reply
      • Karthik says:
        June 15, 2020 at 16:46

        Hi Mike,

        Thanks for your update. Yes, we have raised SR for the same, but its going forth and back between patching team and SDO team because its happening for MDSYS objects. Sure, I’ll work on SR.

        Thanks,
        Karthik

        Reply
  11. Jackie says:
    June 17, 2020 at 16:00

    Hi Mike,

    My team applied the April CPU but and we’re getting a vulnerability finding: “Oracle Java SE 1.7.0_261 / 1.8.0_251 / 1.11.0_7 / 1.14.0_1 Multiple Vulnerabilities (Apr 2020 CPU) (Unix)”. We reapplied the patch and we’re still showing the Java SE version as 1.8.0_241. Should it be at Java SE version 1.8.0_251 or do we have an issue on our patching?

    Reply
    • Mike.Dietrich says:
      June 17, 2020 at 18:24

      Jackie,

      check which java (or jdk) you are checking against. I’ve had the same issue.
      Do a “which java” to find out which one hasn’t been patched.

      Cheers,
      Mike

      Reply
      • Miguel Anjo says:
        June 17, 2020 at 19:27

        Hi Jackie, Mike,

        The April CPU does not come bundled with the latest JDK. You need to install a separate patch, which is released at the same time as the PSU. Check: JDK and PERL Patches for Oracle Database Home and Grid Home (Doc ID 2584628.1)
        I find it is not very clear on the docs, I opened an SR in January to understand.

        cheers,
        Miguel Anjo

        Reply
      • Miguel Anjo says:
        June 18, 2020 at 08:13

        Hi again,
        I found again the text. On Doc ID 2633852.1, comments column of Database Home patch availability, for each version, it states:
        “From Jan2020 onwards the Database and GI Update and Revision patches include the JDK fixes released in the prior cycle. For the most recent JDK fixes a separate patch is available (see below) and needs to be installed in addition to the Database and GI patches.”
        Cheers,
        Miguel Anjo

        Reply
  12. Jerry says:
    July 19, 2020 at 09:24

    Hi Mike,
    We have a critical DB on 2 node RAC (12.1), currently, the system is on Jan 2019 patch. We want to get to the latest patch i.e Mar 20. Is it a good idea to patch directly to Mar 20? Patches are cumulative, ideally, for the less critical environment, we would have directly jumped to the current patch level. Any thoughts or suggestions. Thanks!

    Reply
  13. Jerry says:
    July 19, 2020 at 09:38

    Hi …

    Further to my previous post , correction — I mean Apr 20 quarterly patch 🙂
    Cheers
    Jerry

    Reply
    • Mike.Dietrich says:
      July 20, 2020 at 19:19

      Hi Jerry,

      yes, of course – or even better, the July 2020 bundle instead.
      But you will need Extended Support to access to 12.1.0.2 bundles I’d guess, as Oracle 12.1.0.2 is under Paid Extended Support already.

      Cheers,
      Mike

      Reply
  14. Simon Cook says:
    August 13, 2020 at 11:37

    Hi Mike,

    I have just tried to apply patch 31247621 to my 19C Oracle windows environment and all went well until the very end when it reported … this :

    ru_build_description,
    ru_build_timestamp,
    patch_directory)
    VALUES
    (:patch_id,
    :patch_uid,
    :patch_descriptor,
    :ru_version,
    :ru_build_description,
    TO_TIMESTAMP(:ru_build_timestamp, ‘YYMMDDHH24MISS’),
    :patch_directory);
    COMMIT;
    ..Óè…..31247621.xml¢]█r█8.}^..WO╗UÙ.Ó.[.º2Ò.¡®╩î3╣Ý╝╣(…….¡³²..¼H└. H.j.F.Z8©6╗.}.Î?¡è.§.5m^.»’õ.=▒▓rVÑy9.=Yv..Ðõº.ïÙ÷█Ô]Ê═.¡▀n_O\ÔxaÓ.ëÁ,¾o╦l²M..Ò.íþ.┤ìñ«.¨,Úh½Ùo_O■©.X_.è═.ÂK.nY.^Ñ┘ÙIY5E▓á©m..I.ÑoÞ.┐.╠·.?▒.v.■¥Z,ª╔ýÙ¯½Ú2_ñ²_┤¢óª°Â.:.ëI@ýÝÀÀY;k‗║[.´}Â╚.6╗.Tº┤¢ëU¸]¹°¢ª¡¢.4▒.▓ñ[6┘þ¦l─.½Y¯²¨*ze¸.Mn..«Î?Ìk■µ.y.V¤¡u.t╔.┬X?/╦t.Y.ë¹ÀÁ¹}▀MÔY.x.Ã.^_qìQ.┐_^Zo.kV.uUfeÎÊ.e.õe.Zyiu.y╗..uyIÎÞ.▄═.e²°Ëj3║HÕî..Ln~y¾±═█╗.^_Ý¥.J;kÚw´´~..v’7.¦■,#ÚMn¯Ì▀■÷╗î¼?╣¨p{‘#.Lnn?╦..tXw.|³¤_.eñ#┌┘À.d$c:.w..H¯²Ð¥,ÚzM.‗E6▓.¶╚²┌K§x.▒..U¼.L.©¥.½┘..ëUf¤²)┌;A╗.▓..=┘.ÕõplM:-┌½$-‗‗è.W┌¶Kº.W┤.ÎW=«ã..þ░.²Gè╗4.¯..Î═S.┤.»Û┼T?¤cÀu….°Y.?.╩.■=k…y­èj=u°ú..¾Þ¶¨S..º¤L¯─ÕO¤f░]n├uª6╗├.┤..╣3.╬.4:Ùf…┬./═.G.▄.èqb.«î}.èq .¥Q1&.¯..Í.ek..9j┘*.Á┼¶³*..{.©Ó..¾H9j╠….+3.¦│y­Ãzi..l¶®1p..?.┴v╣’Ú├▓mµC¹Ý.═ʹJ¹©>3ß}{uıt¸kï■j║.;q..v.▀┐└Ú▒¬©.Ð
    )Êm».Ï▒ë´.ð.Ð5í^┘.╝┐.▀o…uÃb.µ╝HÁl>n«┴.uz─│Ý.ì´C¹5/ì..6.>²┌┤F┤|.t.Á▄§,9..t¦C[.Q┤.0(ÍË«¹..ÌÌ ú*ÂH.Ák.└g1.ı¼&·q¸ÁI.VY¦╬W·Q├CÈy▒hg·QúCÈþ.vªß.│¿±!Û¼}ª.Á├.6╗í(vÝÞÃ%╠Ê6½bí.ıa….’, :patch_id=’31247621′, :patch_uid=’23674370′, :ru_build_description=”Release_Update”, :ru_build_timestamp=”200724191610″, :ru_version=”19.8.0.0.0″] at H:\app\oracle\product\19_03_00\dbhome_1\\sqlpatch/sqlpatch.pm line 5549.

    Please refer to MOS Note 1609718.1 and/or the invocation log
    H:\app\oracle\cfgtoollogs\sqlpatch\sqlpatch_8472_2020_08_13_10_49_44\sqlpatch_invocation.log
    for information on how to resolve the above errors.

    SQL Patching tool complete on Thu Aug 13 10:51:01 2020
    H:\app\oracle\product\19_03_00\dbhome_1\OPatch>

    The MOS note it points you to 1609718.1 isn’t very helpful.. it basically says check the logs and fix the problem. The main problem is the logs have nothing in them which points to the issue.

    Any advice would be gratefully received,

    Thanks

    Reply
  15. Stig says:
    September 24, 2020 at 15:38

    Hi Mike.
    Is it possible to apply both patches -1 Windows Bundle and Oracle Javavm to Oracle home, and then start the the database in upgrade mode and run: Datapatch -verbose?

    Reply
    • Mike.Dietrich says:
      September 29, 2020 at 20:15

      Stig,

      the database does not need to be started in UPGRADE mode to run datapatch. You can start the database normally as I do.
      And yes, you can apply both at the same time.

      Cheers,
      Mike

      Reply
  16. Roman Miroshnychenko says:
    October 22, 2020 at 12:42

    Hi Mike.
    On advice of my colleague I am sharing issue here.
    Patch for Linux
    “Database Release Update : 19.7.0.0.200414 (30869156)” Created on 6 Apr 2020, 23:20:53 hrs PST8PDT
    was created earlier than for Windows
    “Windows Database Bundle Patch : 19.7.0.0.200414 (30901317)” Created on 18 May 2020, 03:13:11 hrs PST8PDT

    What is going on when we unplug pdb from Windows and plug into Linux? Yes, some kind of rollback

    It is actually fails with errors:
    Patch 30901317 rollback (pdb MASTER): WITH ERRORS
    logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/30901317/23471163/30901317_rollback_CDBA_MASTER_2020Oct21_21_39_32.log (errors)
    -> Error at line 47: script rdbms/admin/backport_files/bug_29738400_rollback.sql
    – SP2-0310: unable to open file “/u01/app/oracle/ora197/sqlpatch/30901317/23471163/rollback_files/19.7.0.0.0-RU-Release_Update-200514113449/rdbms/admin/backport_files/bug_29738400_rollback.sql”
    -> Error at line 89: script rdbms/admin/backport_files/bug_30305880_rollback.sql
    – SP2-0310: unable to open file “/u01/app/oracle/ora197/sqlpatch/30901317/23471163/rollback_files/19.7.0.0.0-RU-Release_Update-200514113449/rdbms/admin/backport_files/bug_30305880_rollback.sql”

    Actually both bug*rollback.sql files stored in another place
    We’ve run these commands to get success:

    [oracle@s-68292 backport_files]$ cd /u01/app/oracle/ora197/sqlpatch/30901317/23471163/rollback_files/19.7.0.0.0-RU-Release_Update-200514113449/rdbms/admin/backport_files
    [oracle@s-68292 backport_files]$ cp ../bug_29738400_rollback.sql ./
    [oracle@s-68292 backport_files]$ cp ../bug_30305880_rollback.sql ./
    $ORACLE_HOME/OPatch/datapatch -verbose -pdbs master

    Question:
    is it a bug and should be reported ?
    Do we need each time to check if RU of the same version is compatible between Windows and Linux and do some extra stuff in ORA_HOME in Linux to prevent this issue?

    Reply
    • Mike.Dietrich says:
      October 27, 2020 at 09:18

      Hi Roman,

      this doesn’t look healthy to me. Would you mind to open an SR please, upload all the logs and share the SR number with me or Daniel via email (or via the blog)?
      Then we’ll take it from there.

      Cheers,
      Mike

      Reply
  17. Roman Miroshnychenko says:
    October 22, 2020 at 23:06

    Hi Mike
    It is the first time I ‘m posting here, but looks like we faced quite interesting case.

    In Linux we have “Database Release Update : 19.7.0.0.200414 (30869156)” Created on 6 Apr 2020, 23:20:53 hrs PST8PDT

    However, in Windows it has been released later
    “Windows Database Bundle Patch : 19.7.0.0.200414 (30901317)” Created on 18 May 2020, 03:13:11 hrs PST8PDT

    What is going on when we unplug pdb from Windows and plug into Linux? Yes, some kind of rollback

    It is actually fails with errors:
    Patch 30901317 rollback (pdb MASTER): WITH ERRORS

    logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/30901317/23471163/30901317_rollback_CDBA_MASTER_2020Oct21_21_39_32.log (errors)
    -> Error at line 47: script rdbms/admin/backport_files/bug_29738400_rollback.sql
    – SP2-0310: unable to open file “/u01/app/oracle/ora197/sqlpatch/30901317/23471163/rollback_files/19.7.0.0.0-RU-Release_Update-200514113449/rdbms/admin/backport_files/bug_29738400_rollback.sql”
    -> Error at line 89: script rdbms/admin/backport_files/bug_30305880_rollback.sql
    – SP2-0310: unable to open file “/u01/app/oracle/ora197/sqlpatch/30901317/23471163/rollback_files/19.7.0.0.0-RU-Release_Update-200514113449/rdbms/admin/backport_files/bug_30305880_rollback.sql”

    Actually both bug*rollback.sql files stored in another place
    We’ve run these commands to get success:

    [oracle@s-68292 backport_files]$ cd /u01/app/oracle/ora197/sqlpatch/30901317/23471163/rollback_files/19.7.0.0.0-RU-Release_Update-200514113449/rdbms/admin/backport_files
    [oracle@s-68292 backport_files]$ cp ../bug_29738400_rollback.sql ./
    [oracle@s-68292 backport_files]$ cp ../bug_30305880_rollback.sql ./
    $ORACLE_HOME/OPatch/datapatch -verbose -pdbs master

    Question:
    is it a bug and should be reported ?
    Do we need each time to check if RU of the same version is compatible between Windows and Linux and do some extra stuff in ORA_HOME in Linux to prevent this issue?

    Reply
  18. Jerry says:
    October 23, 2020 at 19:04

    Hi Mike,
    Further to the Jul -19 post , we applied April 20 patch on our prod (12.1) environment, but datapatch stage invoked dictionary stats which indefinitely ran for 3 hrs , finally we raised a sev1 with Oracle and terminated datapatch. But this caused multiple issues – like db components going invalid etc. Finally we ran dictionary stats before our next attempt to patch , however datapatch somehow pics up dictionary stats and it runs for more than an hour. Now people are scared to give us a downtime for patching , somehow concept of dict stats with datapatch is still unclear and that too running dictionary stats before patch.

    Reply
    • Mike.Dietrich says:
      October 27, 2020 at 09:28

      Fully agree, Jerry – and actually I wasn’t aware that datapatch triggers dictionary stats.
      I’m aware that it has this flag: -recomp_threshold
      to adjust recompilation threshold.

      Which OPatch installation did you use (as it contains datapatch, too)?

      Cheers,
      Mike

      Reply
  19. Jerry says:
    October 27, 2020 at 11:45

    Hi Mike ,
    thanks ! opatch version is 12.2.0.1.21 -latest and Db version is 12.1.0.2
    This is core banking(Oracle FLEXCUBE) DB
    Did not find any metalink doc related to this , also Support guys are clueless.
    thanks for the tip recomp_threshold

    jerry

    Reply
  20. Jerry says:
    November 2, 2020 at 15:57

    thanks Mike !

    Reply
  21. Mani says:
    June 14, 2022 at 16:22

    Hi Mike,

    For applying JDK patch does it required database down time?

    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,331 other subscribers

Follow me on Twitter