Document ID:        17215.1
Subject:            ALERT: Symbolic Links can cause Database Corruption
Last Modified:      10 January   1995
Author:             RPOWELL


Versions Affected
~~~~~~~~~~~~~~~~~
   Oracle 7 Server on most Unix platforms from release 7.0.16 onwards.

Problem
~~~~~~~
   If ORACLE_HOME is set to a symbolic link it is possible to start up
   TWO Oracle instances against the same database - one using the 'real' 
   ORACLE_HOME path and one using the symbolic link. This can lead to 
   database corruption.

   The same problem can occur if ORACLE_HOME is nfs-mounted onto a path
   different to the 'real' ORACLE_HOME.

Solution
~~~~~~~~
   ORACLE_HOME should be set to the REAL absolute path of the ORACLE_HOME
   directory. It should NEVER be set to the name of a symbolic link that
   points at the 'real' ORACLE_HOME.

Already Using a Symbollic Link ?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   If you are already using a symbolic link for ORACLE_HOME make sure
   ANY DBA connection to the database will use EXACTLY the same setting
   of ORACLE_HOME as used to start the database. There should be no problem
   with this as long as ANYONE who can start the database uses EXACTLY the
   same value for ORACLE_HOME throughout.

   If you wish to change ORACLE_HOME to the 'REAL' value plan this 
   carefully so as not to miss any script where ORACLE_HOME may be set.
   To change ORACLE_HOME from a symbolic link to a the 'REAL' pathname:

      - Shutdown NORMAL any database instances
      - Check carefully that the instances have shut down
        (use a process listing to confirm no background processes exist)
      - Change ALL places where ORACLE_HOME is set (Eg: /etc/oratab, 
        users .login scripts etc.)
      - Restart the database/s using the 'real' ORACLE_HOME setting.

   Take extreme care not to leave any ORACLE_HOME set to the old value.
   Note that some platforms will not allow ORACLE_HOME to be changed
   in this way (Eg: SunOS 4.1).

Details:
~~~~~~~~
   The following is the relevant extract from the 'readmenunix.doc' file
   supplied with Oracle 7.0.16 describing changes to the generation of
   the shared memory key on Unix.

"
- The 7.0.16.4 release uses the ORACLE_SID and the ORACLE_HOME pathname to
  generate keys for shared memory segments. This new mechanism is implemented
  in order to remove shared memory access dependency on the integrity of the
  sgadef file. Different ORACLE_SID, ORACLE_HOME pair will almost always give
  distinct keys. In the extremely rare event of key collision, startup of
  Oracle instance will fail with EEXIST error, and a different ORACLE_SID,
  ORACLE_HOME pair need to be chosen.

- Restriction: the ORACLE_HOME environment variable must be set to the
  real ORACLE_HOME location or absolute pathname on its host, and NOT any
  nfs or soft-linked pathnames, even if they point to the real ORACLE_HOME.