Install and Patch in one single action with OUI

Posted on July 28, 2020 by Installation Patch Recommendation 41

This is such a common case: You want to install a new Oracle Home and you’d like to apply the most recent patch bundle to it as well. But as we don’t officially offer Gold Images to download where the RU is included already, you have to do three tasks instead of one. But you can avoid this and Install and Patch in one single action with OUI.

Recommendation and 3 standard actions

We always recommend that you apply the most recent RU. Hence, usually you will download Oracle Database 19.3.0 from eDelivery or from oracle.com at first. Afterwards you will download for instance Oracle 19.8.0 and apply it on top. And very often you will need to download and install a more recent version of OPatch beforehand.

Install everything in 1 action

Since Oracle Database 18c an often overlooked feature exists. With OUI, you can not only install Oracle 18.3.0 or Oracle 19.3.0 but you can also apply the patch bundle in addition with just one single call. And you can even add one-off patches on top. But make sure they are not conflicting.

Of course, you still need to download the software at first. In my case, I will download 19.3.0, the July 2020 RU 19.8.0 and the most recent version of opatch. In addition, I add one-off patch 29041775 to it. This cures a misbehavior of Multitenant when you mix character sets and add a PDB with character set WE8MSWIN1252. A customer I work with right now ran into this issue when migrating to ExaCS.

This is the approach.

  1. Create the future Oracle Home directory:
  2. Download and unzip the software release into the Oracle Home directory:
  3. Create /patch subdirectory for:
  4. Download and unzip the patch(es) into the patch subdirectory:
  5. all the installer and let it do its work:

You can use this approach also for multiple patches – just separate them with commas, e.g.:

./runInstaller -applyRU [patch-id] -applyOneOffs [patch-id1],[patch-id2],...

 

opatch?

When I demonstrated this technique in our Web Seminar 1: Database Release and Patching Strategy on June 23, 2020, somebody asked whether opatch needs to be updated as well. And that is a very valid question.

In fact, I agree – you should update opatch before you invoke the installer. As opatch is not an ordinary patch, you can’t install it via the runInstaller process. You need to copy it upfront into your home.

  1. Check the readme of the RU you’d like to apply
  2. Check the local current version of opatch in your unzipped new $ORACLE_HOME 
    $ export ORACLE_HOME=/u01/app/oracle/product/1980
[DB12] oracle@hol:/u01/app/oracle/product/1980/OPatch
$ ./opatch version
OPatch Version: 12.2.0.1.21

OPatch succeeded.
  3. If necessary, download the most recent opatch via patch 6880880.
  4. Remove the existing new $ORACLE_HOME/OPatch directory
  5. Copy the opatch zip into the new $ORACLE_HOME directory
  6. Unzip the opatch zip

Database

Here I will apply 19.8.0

I unpack the following two patches (RU 19.8.0 and one-off 29041775) into a subdirectory $ORACLE_HOME/patch.

VERY IMPORTANT:
Please be aware that you need to keep them separate directories as otherwise the XML files overwrite each other – that’s why it is one level deeper:

[DB12] oracle@hol:/u01/app/oracle/product/1980/patch
$ ls
29041775  31281355

Then I can call the OUI with – and VERY IMPORTANT again, you need to specify the subdirectories where the patches are located at. If you don’t do this, it will fail as I explain at the end of this blog post:

$ ./runInstaller -applyRU patch/31281355/31281355 -applyOneOffs patch/29041775/29041775
Preparing the home to patch...
Applying the patch patch/31281355/31281355...
Successfully applied the patch.
Applying the patch patch/29041775/29041775...
Successfully applied the patch.
The log can be found at: /u01/app/oraInventory/logs/InstallActions2020-07-27_05-57-23PM/installerPatchActions_2020-07-27_05-57-23PM.log
Launching Oracle Database Setup Wizard...

Afterwards, the OUI GUI starts up:

I’m just showing a few example screens here:

And finally, a few clicks later, everything is done.

Let me check what opatch has to say:

$ export ORACLE_HOME=/u01/app/oracle/product/1980
[DB12] oracle@hol:/u01/app/oracle/product/1980
$ OPatch/opatch lsinventory
Oracle Interim Patch Installer version 12.2.0.1.21
Copyright (c) 2020, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/oracle/product/1980
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/1980/oraInst.loc
OPatch version    : 12.2.0.1.21
OUI version       : 12.2.0.7.0
Log file location : /u01/app/oracle/product/1980/cfgtoollogs/opatch/opatch2020-07-27_17-44-14PM_1.log

Lsinventory Output file location : /u01/app/oracle/product/1980/cfgtoollogs/opatch/lsinv/lsinventory2020-07-27_17-44-14PM.txt
--------------------------------------------------------------------------------
Local Machine Information::
Hostname: hol
ARU platform id: 226
ARU platform description:: Linux x86-64

Installed Top-level Products (1): 

Oracle Database 19c                                                  19.0.0.0.0
There are 1 products installed in this Oracle Home.


Interim patches (3) :

Patch  29041775     : applied on Tue Jul 28 21:30:58 CEST 2020
Unique Patch ID:  23690111
Patch description:  "ORA-41401 IN ALERT.LOG EXACM"
   Created on 11 Jul 2020, 01:19:40 hrs PST8PDT
   Bugs fixed:
     29041775
   This patch overlays patches:
     31281355, 29517242, 31281355
   This patch needs patches:
     31281355, 29517242, 31281355
   as prerequisites

Patch  31281355     : applied on Tue Jul 28 21:27:57 CEST 2020
Unique Patch ID:  23688465
Patch description:  "Database Release Update : 19.8.0.0.200714 (31281355)"
   Created on 6 Jul 2020, 11:18:02 hrs PST8PDT
   Bugs fixed:
     30533132, 30312546, 29924181, 30980733, 31383396, 31094688, 7391838
     8476681, 14735102, 17428816, 19080742, 19697993, 20313356, 21374587
     [...]
     31134430, 31153120, 31156383, 31172207, 31177193, 31182793, 31193936
     31200845, 31305624, 31338673, 31393600, 31414023, 31414524

Patch  29585399     : applied on Thu Apr 18 09:21:33 CEST 2019
Unique Patch ID:  22840393
Patch description:  "OCW RELEASE UPDATE 19.3.0.0.0 (29585399)"
   Created on 9 Apr 2019, 19:12:47 hrs PST8PDT
   Bugs fixed:
     27222128, 27572040, 27604329, 27760043, 27877830, 28302580, 28470673
     [...]


--------------------------------------------------------------------------------

OPatch succeeded.

The message regarding the one-off is not really clear:

Patch  29041775     : applied on Tue Jul 28 21:30:58 CEST 2020
Unique Patch ID:  23690111
Patch description:  "ORA-41401 IN ALERT.LOG EXACM"
   Created on 11 Jul 2020, 01:19:40 hrs PST8PDT
   Bugs fixed:
     29041775
   This patch overlays patches:
     31281355, 29517242, 31281355
   This patch needs patches:
     31281355, 29517242, 31281355
   as prerequisites

I checked:

  • 31281355 is the July 2020 RU (19.8.0) – the patch bundle I install within the same process
  • 29517242 is the April 2019 RU (19.3.0) – the base release I settle on

Even though this message seems to be a bit strange to me, all went fine.

Mission accomplished.

But what if you use Grid Infrastructure?

Grid Infrastructure

The same approach works with Grid Infrastructure as well.

mkdir /u01/app/grid/1970
cd /u01/app/grid/1970
unzip LINUX.X64_193000_grid_home.zip
unzip p30899722_19000_Linux_x86-64.zip
./gridSetup -applyRU 30899722

And I had to laugh out loud on Friday when I started writing this blog post. In my twitter timeline, Anil Nair, RAC PM at Oracle, included me into a tweet – about the exact same topic. But of course, Anil covers GI – and he has added a very helpful troubleshooting section as well. So please, if you’d like to read the details about RAC/GI for this topic, check Anil’s post:

Video

You can watch the database software installation and patching in this video:

The not-so-nice part

Well, if something goes wrong, you will start from scratch again.

You can see below what happens when my patch application failed:

$ ./runInstaller -applyRU patch/31281355 -applyOneOffs patch/29041775
Preparing the home to patch...
Applying the patch patch/31281355/...
OPatch command failed while applying the patch. For details look at the logs from /u01/app/oracle/product/1980/cfgtoollogs/opatchauto/.

Problem 1:
Ok, I confess – the problem is in front of the screen. The way how I specify the subdirectories is wrong. But this leads me to …

Problem 2:
There is a “opatchauto” subdirectory. But this is not the one to look into as it is empty. The correct one is called “opatchautodb” in my case.

Problem 3:
The logfile does not really tell me what the issue is.

2020-07-24 15:51:46,871 INFO  [1] com.oracle.glcm.patch.auto.db.util.BootstrapHelper - indexOfRemote: -1
2020-07-24 15:51:46,873 INFO  [1] com.oracle.glcm.patch.auto.db.util.BootstrapHelper - currentUser: oracle
2020-07-24 15:51:46,923 INFO  [1] com.oracle.glcm.patch.auto.db.util.BootstrapHelper - indexOfRemote: -1
2020-07-24 15:51:46,923 INFO  [1] com.oracle.glcm.patch.auto.db.util.BootstrapHelper - currentUser: oracle
2020-07-24 15:51:46,967 INFO  [1] com.oracle.glcm.patch.auto.db.util.BootstrapHandler - Processing common bootstrap parameters.
2020-07-24 15:51:46,967 INFO  [1] com.oracle.glcm.patch.auto.db.util.BootstrapHandler - Space available: 239111 MB
2020-07-24 15:51:46,985 INFO  [1] com.oracle.glcm.patch.auto.db.util.PatchReaderUtil - Patch information is :  [Patch Location: patch/31281355/]
2020-07-24 15:51:46,985 INFO  [1] com.oracle.glcm.patch.auto.db.util.PatchReaderUtil - Patch information is :  [Patch Location: patch/31281355/, Patch Base Directory: null, Patch Id: null]
2020-07-24 15:51:47,711 INFO  [1] com.oracle.glcm.patch.auto.db.util.PatchPlatformValidator - Patch Aru id:226
2020-07-24 15:51:47,713 INFO  [1] com.oracle.glcm.patch.auto.db.util.PatchPlatformValidator - Platform Aru id:226
2020-07-24 15:51:47,715 INFO  [1] com.oracle.glcm.patch.auto.db.util.BootstrapHandler - The patchInfo is : com.oracle.glcm.patch.auto.session.PatchInfoImpl@34ce8af7
2020-07-24 15:51:47,717 INFO  [1] com.oracle.glcm.patch.auto.db.util.BootstrapController - The bootstrap params are: BootstrapParams [baseLocation=/u01/app/oracle/product/1980, operationType=APPLY, homes=null, customLogDir=/u01/app/oracle/product/1980/cfgtoollogs, customConfigDir=/u01/app/oracle/product/1980/opatchautocfg/db, invPtrLocation=null, isRemotePatching=false, isOOPPatching=false, patchInfo=com.oracle.glcm.patch.auto.session.PatchInfoImpl@34ce8af7, credential=null, gridHome=null, gridVersion=null, isBinaryPatching=true, isShardSidbPatching=false, isStandaloneSidbPatching=false, pathWithFilesFromLoc=null]
2020-07-24 15:51:47,727 INFO  [1] com.oracle.glcm.patch.auto.db.utils.BootstrapUtil - Creating boostrap dir: /u01/app/oracle/product/1980/opatchautocfg/db/dbtmp/bootstrap_hol
2020-07-24 15:51:47,727 INFO  [1] com.oracle.glcm.patch.auto.db.utils.BootstrapUtil - Creating patchwork dir: /u01/app/oracle/product/1980/opatchautocfg/db/dbtmp/bootstrap_hol/patchwork
2020-07-24 15:51:47,784 INFO  [1] oracle.glcm.opatch.common.impl.PatchFactoryImpl - Registering:SYSTEM_PATCH:oracle.glcm.opatch.common.impl.SystemPatch
2020-07-24 15:51:47,785 INFO  [1] oracle.glcm.opatch.common.impl.PatchFactoryImpl - Registering:COMPOSITE_PATCH:oracle.glcm.opatch.common.impl.CompositePatch
2020-07-24 15:51:47,785 INFO  [1] oracle.glcm.opatch.common.impl.PatchFactoryImpl - Registering:SINGLETON_PATCH:oracle.glcm.opatch.common.impl.SingletonPatch
2020-07-24 15:51:47,792 INFO  [1] oracle.glcm.opatch.common.impl.PatchFactoryImpl - Singleton  patch not found
2020-07-24 15:51:47,795 INFO  [1] oracle.glcm.opatch.common.impl.PatchFactoryImpl - Composite patch NOT found
2020-07-24 15:51:47,796 INFO  [1] oracle.glcm.opatch.common.impl.PatchFactoryImpl - System patch NOT found
2020-07-24 15:51:47,796 SEVERE [1] com.oracle.glcm.patch.auto.db.util.PerlBootstrapPlugin - Exception while loading the patch for validating perl patching as the patch type is invalid: The patch type is invalid in patch location: /u01/app/oracle/product/1980/patch/31281355
2020-07-24 15:51:47,797 SEVERE [1] com.oracle.glcm.patch.auto.db.util.PerlBootstrapPlugin - OPATCHAUTO-72146: Failed to load patch
OPATCHAUTO-72146: Failed while collecting patch information for patch patch/31281355/.
OPATCHAUTO-72146: Check the log for more information.
2020-07-24 15:51:47,798 INFO  [1] com.oracle.glcm.patch.auto.db.util.BootstrapHandler - The bootstrap execution result is : [BootstrapResult [result=FAILED, pluginType=PERL, errorMessage=OPATCHAUTO-72146: Failed to load patch
OPATCHAUTO-72146: Failed while collecting patch information for patch patch/31281355/.
OPATCHAUTO-72146: Check the log for more information., errorCode=72145]]
2020-07-24 15:51:47,808 SEVERE [1] com.oracle.glcm.patch.auto.db.util.BootstrapHandler - OPATCHAUTO-72083: Performing bootstrap operations failed.
OPATCHAUTO-72083: The bootstrap execution failed because OPATCHAUTO-72146: Failed to load patch
OPATCHAUTO-72146: Failed while collecting patch information for patch patch/31281355/.
OPATCHAUTO-72146: Check the log for more information..
OPATCHAUTO-72083: Fix the reported problem and re-run opatchauto.

Well, it looks liks as if opatch couldn’t find the patch information But it is there (I thought so). I checked it. But it seems not to look for the XML file. To me, the above log information was neither clear nor obvious. And I didn’t find useful information in MOS searching for OPATCHAUTO-72146 and OPATCHAUTO-72083.

Problem 4:
If you’d like to alter something now, and run it again, well …

$ ./runInstaller -applyRU patch/31281355/ -applyOneOffs patch/29041775/

ERROR: The home is not clean. This home cannot be used since there was a failed OPatch execution in this home. Use a different home to proceed.

Ouch. Gladly I work in VBox and created a snapshot upfront. Back to start.

The Solution:
Very simple: $ ./runInstaller -applyRU patch/31281355/31281355 -applyOneOffs patch/29041775/29041775

MS Windows [added Nov 23, 2020]

Well, thanks to Joel Peran who tested this with 19.9.0 on MS Windows. I wasn’t aware but it seems to be that this nice little feature didn’t found its path into the Windows code. This screenshot is from Joel:

Install and Patch in one single action with OUI

Hence, unfortunately “applyRU” does not work on the MS Windows platform.

Summary

Kudos to the guys who developed it. This is really really REALLY a very convenient way to install and patch in one action – and as Anil showed, it works with GI as well. I like this approach a lot, it eases my tasks and I can automate things. With -applyRU you can add RUs (I didn’t try RURs but I ignore them anyways), with -applyOneOffs you can add one-off patches. Very convenient approach. Try it out please.

Further Information and Links

–Mike

Share this:

Tags:

You may also like...

41 Responses

  1. Mark J Bobak says:
    July 28, 2020 at 10:21

    Hi Mike,
    You talk about 19.8 RU, but at the end when you use ‘opatch lsinventory’ to show that everything worked, it’s showing the 19.7 RU in the output? Looks like something got mixed up there.

    -Mark

    Reply
    • Mike.Dietrich says:
      July 28, 2020 at 22:02

      Thanks Mark,

      I realized this as well. I’ve had an issue with 19.8, switched to 19.7 then to complete the blog post – then learned that I did something wrong – and switched back but didn’t copy the right output. I’ve had that feeling that something was not correct – and fixed it.

      Thanks for spotting this!

      Cheers,
      Mike

      Reply
  2. Neil says:
    July 28, 2020 at 22:45

    Hi Mike,

    Couple of questions.

    1. Does this work with Gold Images – i.e, can you take a Gold Image (either Oracle supplied or one created via clone option) of say a 19.6 $OH and apply 19.8 on top?

    2. Presumably this can be run in silent mode without the GUI?

    Thanks
    Neil

    Reply
    • Mike.Dietrich says:
      July 29, 2020 at 21:53

      Hi Neil,

      I never tried this with Gold Images – the RU is included already into it.
      And I haven’t tried this in silent mode. But I’d guess so as you can combine the options into a response file and execute it with -silent.

      Thanks,
      Mike

      Reply
  3. Emad Al-Mousa says:
    July 30, 2020 at 07:20

    Hi Mike,

    Thanks for you technical tips…it helps us a lot !

    just wanted to share a small technical tip, in addition of using OPatch lsinventory command (which is the best/official way to check patches applied on the binary)….if you execute sqlplus immediately after patching the sqlplus prompt will display updated oracle version with the new RU build number in this case 19.8. This is because oraversion file under $ORACLE_HOME/bin directory gets updated when binaries are patched.

    Regards,
    Emad

    Reply
  4. Chris Smids says:
    August 17, 2020 at 07:48

    Hello Mike,

    Thank you very much for sharing this indeed often overlooked feature.

    I have a question, not related to this feature, but related to the one-off patch 29041775 which you applied to it.

    Do you recommend to always install one-off patch 29041775 in the Oracle 19c DB software for anyone who’s going to mix DB character sets within one CDB involving the DB character set WE8MSWIN1252 ?

    We are planning to do so, so maybe we will then also have to include one-off patch 29041775 in our Oracle 19c DB software ?

    Greetings,

    Chris Smids

    Reply
    • Mike.Dietrich says:
      August 18, 2020 at 17:52

      Hi Chris,

      yes, I would recommend this – but only when MSWIN1252 is involved.
      As far as I see from the bug description, it happens with this one only.

      Cheers,
      Mike

      Reply
  5. Chris Smids says:
    August 19, 2020 at 05:38

    Thank you very much for the answer Mike !

    I hope it will not be an issue when you have the situation on a server where you have CDB’s having this mixed setup (CDB – AL32UTF8 and one or more PDB’s – WE8MSWIN1252) and CDB’s not having this mixed setup (CDB – AL32UTF8 and one or more PDB’s – AL32UTF8) using the same Oracle 19c DB software having the fix for bug 29041775 installed ?

    Greetings,

    Chris

    Reply
  6. Jeffrey Dawson says:
    September 1, 2020 at 22:47

    I plan to test this with VirtualBox, but have you tried to apply the OJVM/DB RU Combo patch (e.g. patch 31326362) with the “-applyRU” option?

    Reply
  7. Jeffrey Dawson says:
    September 2, 2020 at 19:28

    Hello Mike,

    I plan to test this in a VirtualBox VM, but have you had the opportunity to test whether or not you can apply both the latest DB RU and OJVM RU using this method. For example, patch 31326362 is the July 2020 combo patch for Linux x86_64. Could you apply both RUs during the installation with a command similar to:

    ./runInstaller -applyRU patch/31326362/31281355 -applyOneOffs patch/31326362/31219897

    Reply
  8. Jeffrey Dawson says:
    September 11, 2020 at 17:12

    I’m pleased to report that you can apply the OJVM RU using the “-applyOneOffs” parameter. You can also provide a list of other one-off patches if needed. This is very helpful for an automated build process.

    Reply
  9. Andreas says:
    October 25, 2020 at 01:12

    Hi Mike,

    I use this since it was introduced in 12.2 for GI, and 18 for DB and I’m very happy with it. I also pack the patched home to use it to install on another machine. I find it much easier to use than gold images.
    As far as I know and tried, this only applies to Linux systems? The windows version lacks the cli flag – at least at the last time I tried a few month ago.

    Cheers,
    Andreas

    Reply
  10. Ramanan Neelakandan says:
    November 25, 2020 at 20:35

    Hi Mike,

    Can I use this method as Out of place Patching method ? . Install New home using Run Installer with RU on it

    Do switchover using opatchauto switchover command ?

    Will it work like that ?

    Thanks,
    Ramanan

    Reply
  11. Mario Guarino says:
    December 4, 2020 at 16:39

    Hi Mike,
    I have had the same error OPATCHAUTO-72043 applying the 19.9 RU for grid environment and the strange thing is that I had it on a shared FS but on node 1 it worked correctly, on node 2 it failed. I have solved downloading again it, unzipping as root in a different location (not shared) and then changing ownership to oracle.dba.

    Hi hope this can help for the next time

    cheers

    Mario

    Reply
  12. Sunil Shetty says:
    April 8, 2021 at 14:31

    HI Mike,

    Regarding Problem 4

    $ ./runInstaller -applyRU patch/31281355/ -applyOneOffs patch/29041775/

    ERROR: The home is not clean. This home cannot be used since there was a failed OPatch execution in this home. Use a different home to proceed.

    Simple fix is to remove file $GI_HOME/install/patch. It’s zero byte file and created when ./gridSetup.sh fails.

    Reply
  13. Jared Still says:
    August 16, 2021 at 13:40

    I thought it was time to try an patch my lab environment, which is a 2 node RAC, which was at 19.8.

    The same issues others have faced made it impossible to patch in place.
    – opatch 12.2.0.1.25 is buggy
    – opatch 12.2.0.1.24 is not available. Also found someone in the forums that did have the older version, but it will not work – too old
    – ancillary issues, such as providing an NFS mount for the patches, both for grid and oracle, as each must own the directory
    – probably more but that is enough

    Patching is not something I usually do, but as it is my lab, I have to do it.

    So, I tried the out of place patching, both for grid, and oracle.

    I worked quite well, but it is o-so-slow.

    This is only a lab, but still, I’ve been using RAC on it for quite some time, and it isn’t *that* slow.

    The patching process is very resource intensive at times, though I haven’t tried to find out just what it is.

    And datapatch – that ran for 6 hours.

    In any case, patching out of place worked without any issues, other than a couple of user errors

    Reply
    • Mike.Dietrich says:
      August 25, 2021 at 20:36

      Hi Jared,

      thanks for the comment – and I know about this strange recommendation to use an older opatch – because than the patch does not accept the older version since it is asking for the newer opatch. I think opatch 27 will fix this chaos.

      Cheers,
      Mike

      Reply
      • Andreas says:
        September 9, 2021 at 10:44

        Hello Mike!

        Is OPatch 27 realy the solution?
        I am trying for two days to get this scenario working and allways getting “OPatch command failed while applying the patch.”
        (scripting installation plus RU patching and OJVM one off patching was done in under one hour)

        I did watch your video for several times, re-read the blog, in order not to miss out a tiny detail.
        But I don’t get it.

        This what I am doing in my test environment:
        NewHome=/oracle/product/db/TST12/1912
        ORACLE_HOME=$NewHome
        # rm -rf $NewHome
        # 19c Base
        mkdir -p $NewHome
        cd $NewHome
        unzip -o /install/sw/oracle/Software/Oracle19/Release/V982063-01_LINUX.X64_193000_Database.zip
        # Patchset 19.12
        mkdir -p $NewHome/patch/32904851
        cd $NewHome/patch/32904851
        unzip -o /install/sw/oracle/Software/Oracle19/RU/1912/p32904851_190000_Linux-x86-64.zip
        # OPatch 12.2.0.1.27
        cd $NewHome
        ls -l -d OPatch*
        mv OPatch OPatch.$(date “+%Y%m%d_%H%M%S”)
        unzip -o /install/sw/oracle/Software/Oracle19/OPatch/p6880880_122010_Linux-x86-64_1220127.zip
        ls -ld OPatch*
        $ORACLE_HOME/OPatch/opatch version
        # Install and patch
        cd $NewHome
        ./runInstaller -applyRU $ORACLE_HOME/patch/32904851/32904851

        Also tried it with:
        ./runInstaller -applyRU patch/32904851
        ./runInstaller -applyRU patch/32904851/32904851
        ./runInstaller -applyRU $ORACLE_HOME/patch/32904851

        Always the same: OPatch command failed while applying the patch.

        Maybe the problem is sitting in front of my screen, but I realy think I did it the right way.

        So, if OPatch 12.2.0.1.27 is not the problem, where could I find some more information?

        Regards
        Andreas

        Reply
  14. Sergey says:
    December 10, 2021 at 16:11

    Hi, Mike

    Something is wrong with -applyRU for 19.13 on Solaris, for Grid & DB Home.

    Everything looks good:

    grid@plat163dom1:~$ /u01/app/19.13.0/grid/gridSetup.sh -applyRU /u01/stage/33182768
    Preparing the home to patch…
    Applying the patch /u01/stage/33182768…
    Successfully applied the patch.
    The log can be found at: /u01/app/oraInventory/logs/GridSetupActions2021-12-10_06-03-14PM/installerPatchActions_2021-12-10_06-03-14PM.log
    Launching Oracle Grid Infrastructure Setup Wizard…

    But RU patch “applied in 2-3seconds instead of few minutes”. And there is no applied RU 19.13 in inventory later. It is not applied in fact. The problem exists only with 19.13 on Solaris. It worked well within 19.4-19.11
    OPatch Version: 12.2.0.1.28
    Logs does not contain any errors…

    Reply
  15. Mane says:
    February 18, 2022 at 11:47

    reminder to myself: -applyRu is not the same as -applyRU 😉

    Reply
  16. David.Dill says:
    March 7, 2022 at 17:34

    After patching and moving to a new home, how does everyone update the OH in 3rd party tools/applications (e.g. enterprise backup solution)?

    For example (Linux):

    Old OH: /u01/app/oracle/product/19.3.0.0

    New OH: /u01/app/oracle/product/19.12.0.0

    Seems impractical to update all 3rd party tools with this new path every quarter.

    Can you create a generic symbolic link (e.g /u01/app/oracle/product/19.0.0.0) that points to the current OH (e.g. /u01/app/oracle/product/19.12.0.0)? So whenever I patch, I just update the link….

    Reply
    • Mike.Dietrich says:
      March 21, 2022 at 23:53

      Hi David,

      doesn’t an external application, regardless of what it does connect via the service name?
      I have not seen an Oracle database backup solution using the home path.

      Thanks,
      Mike

      Reply
  17. Saanchi says:
    March 22, 2022 at 13:01

    Hi Mike,

    Recently I encountered an issue while installing 19c Grid (19.3.0.0) and applying July CPU on top of it using Applyru.
    ./gridSetup -applyRU

    The command completed very fast and said “patch applied successfully”. However, the message was misleading as Oracle did not apply the patch. The reason being I had applied latest Opatch patch without moving OPatch directory and choosing the option replace “A”.

    When I updated OPatch by creating a new directory, the patch was finally applied and it took a while!

    Oracle document Doc ID 1410202.1 says when upgrading OPatch do not move the folder OPatch

    “Note: Choose Overwrite ALL when prompted, do NOT remove the old OPatch directory from the GI_HOME prior to extracting”

    But above instruction if followed, leads to the issue described above.
    Wondering if you have any comments on it?

    Thanks.

    Reply
  18. Brian Schnell says:
    April 26, 2022 at 15:01

    Hi Mike,
    I am receiving a very strange behavior when trying to install the 19.3.0.0.0 software onto a system that already has a 12.2.0.1 oracle database running. I am wanting to eventually use the autoupgrade.jar file to complete the upgrade. However, it has become a great challenge to even install the 19c software only. The issue is that the Universal Installer will not even open to allow me to start the installation at all.

    When I use the ./runInstaller command by itself, I receive the message “Path ‘/InstallActions’ for work directory is invalid. It must be specified as an absolute pathname”. Then you are forced to select the “OK” button, which causes the installer to abort.

    Now, when I add the -applyRU to add the newest RU to the ./runInstaller command, I receive the message “File name too long at /opt/oracle/product/19//bin/CommonSetup.pm line 1404”.

    I have even tried running the ./runInstaller command in -silent mode using a response file with the same results.

    The system that is running is:
    OS Version is SUSE Linux 12 SP5 x86_64 with kernel 4.12.14-122.113-default

    Have you ever run across anything similar as this? I have already created a SR ticket with Oracle support with no success at this time. We have been working together on this for 12 days. Any information you may have would be appreciated very much. Thank you.

    Regards,
    Brian

    Reply
    • Mike.Dietrich says:
      May 15, 2022 at 20:38

      Hi Brian,

      whenever I saw such issues, it had to do with the LOCALE.
      Have you checked with Oracle Support?

      Thanks,
      Mike

      Reply
    • Mane says:
      May 16, 2022 at 07:05

      the double slash in the path looks weird: /opt/oracle/product/19//bin/CommonSetup.pm
      -> do you have a slash at the end of your ORACLE_HOME variable? Maybe this causes problems?

      Reply
      • Mike.Dietrich says:
        May 16, 2022 at 09:45

        I agree – this looks strange – maybe something in the environment?

        Cheers
        Mike

        Reply
      • Jared Still says:
        May 16, 2022 at 14:55

        Linux does not care about the double dash, nor had any other unix I have worked on. It would seem odd if this were causing an issue with Oracle.

        Nonetheless, I think it would be a good idea to look for trailing slashes in /etc/oratab, and remove them if found.

        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