Oracle db problem; shared mem, not owner

[Evelyn Daroga]

I am unable to start 2 out of 5 Oracle db's. The two are reporting:
ORA-27125: unable to create shared memory segment
HP-UX Error: 1: Not owner

All db's were shut down normally, and copied to another server (via mirrored devices). 3 came up ok, the other 2 report as above.

Any ideas? I have tried removing mem segments (using ipcrm), changed some sys parameters (to match the original system), ensured swap is available. No progress.

Thanks.

[Sandman!]

Since it seems like a premission problem make sure that all the Oracle binaries are owned by user oracle and group dba.

[Evelyn Daroga]

Thanks for the quick reply. All files under the ORACLE_HOME are owned by oracle:dba. All the db's run off the same code, and 3 are doing fine. It's just these 2.

[Sandman!]

Try tracing the Oracle startup with tusc and see where it abends i.e.

# tusc -s shmget

[A. Clay Stephenson]

Check that ${ORACLE_HOME}/bin/oracle has the setuid and setgid bits set.

Examine the output of ipcs -m and try to tie the shared memory segments to the database instances. You are looking for some which are owned by oracle:dba and others that are owned by someone else.

[Evelyn Daroga]

Sandman -- tusc does not appear to exist on the server.

Clay -- I've taken the other instances down, so as to have as clean an output as possible from ipcs. I also rebooted the server to clear up any old segments hanging out there. ipcs -ma currently shows:

ipcs -ma
IPC status from /dev/kmem as of Mon May 7 13:04:35 2007
T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
Shared Memory:
m 0 0x41540e17 --rw-rw-rw- root root root root 0 348 678 678 11:13:55 11:13:55 11:13:48
m 1 0x4e4c0002 --rw-rw-rw- root root root root 1 31040 678 678 11:13:51 11:13:55 11:13:48
m 2 0x415004db --rw-rw-rw- root root root root 1 8192 678 690 11:13:51 11:13:49 11:13:48
m 4611 0x00000000 D-rw-r----- root root root root 2 11384128 1864 1855 11:15:06 no-entry 11:46:10
m 4 0x06347849 --rw-rw-rw- root root root root 1 77384 1864 2020 11:15:18 11:15:04 11:15:04
m 23046 0x00280267 --rw-r--r-- root root root root 0 1048576 5148 8311 13:04:34 no-entry 11:45:44

Segments 1-4 appear to have been created at bootup, and the other two (4611, 23046) shortly after. I've removed 23046, only to have it re-appear almost immediately with a new number. 4611 is currently marked for delete, but not going away as yet. All these mem segments are owned by root, which leads me to believe (along with the times on them) that these are system processes that always have mem segments opened.

My last resort is to restore the databases from tape and hope I can get them up. But I actually ftp'd one over from the old server after a clean shutdown, but still a problem, so I'm not convinced restoring from tape will help.

Any other thoughts???

[A. Clay Stephenson]

Did you do this?
Check that ${ORACLE_HOME}/bin/oracle has the setuid and setgid bits set.

Before you start any database instances, as root, I would cd to ${ORACLE_HOME} and execute root.sh. This will fixup any modes, ownership, and group problems.

[Evelyn Daroga]

Ok, here's the protection on the oracle executable:

-rwsr-s--x 1 oracle dba 24260184 Mar 4 2003 oracle


And, here's the output of running root.sh:
------------------------------------
Running Oracle8 root.sh script...

The following environment variables are set as:
ORACLE_OWNER= oracle
ORACLE_HOME= /oracle/app/oracle/product/8.0.6
ORACLE_SID= DWEBB63
Are these settings correct (Y/N)? [Y]:

Enter the full pathname of the local bin directory [/usr/lbin]:

Checking for "oracle" user id...
ORACLE_HOME does not match the home directory for oracle.
Okay to continue? [N]: Y

Leaving common section of Oracle8 root.sh.

-----------------------------------

Apparently it doesn't like the fact that oracle's home dir is not the same as $ORACLE_HOME, although it has been that way for many years. The other db's all use the same code with no problem.

Other thoughts? I really appreciate the suggestions!

[Steven E. Protter]

Shalom,

If someone starts oracle as root, the shared memory areas are owned by root and are not accessible to other users. To clear this, you'll need to use ipcrm as root.

To prevent it, don't start and stop oracle with any other user than the user that owns the binaries. Never do anything on oracle as root.

SEP

[Evelyn Daroga]

Thanks for the thoughts, Steven. I deliberately have root NOT set up any Oracle variables, so I couldn't start the db as root without going thru the exercise of setting up the Oracle environment. I always start/stop the db's as oracle. Even so, I would think that rebooting would clear out any lingering mem segments incorrectly owned by root. Appreciate the suggestion.