Kernel Conf for Oracle SGA

[Steven Chen_1]

Hi,

We plan to have 4G ram for Oracle 8i on hp9000 64bit 11i platform. Currently we have 2g ram and the shmmax=1073741824. There is only one Oracle instance on the server.

How can we pass the 1.75G SGA limit by tuning the kernel parameters?

Any one please help.

Thanks a lot,

Steven

[Patrick Wallek · Accepted solution]

If you are running a 64-bit version of Oracle, and since this is 64-bit HP-UX, there is no 1.75GB limit. That is only applicable to 32-bit systems.

[Jeff Schussele]

Hi Steven,

You simply *can't* pass the 1.75GB 32-bit ceiling with kernel parms.
The only way to do this would be to compile the binary with the SHMEM_MAGIC switch.
Or if the binary was already compiled for EXEC_MAGIC you could chatr it to SHMEM_MAGIC and if the mem calls have mallopt() before *any* malloc() with a M_ENABLE MMAP arg then you could address up to 3.5-3.6 GB.

But realistically - for Oracle the best thing to do is upgrade to the 64-bit flavor as these techniques described above are not fully supported be Oracle, I believe.

Rgds,
Jeff

[Jean-Luc Oudart]

Steven,
When you add your memory you also have to increase shmmax parameter (one Gb at the moment) to go up to say 4Gb.
The SGA will be size with the change in your initxxx.ora file.

If you use dynamic buffer cache, don't forget to tune the parameters again once you add the eztra memory.

You only have one instance, hope you have Oracle 8i 64bits (8.1.7.4).
select * from v$version will give you the oracle version.

Regards,
Jean-Luc

[Steven Chen_1]

Thanks a lot, guys.

Jean-Luc: I am using 8174 on 64bit server. Currently I have the followings parameters set to 1073741824:

shmmax
maxdsiz
maxdxiz_64bit
maxssiz_64bit
maxtsiz
maxtsiz_64bit

I'll have your advise to change dct_min_pct or max after 4g in place accordingly.

Please tell me:

1) is setting the above parameters to 4g the way to have sga upto 4g physical ram limit? What if only 3g number?
2) is 4G digit equal to 4294967296?

Thanks a lot.

[Jean-Luc Oudart]

Steven,

Realistically, you wonâ t be using 4Gb for your RAM.
You need some RAM to run your system, your applications, for your buffer cache.
The idea is not to use the device swap area (use pseudo swap only).

The shmmax is the physical limit. It does not mean you will use it. The init.ora file is where you will configure the SGA size.

# kmtune | grep shmmax
shmmax 1024000000
This is what I have for 1Gb (I have more than one instance on my server).

Regards,
Jean-L

[Steven Chen_1]

Jean-Luc,

I will do init#.ora for sga utilization.

My point is, for kernel conf to reflect 4g ram, is it the right way to set parameters first to physical ram limit?

Stevn

[Jean-Luc Oudart]

Steven,

the kernel parameter is the HWM (high Water Mark) that will limit your SGA size as it is based on one segment.
Therefore you can set this parameter to 4Gb but have a SGA of 2.2Gb if you wish.

I read somewhere that Oracle9i was more clever (???) as it would book more than one shared memory segment is the HWM was hit !
( I still think you should stick to one segment per instance).


Jean-Luc

[Steven Chen_1]

I've talked to Oracle support, who suggested that shmmax must be set to 1G regardless of the amount of RAM on the box. The 64bit OS does not have a limit on SGA size, which can be 1/2 of RAM. There are 6 memory segments allowed on the 64bit OS box.

HP: correct this statement, if it is WRONG.

[Jeff Schussele]

Hi Steven,

Well, I'm not HP but I can tell you they ARE flat out wrong.
If you wanted advice on healthcare would you go to your auto mechanic?

For 32-bit Oracle apps, you can certainly set an shmmax of 1.75GB - but realistically you'll only be able to use 1.5-1.6GB & that's it unless you compiled or chatr's the binary. But then IF you had multiple Oracle instances, they could *each* address up to that by using memory windows. But that *only* helps with multiple SIDs.

For 64-bit OS and apps you can set an shmmax of whatever you need, but you don't want a value higher than physical RAM of course.

What Oracle is NOT telling you is that prior to the 9 version, IF you defined an shmmax value *smaller* than the SGA size they would error out & not start. NOW what Oracle will do is spawn multiple shared mem segments in values just smaller than the shmmax value & link them all together & this will cause tremendous performance penalties. Oh yes - it will run - but nowhere near optimally & of course they'll blame the OS. BUT if you defined a shmmax value large enough it WILL run optimally.

So there is NO logical reason to believe those statements. Only you & your DBAs know what the optimum shmmax value should be & you should follow *that* advice not some frontline Oracle tech who has no stake in your application's performance & probably could not care less.

My 2 cents,
Jeff