Document ID: 28433.1
Subject: MOVING ORACLE_HOME
Last Modified: 08 June 1995
Author: GBHUTANI
Introduction
------------
A working Oracle installation consists of 3 major parts:
(a) Oracle software
(b) the database, which includes the data, control and the log files
(c) correctly configured configuration files, environment variables,
and system files
Thus, if one decides to move an Oracle installation from one file system to
another or from one machine to another, one has to appropriately move and
reconfigure all the above components.
The following discussion details the issues to be kept in mind when one
decides to move the complete Oracle installation.
Some basic assumptions
----------------------
1. If you are moving the oracle instance to another machine, it is assumed
for the purpose of this discussion that the operating system on the
new machine is binary compatible to the original OS. Note that different
versions of the operating system from the same vendor might not be
completely binary compatible.
2. The Oracle instance was completely and normally shutdown before any
actions to copy/move the installtion were taken.
(a) Moving the Oracle Software
------------------------------
Following are some of the possible ways an installation of Oracle software
may be moved to a new location:
1. Changing the name of a directory that is in the ORACLE_HOME path.
2. Moving to a completely different file system on the same machine.
3. Moving to a completely different file system on a new machine.
In cases (2) and (3) above, the files on the Oracle distribution need to be
copied to the new location. One can use a recursive copy, remote copy, TAR,
CPIO or File Transfer Protocol (ftp) in BINARY mode for this purpose.
It is good idea to compare filesizes (using ls) and checksums (using sum)
after the copy to the remote location has been accomplished.
(b) Moving the Oracle Database
------------------------------
The Oracle database maintains a complete listing of the location of various
database and log files that come into play for RDBMS operations. These entries
are maintained in the Control file. Thus, a complete rehash of these entries
pointing to the new locations is critical to achieve normal RDBMS operations.
Following are the actions to be taken to appropriately change the entries
in the control file:
On the original instance, do:
$ sqldba
SQLDBA> connect internal;
SQLDBA> spool filenames.txt;
SQLDBA> select * from dba_data_files;
SQLDBA> select * from v$logfile;
The list of datafiles and logfiles for all the tablespaces should be in
'filenames.txt'.
On the new instance, do:
$ sqldba
SQLDBA> connect internal;
SQLDBA> startup mount [DBNAME];
SQLDBA> ALTER DATABASE RENAME FILE '<old path>/filename' to
'<new path>/filename';
Perform the ALTER DATABASE RENAME FILE for ALL the datafiles and logfiles
mentioned in 'filenames.txt'.
NOTE: Just in case your control files need to be re-created at the new
ORACLE_HOME because of corruption, it is a good idea to create a
trace file that includes the CREATE CONTROLFILE statement. This
trace file will come in handy if your old instance cannot be brought
up anymore.
To create the trace file:
1. sqldba
2. SQLDBA> connect internal
3. SQLDBA> alter database backup controlfile to trace
4. Change directory to <user_dump_dest>
5. "ls -lat" to see the latest trace file
6. Remove the timestamp and version lines from the top of the file
7. Remove the RECOVER statement from the file
Now, you have a script ready to recreate the control files in case
there is a need to do so.
(c) Reconfiguring all other Oracle and System-based settings
------------------------------------------------------------
1. If the new ORACLE_HOME is on the same machine, make sure the entry in
the oratab (/etc/oratab or /var/opt/oracle/oratab) file is correctly updated.
If you are moving to a new machine, either copy the file over or create a
new one. Again make sure that the ORACLE_HOME entry is correct.
Also change the ORACLE_SID, if you decide to change that as well.
NOTE: Please make sure that the ORACLE_HOME you specify contains no soft
links to other directories or file systems. Please specify the
entire ABSOLUTE path to ORACLE in ALL places.
2. Configure your initSID.ora and configSID.ora file to reflect the new
location of parameter, control, log and dump file destinations. Following
are some of the parameters to be updated. Others may need to be changed
depending on the way your system is configured:
initSID.ora: ifile
configSID.ora: control_files
background_dump_dest
log_archive_dest
db_name (if applicable)
Refer to your Oracle Server Administrator's Guide for more details.
3. If you are changing systems, make sure that the Shared Memory and Semaphore
parameters for the UNIX kernel are configured correctly. Refer to the
Oracle Installation and Configuration Guide (ICG) or the System Admin's
Guide for more details. Also make sure you have enough swap space
configured on the new system. Usually, swap space should be 2.5 to 3 times
the RAM on your system.
4. In case you are using the ORACLE_BASE (OFA) structure, you will need to
create a symbolic link (using ln), $ORACLE_HOME/dbs/initSID.ora, pointing
to the location of initSID.ora in the OFA structure, usually
$ORACLE_BASE/admin/<DB_NAME>/pfile/initSID.ora.
5. If you move to a new machine and intend to automate the instance startup
and shutdown when your machine comes up/down respetively, you will need to
configure the system startup/shutdown to process to include the new
Oracle instances.
6. Appropriately reset the following environment variables in the .profile
or .login files of the various users:
$ORACLE_HOME
$ORACLE_SID (if applicable)
$FORMS30PATH
$ORAKITPATH
$TNS_ADMIN
Refer to bulletin on "Oracle Environment Variables on Unix" (103795.387)
for more details.
7. If your $ORACLE_HOME/rdbms/lib/sysliblist has references to a library using
an absolute path, that reference might need to be changed.
8. If your makefiles have references to a library, source or include file using
an absolute path, those references might need to be changed.
9. Make sure that the new file system does not have a NO-SUID flag set.
Most systems have these flags in the /etc/fstab file. Check your System
Administrator's Guide for more details.
10.Remove/rename the user defaults file for the Oracle installer. The file
is called 'usrdfl.log' and is usually in $ORACLE_HOME/orainst. The file
may contain references to sources of certain libraries, which may now
be invalid.
11.If you are changing systems, you will need to add entries for SQL*Net
listeners in the new /etc/services file.
12.If you are using SQL*Net v2 or later, you will need to update your
SQL*Net configuration files on both, client and server sides.
The file, 'listener.ora' is used for server-side configuration. This file
is located in /etc, /var/opt/oracle or $TNS_ADMIN, and contains entries
for ORACLE_HOME, SID_NAME, HOST and PORT. These entries will need to be
updated appropriately.
The file, 'tnsnames.ora' is used for client-side configuration and lists
aliases to locate the Oracle database. If your client runs a flavor of
UNIX, this file can be found in /etc, /var/opt/oracle or is pointed to
by $TNS_ADMIN. You will need to update the HOST, PORT and SID entries
appropriately to point to the new values.
If you are using SQL*Net 2.1, use Oracle Network Manager to update the
configuration files.
13.If you are changing systems, make sure that the 'oracle' userid and the
'dba' group (or their equivalent) are created on the new system. If your
/etc/passwd and /etc/group file is yellow-paged, make sure the entries
are created on the *local* /etc/passwd and /etc/group respectively.
14.If you have written certain scripts and/or cron jobs that have ORACLE_HOME,
ORACLE_SID or any other environment variable that is due to change,
hardcoded in them, you will need to change those appropriately.
15.You will need to copy any scripts and/or cron jobs over to the new machine.
Problems to be Look Out For
---------------------------
1. Make sure there is enough disk space (using df) on the machine/filesystem
for all the software, control, data, log files etc. BEFORE you decide to
move the Oracle Installation. You can use 'du' to find out the disk
requirements of your Oracle installation.
2. In case you are changing machines, make sure enough swap space, shared
memory, semaphores have been configured. Refer to the ICG and the Sys.
Admin. Guide for your system.
3. ORA-9782: sfifi: another instance has the same database mounted
- Make sure that the original instance was shutdown normally, before the
copy to the new machine/filesystem was done.
- Make sure that the $ORACLE_HOME/dbs/sgadef<SID>.dbf file does not
exist if the database instance is down. If the file exists, simply
rename the file.
- Make sure that the environment variable $ORACLE_HOME, the ORACLE_HOME
in /etc/oratab (or /var/opt/oracle/oratab) and the ORACLE_HOME entry
in the control file (using strings <file>) is the same.
They should all be the same as the entry in the control files. If you
still get the above error after this step, make sure that there is
no symbolic link in the ORACLE_HOME path.
- If none of the above work for you, you may try to recreate the control
files. If you had not created the trace file to recreate the control
files, and if your previous instance can still be brought up, use the
"ALTER DATABASE BACKUP CONTROLFILE TO TRACE" command.
Proceed as follows:
- Bring up the original instance and do:
- ALTER DATABASE BACKUP CONTROLFILE TO TRACE
- Change directory to <user_dump_dest>
- "ls -lat" to see the latest trace file
- Edit the newly created file and comment out the lines from
the top of the file that list the version numbers and
timestamps.
- Also comment out the instruction to RECOVER the database.
- STARTUP NOMOUNT
- Run the newly edited script. That should create the control
files afresh
If its not possible to bring up the old instance to create the trace
file, use CREATE CONTROLFILE to recreate the controlfile. You will
have to figure out the names and sizes of the log and data files.
4. ORA-205: "error in identifying control file '%s'"
- Make sure that the all the control files are present where they are
supposed to be.
- Make sure they are owned by the oracle owner and the dba group.
- Make sure the permissions are appropriate all the way to the control
file(s). The permissions for the control files themselves usually are 0640.
- Make sure that the path to the controlfile is absolute and does not
contain any soft links.