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.
- Create the future Oracle Home directory:
- Download and unzip the software release into the Oracle Home directory:
- Create /patch subdirectory for:
- Download and unzip the patch(es) into the patch subdirectory:
- 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],...
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.
- Check the readme of the RU you’d like to apply
- 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: 18.104.22.168.21 OPatch succeeded.
- If necessary, download the most recent opatch via patch 6880880.
- Remove the existing new $ORACLE_HOME/OPatch directory
- Copy the opatch zip into the new $ORACLE_HOME directory
- Unzip the opatch zip
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.
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 22.214.171.124.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 : 126.96.36.199.21 OUI version : 188.8.131.52.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 184.108.40.206.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 : 220.127.116.11.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 18.104.22.168.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
- 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.
But what if you use 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:
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/.
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 …
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.
The logfile does not really tell me what the issue is.
2020-07-24 15:51:46,871 INFO  com.oracle.glcm.patch.auto.db.util.BootstrapHelper - indexOfRemote: -1 2020-07-24 15:51:46,873 INFO  com.oracle.glcm.patch.auto.db.util.BootstrapHelper - currentUser: oracle 2020-07-24 15:51:46,923 INFO  com.oracle.glcm.patch.auto.db.util.BootstrapHelper - indexOfRemote: -1 2020-07-24 15:51:46,923 INFO  com.oracle.glcm.patch.auto.db.util.BootstrapHelper - currentUser: oracle 2020-07-24 15:51:46,967 INFO  com.oracle.glcm.patch.auto.db.util.BootstrapHandler - Processing common bootstrap parameters. 2020-07-24 15:51:46,967 INFO  com.oracle.glcm.patch.auto.db.util.BootstrapHandler - Space available: 239111 MB 2020-07-24 15:51:46,985 INFO  com.oracle.glcm.patch.auto.db.util.PatchReaderUtil - Patch information is : [Patch Location: patch/31281355/] 2020-07-24 15:51:46,985 INFO  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  com.oracle.glcm.patch.auto.db.util.PatchPlatformValidator - Patch Aru id:226 2020-07-24 15:51:47,713 INFO  com.oracle.glcm.patch.auto.db.util.PatchPlatformValidator - Platform Aru id:226 2020-07-24 15:51:47,715 INFO  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  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  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  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  oracle.glcm.opatch.common.impl.PatchFactoryImpl - Registering:SYSTEM_PATCH:oracle.glcm.opatch.common.impl.SystemPatch 2020-07-24 15:51:47,785 INFO  oracle.glcm.opatch.common.impl.PatchFactoryImpl - Registering:COMPOSITE_PATCH:oracle.glcm.opatch.common.impl.CompositePatch 2020-07-24 15:51:47,785 INFO  oracle.glcm.opatch.common.impl.PatchFactoryImpl - Registering:SINGLETON_PATCH:oracle.glcm.opatch.common.impl.SingletonPatch 2020-07-24 15:51:47,792 INFO  oracle.glcm.opatch.common.impl.PatchFactoryImpl - Singleton patch not found 2020-07-24 15:51:47,795 INFO  oracle.glcm.opatch.common.impl.PatchFactoryImpl - Composite patch NOT found 2020-07-24 15:51:47,796 INFO  oracle.glcm.opatch.common.impl.PatchFactoryImpl - System patch NOT found 2020-07-24 15:51:47,796 SEVERE  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  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  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  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.
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.
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:
Hence, unfortunately “applyRU” does not work on the MS Windows platform.
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
- LinkedIn: Upgrade and apply latest RU at the same time – by Anil Nair (July 24, 2020)
- Patching all my environments with the July 2020 Patch Bundles
- Do we offer patched Gold Images already?
- Recorded Upgrade Seminars 2020 – 4 Session – Upgrade, Patching, Performance, Multitenant
- Oracle Software Delivery Cloud “eDelivery”
- Oracle Database Software Download on oracle.com
- Oracle Documentation 18c: Apply patches during an installation
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.
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!
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?
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 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.
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 ?
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.
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 ?
no, having the fix in an environment where you don’t have an MSWIN1252 PDB does not harm or hurt.
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?
Not yet – I’m “allergic” to OJVM (just kidding) 🙂
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
Please try it out, Jeffrey, I haven’t yet.
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.
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.
I don’t think that this works on Windows as well. And I haven’t tried other Unix ports.
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 ?
Yes, of course – that is the idea. You provide a new home with this method, and then you shutdown/startup in the new home, and you run datapatch.
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
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.
Thanks for this hint, Sunil!!
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 22.214.171.124.25 is buggy
– opatch 126.96.36.199.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
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.
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:
# rm -rf $NewHome
# 19c Base
mkdir -p $NewHome
unzip -o /install/sw/oracle/Software/Oracle19/Release/V982063-01_LINUX.X64_193000_Database.zip
# Patchset 19.12
mkdir -p $NewHome/patch/32904851
unzip -o /install/sw/oracle/Software/Oracle19/RU/1912/p32904851_190000_Linux-x86-64.zip
# OPatch 188.8.131.52.27
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*
# Install and patch
./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 184.108.40.206.27 is not the problem, where could I find some more information?
I can provide the original layout 😉
I need to see what has failed – with “opatch command failed while applying the patch” I can’t say anything useful.
How about the installer log at this point?
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: 220.127.116.11.28
Logs does not contain any errors…
reminder to myself: -applyRu is not the same as -applyRU 😉
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/18.104.22.168
New OH: /u01/app/oracle/product/22.214.171.124
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/126.96.36.199) that points to the current OH (e.g. /u01/app/oracle/product/188.8.131.52)? So whenever I patch, I just update the link….
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.
Recently I encountered an issue while installing 19c Grid (184.108.40.206) and applying July CPU on top of it using 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?
I wipe out the folder, and it gets recreated when you unzip the newest opatch.
That is at least what I do all the time:
I am receiving a very strange behavior when trying to install the 220.127.116.11.0 software onto a system that already has a 18.104.22.168 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.
whenever I saw such issues, it had to do with the LOCALE.
Have you checked with Oracle Support?
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?
I agree – this looks strange – maybe something in the environment?
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.