A number of different errors can occur when the SUID bit is not turned on for Oracle binary when used in conjunction with Shareplex. Typical errors are ORA-1034 (see SOL6943), Read errors "Can't rename ops cache" (SOL6830), Library errors (SOL542), errors running ora_setup (SOL4671), among others.
The purpose of this solution is to explain what is meant by turning on SUID bit, in context of Oracle binary.
At times it is required that an underprivileged user must be able to execute tasks that require privileges. With the advent of UNIX long time ago, this has been made possible. When a SUID program is run, its effective UID becomes that of the owner of the executable, rather than of the user who is running it. If a program is SUID or SGID, the output of the "ls -l" command will have the "x" in the display changed to an "s". If the program is sticky, last x changes to a t. The following table illustrates this:
CONTENTS PERMISSION MEANING
---s----- SUID A process that execs a SUID program has its
effective UID set to be the UID of the programs owner.
-----s-- SGID A process that executess an SGID program has its
Changed to the programs GID. Files created by the
process can have their primary group set to the GID
as well, depending on the permissions of the
----------t sticky In some flavors of Unix this is obsolete.
The following illustrates SUID turned on as shown below for the Oracle executable:
$ ls -l oracle
-rwsr-s--x 1 oracle dba 118453200 Sep 21 2006 oracle
If the permission on Oracle executable are something other than the above and one needs the SUID bit turned on, then the command to achieve this would be:
chmod 6751 oracle
For a detailed explanation of these permissions and their implications on running of Oracle, one may find the following documents from Metalink extremely useful:
Doc ID: Note:68303.1
Doc ID: Note:1011995.6