Recently I faced a very typical problem. We have an Oracle 8i on Linux installation. Last month we received one...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
more Linux server with a similar configuration and had to load Oracle on it as well. The only problem was that our Oracle CD was not working properly and hence installation was being aborted.
The solution? We just copied everyting in oracle user-id on the old machine to the new machine. It worked: Oracle was loaded and running on the new machine with the same database. Then I did the same expriment with Oracle on Unixware and Solaris (Intel) and found it to work as well.
This procedure is useful whenever a general Oracle installation is not possible due to a bad CD-ROM, bad GUI, etc. or if you want to distribute an installed Oracle to your other branch offices. Instructions for branch offices will be less complex with this approach than with a regular installation since you're sending your standard database pre-installed. PLEASE TAKE CARE OF COPYRIGHT AND LICENSING ISSUES BEFORE USING THIS TIP!
The procedure to duplicate an Oracle installation is as follows:
- Preferably shut down the Oracle database (current installation)
- On the old machine, give the command
# tar cvzf /all_oracle.tgz /home/oracle /etc/ora*This creates a compressed TAR archive of the complete Oracle user-id and Oracle-related files in /etc to the file "all_oracle.tgz". Take care to have enough space wherever you are creating this file. It is assumed that a complete Oracle installation is in /home/oracle. If you have data files in some other area, like /u01, include that too.
- Copy the file "all_oracle.tgz" to the new machine.
- Create a dba group and oracle user-id on the new machine.
- On the new machine give the command:
# tar xvzf all_oracle.tgz
- Check for uid and gid of the Oracle user. If these numbers are different, give the command:
# chown -R oracle.dba /home/oracle # chown -R root.root /etc/ora*
Loren H. writes: The process works fine, but if you are not careful, you will not be able to apply patches or upgrade the software on the server you copied the software to. Plus Oracle will not support this type of installation. I've had problems with upgrading/patch installs on an installation of this type and after talking to Oracle support they told me to reinstall the base software and apply the required patches. Therefore, I would suggest that at the very least you need to get new media if your media is having problems. That way if you do go to patch your installation and have problems you can go back to a fresh install from the media.
Tim H. writes: Some additional items that will make this a more complete procedure:
If you will ever need to run the Oracle Universal Installer on the target system to install a patcheset, upgrade Oracle, or install an additional component, you need to include the directory used for the OUI "location" file. This is "/var/opt/oracle" on all the Unix platforms that I've worked with.
If you have applications that rely on the scripts that are copied by the "root.sh" scripts, you need to include those as well. These are copied to "/usr/local/bin" on most (or all) Unix platforms, and can be identified by owner = the Oracle owner. An alternative would be to run root.sh on the target system.
Also, the described procedure may work on Linux, but on many Unix platforms (e.g. Sun, Tru64) the permissions will not be correct in $ORACLE_HOME/bin after extracting the tar file. The "set user" and "set group" premissions can be preserved by running the tar extract as root, and adding the "p" switch to the tar command (e.g. "tar xpvzf all_oracle.tgz"). $ORACLE_HOME/bin/oracle is always affected; there are some other files affected if you are running optional services like the OEM Intelligent Agent or the SNMP daemon. If the DBA doesn't have root authority on the target system, the permissions can be corrected via chmod after extracting files. On source and target systems, cd to $ORACLE_HOME/bin, pipe "ls -l" output to a file, and compare the two files to find files that need permissions adjusted.
Stuart S. writes: Agree with the approach but you should always relink all modules of Oracle after doing this.
For More Information
- Feedback: E-mail the editor with your thoughts about this tip.
- More tips: Hundreds of free Oracle tips and scripts.
- Tip contest: Have an Oracle tip to offer your fellow DBAs and developers? The best tips submitted will receive a cool prize -- submit your tip today!
- Ask the Experts: Our SQL, database design, Oracle, SQL Server, DB2, metadata, and data warehousing gurus are waiting to answer your toughest questions.
- Forums: Ask your technical Oracle questions--or help out your peers by answering them--in our active forums.
- Best Web Links: Oracle tips, tutorials, and scripts from around the Web.