Simpler Navigation for Servers and Operating Systems
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
Showing results for 
Search instead for 
Did you mean: 

Shared Memory issue

Occasional Advisor

Shared Memory issue

I have an Oracle 32-bit database which runs on 11-HPUX, and I have a problem with the shmem being too small when I shutdown and restart the database. I error messages that there isn't a contiguous memory segment available. My question is, can I increase a setting in the Kernel which will allow me to restart the database, without having to clear up the shared memory,
either with a reboot or stopping other services on the server. I have 4GB of memory.
Rita C Workman
Honored Contributor

Re: Shared Memory issue

My question would be this...
If you have set all your semm params (semmni,semmns, semmap) correctly based on the processes being required in Oracles ~init.ora then the problem may not be the parms's could be that Oracle is not releasing the semmaphores, and that is strictly an issue how your database is being handled via Oracle/SQL.
Now for shared memory..check SHMMAX. I generally set this to 1GB (1073741824). This setting does not affect how much shared memory is need or used by Oracle or the O/S. It is used only to indicate the maximum allowable size. This does not impact the operating system kernel resources.

Some Oracle parm settings (I used 8i as example)
nflocks = 200 + sum of values in init.ora parm db_files
maxdsiz & maxdsiz_64_bit = set this value to
larger than the default for maxdsiz &maxdsiz_64, for ex. 1B (because relinking needs the space).
semmni = total of all oracle process from init.ora (round
up if I have resources I add 10 for each db then
round up)
semmns = value of semmni *2
semmap = value of semmni +2

Hope this sure made me dust off my notes.

Josee Bourget-Thuma
Frequent Advisor

Re: Shared Memory issue


If you just upgraded your O/S, make sure you relinked Oracle. I followed the Oracle manual to set the parameters and was mislead in the setting of SEMMNI. If you have access to Metalink, I spent hours on this TAR# 1327376.999. Oracle will be amending the manual. Good notes in there. Hope this helps.

Take care,
Failure is not an option.
Andy Monks
Honored Contributor

Re: Shared Memory issue

The main reasons for this occuring is :-

a) Oracle hasn't shutdown correctly and therefore hasn't removed all it's segments

b) Another application grabbing a chunk of shared memory while Oracle is down.

If it's (a) checking ipcs -m might show the culprit.

If it's (b), then you've got problems. The way the virtual memory is allocated means that if Oracle can't find what it requires contigously, then it won't start.

If your running hp-ux 11 64bit, you can use memory windows, to effectively give Oracle it's own place to put it's shared memory.
Steven Sim Kok Leong
Honored Contributor

Re: Shared Memory issue


Use ipcrm to remove any shared memory segments or semaphores used by Oracle without rebooting your server.

For shared memory segments,
# ipcrm -m shmid

For semaphores,
# ipcrm -s semid

Both the shared memory segment id (shmid) and the semaphore id (semid) can be retrieved from the output of
# ipcs -b

Changing kernel parameters would require you to reboot the system. There is no clean way out of it. In my opinion, it is simply too risky to use the adb debugger to modify the kernel already existing in memory.

Hope this helps. Regards.

Steven Sim Kok Leong
Brainbench MVP for Unix Admin
Email: Homepage:
Les Schuettpelz
Frequent Advisor

Re: Shared Memory issue

Absolutely. It never hurts to review config parms, but if the D/B ran before, it should be able to run again with the same config parameters. Going into ipcs is one way to look at the problem, but sometimes it is easier to look for oracle processes for the instance hanging around from the prior d/b shut and kill those, that will usually free up the shm segments (these should have a 'D' as the first character in the 'mode' string) that have fragmented the shm and caused the startup to fail. This can happen even when the d/b goes down clean, depending on the shutdown options/procedure. You might want to put together a kill_procs 'cleanup' procedure if your environment often has this type of problem when recycling the database.