Cloning an Oracle Home
Do you want a fast way to install Oracle with a standard tnsnames.ora file? The Oracle Universal Installer has a very fast way of cloning an Oracle home. Let me give you the steps.
- Archive your current Oracle installation via zip or tar. I tend to archive the directory of the actual home and all files and subdirectories
- Have your server setup with the required packages for your Oracle version. It also has to be the same OS. A Linux Oracle install will not work for cloning to Solaris.
- Have the dba and oinstall group created and then the oracle user will need to be created and assigned to both groups. Have oracle own the install directory as well.
- Create your profile and environment variables. The main ones are ORACLE_BASE and ORACLE_HOME. The Inventory will be created off of your ORACLE_BASE, so set this beforehand if you don’t have an Oracle Inventory.
- Upload and extract your Oracle archive.
- Use the Oracle installer to link and setup your Oracle installation.
- Run orainstRoot.sh and root.sh if required. It will tell you at the end what scripts to run.
Let me give you an overview of step 6 below. Everything else should be self explanatory.
[oracle@server ~]$ $ORACLE_HOME/oui/bin/runInstaller -silent -clone ORACLE_HOME=$ORACLE_HOME ORACLE_HOME_NAME="Ora10gR2Client" Starting Oracle Universal Installer... No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed. Preparing to launch Oracle Universal Installer from /u001/OraInstall2009-01-29_06-54-41PM. Please wait ...[oracle@server ~]$ Oracle Universal Installer, Version 10.2.0.1.0 Production Copyright (C) 1999, 2005, Oracle. All rights reserved. You can find a log of this install session at: /u001/app/oracle/oraInventory/logs/cloneActions2009-01-29_06-54-41PM.log .................................................................................................... 100% Done. Installation in progress (Thu Jan 29 18:54:50 GMT 2009) ........................................................................ 71% Done. Install successful Linking in progress (Thu Jan 29 18:54:53 GMT 2009) . 72% Done. Link successful Setup in progress (Thu Jan 29 18:55:08 GMT 2009) .................. 100% Done. Setup successful End of install phases.(Thu Jan 29 18:55:10 GMT 2009) WARNING:A new inventory has been created in this session. However, it has not yet been registered as the central inventory of this system. To register the new inventory please run the script '/u001/app/oracle/oraInventory/orainstRoot.sh' with root privileges. If you do not register the inventory, you may not be able to update or patch the products you installed. The following configuration scripts /u001/app/oracle/product/10.2/client/root.sh need to be executed as root for configuring the system. The cloning of Ora10gR2Client was successful. Please check '/u001/app/oracle/oraInventory/logs/cloneActions2009-01-29_06-54-41PM.log' for more details. [oracle@server ~]$
As you can see, it tells you what scripts to run as root. Also, make sure to update your tnsnames.ora if you need something different that what you archived with.
Michael Yakus said,
June 3, 2009 @ 12:13 pm
We’ve been using a similar technique successfully for some time now. We use the OUI and and patching to create a single code tree, a “gold home”, and then cpio/compress it into an archival area (the tar utility can’t handle some of the longer file path names). Then we use these “gold homes” to create code trees everywhere. It became SOP to keep copies by patchset and CPU release and simply migrate databases between them. This ensures consistent configuration management throughout our life-cycle servers (does anyone use that term any more?). We improve the validity of our testing, because even the Oracle binaries are exactly the same (not accounting for OS linked libraries, but we can’t always control those).
One point to make sure of is that you have installed something, anything, before you can register the new code tree. The first install creates the inventory that the clone script will need. At our shop, the first install to create the inventory is always a throw-away, we always uninstall whatever product was picked.
An issue that we ran into is that the “gold homes” tended to grow over time as we stacked CPU’s onto the original install. This was quickly solved in a Metalink note that described how to delete obsolete CPU’s.
The net effect for me personally is that I personally haven’t had to run the OUI on any of my servers for quite some time. The DBA responsible for our code trees has a working knowledge of all the patches that have been needed across the company. It also helps us maintain product licensing compliance by keeping our installs to just the standard set.
The downside of what we do may be found in Oracle 11g when we want to features that are now licensed like compression. We won’t want to pay for compression on all our servers and if it (or any other really needed product) is a pick on the OUI, having a code tree that is different than the rest puts us back in the same boat we were before.