Shared Memory Segments

[SSP_1]

Hi Experts,

N-Class Server, hpux 11.00, oracle 8.1.7

We have approx. 12 instances of databases running on our N-Class server. I am trying to bring down one database [shutdown abort] but it's not going down and showing the error "shared memory realm doesn't exist". I have done "ipcs -moba" and killed one with ipcrm -m id [having NATCH value 0] . But still the database is not going down , even kill -9 to the processes with [LOCAL=NO] is not working.

How to find the semaphore id related to this particular instance.Pl help ..it's urgent !!

[Stefan Farrelly]

If you cant kill -9 it youre going to have to reboot.

In my opinion your NEVER remove shared memory segments or semaphores with ipcrm while a database is still up (by up I mean it still has some processes running), this can cause it to hang.

You always try to shutdown first, even with abort. If it still wont go down then kill al users processes which may be connected to the db first (use lsof to identify) then try a normal kill (15) first on all db processes, only a 9 as a last resort.

[twang]

I had the same issue before. Ended up being the oracle_home setting in my tnsnames.ora file:
(CONNECT_DATA =
(SID = ORCL) (SERVER = DEDICATED)
(ORACLE_HOME = /oraapp01/oracle/product/8.1.7)
)

[SSP_1]

HI Stefen,

How to find out the semaphore id related to a particular SID so that I can flush that off with ipcrm.

Attached is the output of ipcs -mob and the database instance name is oracleGMDV07A .

Could you pl help me out to find which are the ids related to this particular DB.

[Stefan Farrelly · Accepted solution]

add the a option to ipcs (ipcs -moab) this then adds a PID column so you can see exactly which process 'owns' that shared memory segment. You should then be able to id which database is using what and ipcrm only those you need to.

[SSP_1]

Hi Stefen,

Ran ipcs -moba , copied the output to a notepad file and search for all the pids which I got from ps -aef | grep GMDV07A | grep -v grep . But nowhere I found any of these pids.

Is reboot is the only way or still I can do something with lsof command. Attached is the output of ps -aef , these are the processes running after I issued shutdown abort , pl suggest the next step.

Thankx

[Stefan Farrelly]

The processes which opened the shared memory segment must be one of the main db daemons. You can id with;

ps -fuoracle2|grep "Jun 17"

From your output it seems only 3 possibilities, 952, 7140, 7146. If none were on your output from ipcs -moba then nothing you can do. If you cant kill -9 all processes with GMDV07A then you have to reboot.

[SSP_1]

HI Stefen ,

But what is the field for process id in the "ipcs -moba" output....is it CPID or LPID.

Pl confirm.

[Stefan Farrelly]

CPID is the creator of the shared memory segment - thats the one you want. LPID is last process to use it.

[Massimo Bianchi]

Hi,
most probable cause is not shared memory, but that you have set up incorrectly the environtment.

Before killing the instance or removing share memory segments, that is *never* advisable, check ORACLE_HOME, ORACLE_SID, TNS_ADMIN.

I know it may sound silly, but it happens often.

You sai you have many oracle instace: are all they of the same release ? You must use the correspective binary to shut it down.


Other check: is there the file $ORACLE_HOME/dbs/lk ?

If it isn't there you can incour in such behaviour.

Can you connect via tcp ? If it is yes, the db is running, so killing process in not a godd idea.


HTH,
Massimo

[SSP_1]

No Guys ,

Nothing is working, I will reboot the server , we are starting the reboot afetr n15 minutes.

First I will try to shutdown all 15 instances and do ipcrm on whatever ids are there and start the dbs. If it doesn't come up then we will reboot the server

Is this sound OK?

[Massimo Bianchi]

Hi,
since you are rebooting your server, which are your kernel parameters ?

It can be good moment to check whether your kernel parameters are sufficient for 15 oracle instnces.

For the shutdown.

First try woth your rc scripts, before the shutdown.

If they fail, your shutdown will hang the same.


First to kill: all the listener, so no new tcp connection will be possible.
Then try to abort an oracle instance at a time, and eventually kill the process of the one sacrifiable.

Maybe with the sacrifice of one instance, you will be ale to clean shutdown th others.


HTH,
Massimo