HPUX error 12 - Not enough space

[James R. Ferguson]

Hi Anthony:

'maxdsiz' is for 32-bit processes. 'maxdsiz64' is for 64-bit processes. See here for min, max and defaults:

http://docs.hp.com/hpux/onlinedocs/os/KCparam.MaxDsiz.html

Regards!

...JRF...

[Anthony Hill]

Looking at the shmmax setting on 3 of our other machines they are also set to 17179869184.

Is this some kind of default value? If so, what effects could lowering it's value so dramatically have on the system?


Thanks Again,
Anthony.

[Andreas D. Skjervold · Accepted solution]

Hi

Just want to say something about SHMMAX.

On Oracle systems this value is usually set to amount of physical memory. This value sets the larges allowable shared memory SEGMENT.

If Oracle instance requests a shared memory segment less than SHMMAX, the segment will be less (ie the requested size) if requested larger, you'll just get more segments.

In numbers:

If SHMMAX is set to 1 GB, and your SGA is 500MB, the shared memory segment is 500MB.
If your SGA is infact 2 GB, you will get 2 memory segments 1GB each. This requires more of SHMMNI and possibly som other resources as well (don't have my book at the moment), but your SGA and Oracle still works fine.

Setting SHMMAX to a value even bigger than physical mamory will not give any effect.

The main point is that your SGA sizes makes up the size of shared memory that is used, and should not exceed the amount of physical memory (if the SGA begins to page out, you're in trouble)

And because of the fact that the SGA must not page out, the swap that is set up is infact useless (not if you're running other applications at the same time) and that's a waste of diskspace if you have a multigigabyte memory server.
What can be done is to disable swap (don't have the setting; my notebook again!), but you should have fairly good control over your processes use of memory before doing this.

Sybase, on the other hand, grabs the total amount of shared memory set in SHMMAX! This has got many sysadmins (me!) into trouble when attempting to setup both Oracle and Sybase on the same system. Then you infact have to set the SHMMAX as low as the value Sybase needs, and thus ending up with the Oracle SGA quite fragmented. But it works!

Andreas

[Scott Keller]

I found this same error in a database we have that is still using Oracle 7. A ps -ef|grep ora revealed some leftover processes running from before the shutdown. When I killed them, the startup ran fine.

[Bill Hassell]

You didn't indicate your version of Oracle. If the version is only a 32bit version, shared memory is extremely limited (less than 1Gb without changing the Oracle executables). Another problem with 32bit shared memory is that it is a shared resource with other programs so it can be fragmented, especially if programs are improperly shutdown (such as kill -9).

To see the layout (and fragmentation) of shared memory, you can download shminfo from:

ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin/programs/shminfo/

Also use: ipcs -bmop
to look at the current segments. If a process was killed improperly, all shared memory segments created by that process will not be returned to the free memory area and cannot be reused (reboot required unless you are very knowledgeable about each segment).

Now 3Gb is a fairly small amount of RAM. Oracle can perform very well when SGA is large (depending on the number of users and activities) but 3Gb total RAM will reverse the advantage of a large SGA. Make sure that you turn off the dynamic buffer cache by setting the kernel parameter bufpages to something between 102400 and 204800 (400 to 800 megs). That will free up some memory for you.

You can add a lot more swap if Oracle is a 64bit version, but page out (swapping) is a severe performance impact, as much as 50:1 to 100:1 slowdown. If you have a 64bit version of Oracle, I would increase RAM to 6Gb.