topic Re: Shared Memory issue in Operating System - HP-UX

Shared Memory issue

mckiers — Tue, 06 Feb 2001 18:56:40 GMT

I have an Oracle 7.3.4.5 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.

Re: Shared Memory issue

Rita C Workman — Tue, 06 Feb 2001 19:25:27 GMT

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 settings....it'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 helps....it sure made me dust off my notes.
/rcw

Re: Shared Memory issue

Josee Bourget-Thuma — Tue, 06 Feb 2001 20:36:39 GMT

Pearse,

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,
Josee

Re: Shared Memory issue

Andy Monks — Wed, 07 Feb 2001 08:01:22 GMT

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.

Re: Shared Memory issue

Steven Sim Kok Leong — Wed, 07 Feb 2001 10:18:05 GMT

Hi,

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
http://www.brainbench.com

Re: Shared Memory issue

Les Schuettpelz — Wed, 07 Feb 2001 15:49:18 GMT

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.