With the coming of the binary version of the installer repository (with Oracle 9 if my memory serves me well), some things changed which did not make everybody happy.
The biggest disappointment of most people: it was not supported to tar (or zip, cpio, whatever) your Oracle installation and put it in another place. This wouldn’t impact most of the Oracle professionals if patching or upgrading the Oracle home did not need the repository, or if the repository was not easy modifiable. But all patches, patch bundles and upgrades need the repository.
With Oracle version 10 (not entirely sure about that, but I think it was version 10) a clone facility was added. This slipped the attention of most Oracle professionals, including me. Now, a few versions later (version 11.2 to be exact), it gained my attention, and I realise this brings back the wonderful possibility to tar an Oracle home and use it on another place on the same system, or use it on other systems, fully supported by Oracle!
How does that work? Well, it’s fully documented in Oracle’s documentation. The documentation states you need to shutdown all instances using it, I can not think of any reason why that would be necessary (besides just being careful and prepared for the unknown).
One use I want to highlight is the use of cloning for upgrading, patching, applying CPU’s (Cummulative Patch Updates). Most people do that ‘in-place’, which means they shutdown the instances using a certain ORACLE_HOME, (backup the database obviously), apply the patch/CPU/upgrade and next upgrade the database if necessary. Maybe you disagree and say you do not do that, but this is what I encounter in almost any case “out in the field”. It’s easy to spot the problem here: if the patch/upgrade/CPU does not work for you, you got a backup of the database of the old version, but the Oracle software installation is “gone”, alias upgraded.
How about cloning your Oracle software installation (online!), upgrading the clone, and then sequentially upgrading every instance by shutting down, altering the Oracle home, upgrade the instance (if necessary), and open it using the new Oracle home? If it doesn’t work: restore your backup and use the old Oracle home. It’s also not a problem if one database needs to use a new Oracle home and the other’s do not!
How does cloning the Oracle home this work?
(this is a database example, it works differenlty for the clusterware and application server. Also, I haven’t test this with RAC. The documentation describes this, so it is possible, but this example is single instance)
Goto your Oracle home:
$ cd $ORACLE_HOME
Tar (and zip) the Oracle home (probably you encounter some errors, some files in the bin directory are set to owner ‘root’, this is alright):
$ tar czf /path/to/tarfile.tgz --exclude "*.log" --exclude "network/admin/*" --exclude "$(hostname)*" --exclude "/dbs/*" *
Create a directory for the new home:
$ mkdir -p /path/to/new/home
Untar the created tarball:
$ tar xzf /path/to/tarfile.tgz -C /path/to/new/home
Cd to the new Oracle home:
$ cd /path/to/new/home/
Cd to the clone/bin directory in the home:
./clone.pl ORACLE_HOME="/path/to/new/home" ORACLE_BASE="/path/to/base" -defaultHomeName
Here is the output of clone.pl on a testsystem: (see how clone.pl calls runInstaller!)
./runInstaller -clone -waitForCompletion "ORACLE_HOME=/oracle/db/188.8.131.52_test" "ORACLE_BASE=/oracle" -defaultHomeName -defaultHomeName -silent -noConfig -nowait
Starting Oracle Universal Installer...
Checking swap space: must be greater than 500 MB. Actual 1852 MB Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2010-07-02_04-34-52PM. Please wait ...Oracle Universal Installer, Version 184.108.40.206.0 Production
Copyright (C) 1999, 2009, Oracle. All rights reserved.
You can find the log of this install session at:
.................................................................................................... 100% Done.
Installation in progress (Friday, July 2, 2010 4:36:13 PM CEST)
............................................................................. 77% Done.
Linking in progress (Friday, July 2, 2010 4:36:40 PM CEST)
Setup in progress (Friday, July 2, 2010 4:41:23 PM CEST)
End of install phases.(Friday, July 2, 2010 4:47:18 PM CEST)
Starting to execute configuration assistants
The following configuration assistants have not been run. This can happen because Oracle Universal Installer was invoked with the -noConfig option.
The "/oracle/db/220.127.116.11_test/cfgtoollogs/configToolFailedCommands" script contains all commands that failed, were skipped or were cancelled. This file may be used to run these configuration assistants outside of OUI. Note that you may have to update this script with passwords (if any) before executing the same.
The "/oracle/db/18.104.22.168_test/cfgtoollogs/configToolAllCommands" script contains all commands to be executed by the configuration assistants. This file may be used to run the configuration assistants outside of OUI. Note that you may have to update this script with passwords (if any) before executing the same.
The following configuration scripts need to be executed as the "root" user.
To execute the configuration scripts:
1. Open a terminal window
2. Log in as "root"
3. Run the scripts
The cloning of OraHome1 was successful.
Please check '/oracle/oraInventory/logs/cloneActions2010-07-02_04-34-52PM.log' for more details.
As the clone.pl output indicates, root.sh needs to be run after the clone.pl command.