Tag: oracle home

AutoUpgrade New Features: Create Oracle Home Path Dynamically

Some customers prefer to install Oracle homes in a path that indicates the patch level, like:

/u01/app/oracle/dbhome_1928

1928 indicates this is Oracle Database 19c with Release Update 28. If you use AutoUpgrade to create your Oracle home, you can specify that path in your config file:

patch1.target_home=/u01/app/oracle/dbhome_1928

To ease automation, AutoUpgrade can dynamically determine the target Oracle home using placeholders. After downloading the patches, it checks which Release Update it will apply.

patch1.target_home=/u01/app/oracle/dbhome_%RELEASE%%UPDATE%

Easier Patching

Take a look at this config file

global.global_log_dir=/home/oracle/autoupgrade-patching/log
global.keystore=/home/oracle/autoupgrade-patching/keystore
global.folder=/home/oracle/patch-repo
patch1.source_home=/u01/app/oracle/product/dbhome_1927
patch1.target_home=/u01/app/oracle/product/dbhome_%RELEASE%%UPDATE%
patch1.sid=FTEX
patch1.patch=RECOMMENDED
  • patch=RECOMMENDED or even patch=RU would always get the latest Release Update. At time of writing, that would be 19.28.
  • target_home contains the placeholders. After AutoUpgrade determined that 19.28 is the latest Release Update, it would dynamically determine the Oracle home path.
  • You would still need to update source_home in the config file. It will change after each run because you use out-of-place patching.

Now, you can just start AutoUpgrade every quarter:

java -jar autoupgrade.jar \
     -config FTEX.cfg \
     -patch \
     -mode deploy
  • AutoUpgrade downloads the latest Release Update and builds a new Oracle home for your – with a dynamically created path reflecting the Release Update.

Ain’t that easy?

Other Release Updates

What if you want to install an older Release Update. That works too:

patch1.target_home=/u01/app/oracle/product/dbhome_%RELEASE%_%UPDATE%
patch1.patch=RU:19.27,OPATCH

This will install the Oracle home in:

/u01/app/oracle/product/dbhome_19_27

Even Easier

Here’s another way. It requires that the environment is set correctly and works entirely without a config file.

export ORACLE_SID=FTEX
export ORACLE_HOME=/u01/app/oracle/product/19
export AU_LOG_DIR="/home/oracle/autoupgrade-patching/log_"`date +%Y%m%d_%H%M%S`
java -jar autoupgrade.jar \
     -config_values "global.global_log_dir=$AU_LOG_DIR,global.folder=/home/oracle/patch-repo,download=no,target_home=/u01/app/oracle/product/dbhome_%RELEASE%%UPDATE%,patch=RECOMMENDED" \
     -patch \
	 -mode deploy
  • AutoUpgrade takes sid and source_home from the environment variables ORACLE_SID and ORACLE_HOME.
  • Then you specify other parameters as a comma-separated list using -config_values.
  • Notice the target_home with placeholders in the long list of parameters.
  • The AutoUpgrade logging directory uses a timestamp to ensure a new one is used on each invocation.

Final Words

It’s now easier to automate creation of Oracle homes using AutoUpgrade.

Do you think this feature is useful? Do you need other replacement variables?

Leave a comment below and let me know.

Fixing AutoUpgrade PATCH111 Error On Oracle Linux 9

I’ve seen a lot of interest in the create_home mode of AutoUpgrade. It allows you to easily provision new Oracle homes and the feedback has been very positive.

A few customers reported an error during installation of an Oracle home on Oracle Linux 9.

Errors in database [create_home_1]
Stage              [OH_PATCHING]
Operation          [STOPPED]
Status             [ERROR]
Info               [Exception: PATCH111
Err message: AutoUpgradePatchingException [OPatch failed to install ...]

Digging into the referenced log file revealed:

[Jun 25, 2025 10:48:51 AM] [WARNING]OUI-67200:Make failed to invoke "/usr/bin/make -f ins_rdbms.mk javavm_refresh ORACLE_HOME=/u01/app/oracle/product/dbhome_1927 OPATCH_SESSION=apply"....'Can't locate File/Copy.pm in @INC (you may need to install the File::Copy module) (@INC contains: /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at /u01/app/oracle/product/dbhome_1927/javavm/install/update_javavm_binaries.pl line 64.
                                    BEGIN failed--compilation aborted at /u01/app/oracle/product/dbhome_1927/javavm/install/update_javavm_binaries.pl line 64.
                                    make: *** [ins_rdbms.mk:573: javavm_refresh] Error 2

The Workaround

You can avoid the problem by installing Perl before you start AutoUpgrade:

dnf -y install perl-core

Big shoutout to Martin Berger for providing a workaround.

Is My Server Affected

Use this command to test whether your server is affected:

perl -e 'use File::Copy;'

If it returns without any error or output, everything is fine. If you get an error, you must install Perl before proceeding:

perl -e 'use File::Copy;'
Can't locate File/Copy.pm in @INC (you may need to install the File::Copy module) (@INC contains: /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

Why Does It Happen

  • AutoUpgrade starts by installing the Oracle home and in some cases also applies the Release Update using the -applyRU command line parameter.

  • Next, it installs additional patches using OPatch. Some patches, like the OJVM bundle patch, requires a compilation using make. This process fails if there’s no usable Perl installation.

  • There are several MOS notes on this specific issues advising to set the PERL5LIB environment variable (Patching fails during relink , with error code 102 :: Fatal error: Command failed for target `javavm_refresh’ (Doc ID 2002334.1)).

  • To solve an unrelated issue, AutoUpgrade doesn’t always set PERL5LIB when calling OPatch and this leads to this error during the compilation.

  • We’re trying to find a smart way to handle this (without re-introducing the other issue).

To summarize, you get this error when:

  • Your operating system doesn’t have a normal Perl installation. You might have the perl executable, but not the normal modules.
  • You install the OJVM bundle patch.

The Rabbit Hole

I learned something new about Perl today. Do you dare walking down that rabbit hole with me? I’ll make it short.

  • The error from make mentions the missing Perl module, File::Copy:

    /usr/bin/make -f ins_rdbms.mk javavm_refresh ORACLE_HOME=/u01/app/oracle/product/dbhome_1927 OPATCH_SESSION=apply"....'Can't locate File/Copy.pm in @INC (you may need to install the File::Copy module)

  • A Perl module can be loaded from disk. Perl automatically attempts to find the file in the following locations:

    perl -e 'print "@INC\n"'
/usr/local/lib64/perl5/5.32
/usr/local/share/perl5/5.32
/usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib64/perl5
/usr/share/perl5

  • So, I can check these directories for the Perl module. To find the File::Copy module, I need to check in the File subdirectory for the file Copy.pm:

    ll /usr/local/lib64/perl5/5.32/File/Copy.pm
ll /usr/local/share/perl5/5.32/File/Copy.pm
ll /usr/lib64/perl5/vendor_perl/File/Copy.pm
ll /usr/share/perl5/vendor_perl/File/Copy.pm
ll /usr/lib64/perl5/File/Copy.pm
ll /usr/share/perl5/File/Copy.pm
ls: cannot access '/usr/local/lib64/perl5/5.32/File/Copy.pm': No such file or directory
ls: cannot access '/usr/local/share/perl5/5.32/File/Copy.pm': No such file or directory
ls: cannot access '/usr/lib64/perl5/vendor_perl/File/Copy.pm': No such file or directory
ls: cannot access '/usr/share/perl5/vendor_perl/File/Copy.pm': No such file or directory
ls: cannot access '/usr/lib64/perl5/File/Copy.pm': No such file or directory
ls: cannot access '/usr/share/perl5/File/Copy.pm': No such file or directory

  • The file is not found in any of the directories, so Perl will fail to load the module.

  • Had the file been found in just one location, all would be good.

Happy patching!

AutoUpgrade New Features: Install Oracle Home on Brand-New, Empty Server

You can use AutoUpgrade to install an Oracle home on a brand-new, empty server.

Previously, AutoUpgrade used an existing Oracle home to determine how to create a new Oracle home. Now, you can use config file parameters to instruct AutoUpgrade on installing the new Oracle home.

This allows you to use AutoUpgrade to prepare a new server for use with Oracle Database.

How To

Preparations

I start with a brand new Oracle Linux 8 system.

  1. This is a test system, so I disable SELinux:
    sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
reboot
    • Alternatively, follow the guidelines for SELinux in your organization.
  2. Install the preinstall package and Java (required by AutoUpgrade):
    yum -y install oracle-database-preinstall-19c
yum -y install java-1.8.0-openjdk
  3. Additional configurations like mount points and swapfile.

Install Oracle Home

  1. Download AutoUpgrade:

    wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar

  2. Create an AutoUpgrade config file called install-home.cfg:

    global.global_log_dir=/home/oracle/autoupgrade/logs
install1.patch=RU:19.27,OPATCH,OJVM,DPBP
install1.folder=/u01/app/oracle/software
install1.target_home=/u01/app/oracle/product/dbhome_1927
install1.home_settings.oracle_base=/u01/app/oracle
install1.home_settings.edition=EE
install1.home_settings.inventory_location=/u01/app/oraInventory
install1.download=no
    • I have already downloaded the base release and required patches using AutoUpgrade download mode. The files are in an NFS file share which I specify with the folder parameter.
    • I use the home_settings parameters to specify how I want to install the Oracle home. There are many other settings that I can use.

  3. I start AutoUpgrade:

    java -jar autoupgrade.jar -config install-home.cfg -mode create_home

  4. On this system, the oracle user is not allowed to sudo, so I must manually execute the root scripts:

    /u01/app/oracle/product/dbhome_1927/root.sh
/u01/app/oraInventory/orainstRoot.sh
    • AutoUpgrade prints the scripts to the console.
    • It also writes the scripts into <global_log_dir>/create_home_1/<job-no>/rootsh/rootsh.log.

  5. That’s it! I’ve now installed a new Oracle home and can move on with the creation of a listener, database, and so forth

Appendix

Installing on Microsoft Windows

You can use the same functionality on Windows.

  • You must use home_settings.account_type to specify the user that runs the Windows service. If you specify a user, then it must exist already. Although runInstaller can create the user for you, AutoUpgrade doesn’t support it.
  • You should not use home_settings.inventory_location on Windows. On Windows, the Oracle Inventory is always placed in %SYSTEM_DRIVE%\Program Files\Oracle\Inventory.

Installing Java

AutoUpgrade requires Java 8 or Java 11. It doesn’t support newer versions because the tool must be backward compatible. The latest version of AutoUpgrade still supports upgrades from Oracle Database 11g.

I recommend using Oracle Java. This is what we test and develop with, however, other Java packs should be fine as well. I tested the commands in this blog post with OpenJDK.

If you have a license for Oracle Database, you can read about using Oracle JDK/JRE in the License Guide or Oracle Java SE licensing FAQ.

How to Clone Oracle Home Without Using Clone.pl

Cloning Oracle Homes is a convenient way of getting a new Oracle Home. It’s particularly helpful when you need to patch out-of-place.

A popular method for cloning Oracle Homes is to use clone.pl. However, in Oracle Database 18c, it is deprecated.

[INFO] [INS-32183] Use of clone.pl is deprecated in this release. Clone operation is equivalent to performing a Software Only installation from the image. 
You must use runInstaller script available to perform the Software Only install. For more details on image based installation, refer to help documentation.

This Is How You Should Clone Oracle Home

You should use runInstaller to create golden images instead of clone.pl. Golden image is just another word for the zip file containing the Oracle Home.

How to Create a Golden Image

  1. First, only create a golden image from a freshly installed Oracle Home. Never use an Oracle Home that is already in use. As soon as you start to use an Oracle Home you taint it with various files and you don’t want to carry those files around in your golden image. The golden image must be completely clean.

  2. Then, you create a directory where you can store the golden image:

    export GOLDIMAGEDIR=/u01/app/oracle/goldimages
mkdir -p $GOLDIMAGEDIR

  3. Finally, you create the golden image:

    $ORACLE_HOME/runInstaller -createGoldImage \
   -destinationLocation $GOLDIMAGEDIR \
   -silent
    • If you need to exclude files, you can use -exclFiles. It accepts a wilcard, so for example you can specify -exclFiles network/admin* to exclude all files and subdirectories in a directory.

  4. The installer creates the golden image as a zip file in the specified directory. The name of the zip file is unique and printed on the console.

Check the documentation for further details.

How to Deploy from a Golden Image

  1. First, you create a directory for the new Oracle Home and unzip the golden image:
    export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_2
mkdir -p $ORACLE_HOME
cd $ORACLE_HOME
unzip -q /u01/app/oracle/goldimages/my_golden_image.zip
  2. Next, you need to install the Oracle Home. You can do it interactively:
    cd $ORACLE_HOME
./runInstaller
    Or, you can do it in silent mode:
    cd $ORACLE_HOME
./runInstaller -ignorePrereq -waitforcompletion -silent \
...

That’s it!

If you need to read further on silent installations, check out oracle-base.com.

The Oracle Database 23ai documentation has an good example of using use the new procedure.

But How about OraInst.loc?

One of the differences between clone.pl and runInstaller is that the latter does not include the file $ORACLE_HOME/oraInst.loc.

This is intentional because the file is not needed for golden image deployment. runInstaller recreates the file when you install the golden image.

One of the things listed in oraInst.loc is the location of the Oracle inventory. Either runInstaller finds the value itself, or you can specify it on the command line using INVENTORY_LOCATION=<path-to-inventory>.

You can read more about oraInst.loc in the documentation or MOS note Significance of oraInst.loc When Installing Oracle Products and Applying Patches (Doc ID 418537.1).

Naming Your Golden Image

If you want your zip file (the golden image) to have a specific name, you have two options:

  1. Rename the zip file after executing runInstaller -createGoldImage.
  2. Use the secret parameter -name, which allows you to specify a name for the zip file. To name the zip file my_golden_image.zip:
    $ORACLE_HOME/runInstaller -createGoldImage \
   ... \
   -name my_golden_image.zip

Why Is Clone.pl Deprecated?

Previously, many tools existed to do the same – clone an Oracle Home. Now, we have consolidated our resources into one tool.

From now on, there is one method for cloning Oracle Home. That is easier for everyone.

In addition, runInstaller has some extra features that clone.pl doesn’t. For instance:

  • Better error reporting
  • Precheck run
  • Multimode awareness
  • Ability to apply patches during installation

When Will It Be Desupported?

I don’t know. Keep an eye out on the Upgrade Guide, which contains information about desupported features.

However, I can see in the Oracle Database 23c documentation that clone.pl is still listed. But that’s subject to change until Oracle Database 23c is released.

Pro Tips

  • Remember, you can install patches to your golden image after it has been unzipped – as part of the installation.

  • If you clone Oracle Homes because you are doing out-of-place patching, you are on the right track. I strongly recommend always using out-of-place patching. Also, when you patch out-of-place, remember to move all the database configuration files.

  • If you clone Oracle Homes, you keep adding stuff to the same Oracle Home. Over time the Oracle Home will increase in size. The more patches you install over time, the more the Oracle Home increases in size. OPatch has functionality to clean up inactive patches from an Oracle Home. Consider running it from time to time using opatch util deleteinactivepatches. Mike Dietrich has a really good blog post about it. I also describe it in our of our previous webinars:

Appendix

Thanks to Anil Nair for pointing me in the right direction.

Further Reading

Installing Oracle Database 19c and All the Things to Put on Top

When you prepare for patching or upgrading Oracle Database 19c, you must also prepare an Oracle Home. Installing the Oracle Home is easy, but there is more to it.

Out-of-place Installation

I always use out-of-place installation. I install a new, fresh Oracle Home. I will move the databases into that Oracle Home as I upgrade or patch.

The alternative, in-place installation, leads to more downtime, is more error-prone, and makes fallback more complicated. In addition, in-place installation will gradually slow down patching; as Mike Dietrich describes in Binary patching is slow because of the inventory.

Download and Prepare Oracle Home

First, I download the base release from Oracle Software Delivery Cloud, aka e-delivery.

Find REL: Oracle Database 19.3.0.0.0 – Long Term Release, the right platform, and download.

Extract the zip file into a new Oracle Home location:

export NEW_ORACLE_HOME=<path>
mkdir -p $NEW_ORACLE_HOME
cd $NEW_ORACLE_HOME
unzip -oq /tmp/LINUX.X64_193000_db_home.zip
rm /tmp/LINUX.X64_193000_db_home.zip

Don’t run the installer yet.

Clone Existing Oracle Home

I could clone an existing Oracle Home and then just apply the new patches. But it will make me susceptible to the same issue described above about in-place patching. Plus, if you clone an Oracle Home with one-offs then you might need to roll them off before you can apply the next Release Update.

Update OPatch

OPatch is needed later on to apply patches to the new Oracle Home. Get the latest version and install it into the new Oracle Home:

rm -rf $NEW_ORACLE_HOME/OPatch
cd $NEW_ORACLE_HOME
unzip -oq /tmp/<opatch_zip_file>
rm /tmp/<opatch_zip_file>

Patches

Now, I will determine which patches to apply to the Oracle Home.

  • Start by getting the latest Release Update. I really mean the latest. I have helped too many customers with issues, only to find out the issue is already solved in a later Release Update. If your database has JAVAVM installed, then get the combo patch.
  • Review the list of important one-off patches for the specific Release Update. The list contains important fixes that haven’t made into a Release Update yet. I don’t need to get all of them, but based on my knowledge of my database, I can cherrypick those that could be relevant.
  • If I am using Data Pump, I get the Data Pump bundle patch. Data Pump fixes rarely make it into Release Updates, because they are not RAC-Rolling Installable which is a clear requirement for inclusion in Release Update.
  • If I am using GoldenGate, I get the GoldenGate bundle patch.
  • If my database uses OJVM (see appendix), I get the OJVM patch that matches the Release Update I am using. I can also get the OJVM patch as a combo patch together with the Release Update.

Unzip

Now that I have downloaded a number of zip files, I go ahead and unzip the files into separate directories. In the below example, I am using 19.16 Release Update and Data Pump bundle patch:

#Release Update 19.16.0
mkdir -p $NEW_ORACLE_HOME/patch/p34133642
cd $NEW_ORACLE_HOME/patch/p34133642
unzip -oq /tmp/p34133642_190000_Linux-x86-64.zip
rm /tmp/p34133642_190000_Linux-x86-64.zip

#Data Pump bundle patch
mkdir -p $NEW_ORACLE_HOME/patch/p34294932
cd $NEW_ORACLE_HOME/patch/p34294932
unzip -oq /tmp/p34294932_1916000DBRU_Generic
rm /tmp/p34294932_1916000DBRU_Generic

Install

Now, I can install the Oracle Home and apply all the patches in one operation. Mike has a really good description of the functionality and a demo.

I do a silent installation using a response file. Notice how I am applying the patches during the installation using -applyRU and -applyOneOffs:

export ORACLE_BASE=<path_to_oracle_base>
export ORACLE_HOME=<path_to_oracle_home>
#Path to inventory is most likely /u01/app/oraInventory
export ORA_INVENTORY=<path_to_inventory>
cd $ORACLE_HOME
./runInstaller -ignorePrereqFailure -waitforcompletion -silent \
   -responseFile $ORACLE_HOME/install/response/db_install.rsp \
   -applyRU patch/p34133642/34133642 \
   -applyOneOffs patch/p34294932/34294932 \
   oracle.install.option=INSTALL_DB_SWONLY \
   UNIX_GROUP_NAME=oinstall \
   INVENTORY_LOCATION=$ORA_INVENTORY \
   SELECTED_LANGUAGES=en,en_GB \
   ORACLE_HOME=$ORACLE_HOME \
   ORACLE_BASE=$ORACLE_BASE \
   oracle.install.db.InstallEdition=EE \
   oracle.install.db.OSDBA_GROUP=dba \
   oracle.install.db.OSBACKUPDBA_GROUP=dba \
   oracle.install.db.OSDGDBA_GROUP=dba \
   oracle.install.db.OSKMDBA_GROUP=dba \
   oracle.install.db.OSRACDBA_GROUP=dba \
   oracle.install.db.isRACOneInstall=false \
   oracle.install.db.rac.serverpoolCardinality=0 \
   oracle.install.db.config.starterdb.type=GENERAL_PURPOSE \
   oracle.install.db.ConfigureAsContainerDB=false \
   SECURITY_UPDATES_VIA_MYORACLESUPPORT=false \
   DECLINE_SECURITY_UPDATES=true

You can read more about silent installation on oracle-base.com. That’s where I got inspired from. The reponse file db_install.rsp is the default one that comes with the Oracle Home. I don’t change anything in it.

Finally, I execute root.sh as root:

$ORACLE_HOME/root.sh

AutoUpgrade

Download the latest version of AutoUpgrade, and put it into $ORACLE_HOME/rdbms/admin.

Et Voilà

That’s it. I can now use the Oracle Home to upgrade or patch my Oracle Database 19c.

When you move your Oracle Database to the new Oracle Home, be sure to move all the necessary configuration files as well.

Appendix

Patches

As if the list of patches to apply wasn’t long enough. There are even more MOS notes!

Good news is that you don’t have to go through them, as long as you stay on the latest Release Update. If you check the notes, you will see that almost all bugs are already included in a Release Update. That’s a pretty strong argument for always using the latest Release Update.

  • Things to Consider to Avoid Prominent Wrong Result Problems on 19C Proactively (Doc ID 2606585.1)
  • Things to Consider to Avoid Database Performance Problems on 19c (Doc ID 2773012.1)
  • Things to Consider to Avoid SQL Performance Problems on 19c (Doc ID 2773715.1)
  • Things to Consider to Avoid SQL Plan Management (SPM) Related Problems on 19c (Doc ID 2774029.1)

Grid Infrastructure

If Grid Infrastructure manages my database, I must remember to keep GI and database patch level in sync.

It Looks Complicated

It is a little to cumbersome. We know, and that’s why there are several initiatives to make it easier.

You could also look at Oracle Fleet Patching & Provisioning (FPP). Philippe Fierens is product manager for FPP. You can read his blog posts or reach out to him (he is a nice guy who takes every opportunity to talk about FPP).

OJVM

If your database is using OJVM, then you must also apply the OJVM patch to your Oracle Home. You can check it using:

select version, status from dba_registry where comp_id=’JAVAVM’

I have seen many databases that had OJVM installed, but it was never used. In such case, you can remove the component from your database. Then you no longer need to apply the OJVM patch to your Oracle Home. Plus it has the added benefit that it will make your upgrades faster.

Mike Dietrich has a good blog – the OJVM Patching Saga. Catchy title!