topic Re: Contiguous shared memory for oracle in Operating System - HP-UX

Contiguous shared memory for oracle

John Eaton — Wed, 11 Sep 2002 18:58:14 GMT

I'm running oracle 7.3.4 on 10.20 with a 5 node Service Guard cluster. I tried to verify our primary DB can run on the failover node, but it would not come up, the usual error 12, not enough memory. I've searched the forums till I'm blue in the face, and the hits are all the same, shmmax, maxdsize, swap, etc. Been there, done those long ago... I know these are not the issue, as I've done this several times over the last 3 years, and we've not changed anything. (not even patches for 2 years). My DBA and I suspect that there is a contiguous memory issue. We even tested all five packages on this server at once during Service Guard implementation.
The 2 machines in question are identical T600's with 3.75GB ram. The failover server is running a QA DB with a 512mb SGA, and another 60mb used by the system. The production DB wants 1GB, 250mb less than should be available.
How can I determine if I have a problem with contiguous memory? Any easy way to 'see' how it's being used? I suspect Q4 and the kernel tables would tell me, but I'm not sure I know enough about the tables to do that.
Thanks!
John

Re: Contiguous shared memory for oracle

John Poff — Wed, 11 Sep 2002 20:02:04 GMT

Hi John,

Here is what I think is happening. In 32-bit HP-UX, your memory is divided into four 1Gb quadrants. The Oracle SGAs are part of shared memory, and shared memory is limited to quadrants 3 and 4. The last .25Gb of quadrant 4 is reserved, so essentially you can have up to 1.75 Gb of shared memory, in a 1.0Gb chunk and a 0.75Gb chunk. Now, on your failover box you are running a database with 500 Mb of shared memory. My guess is that the SGA for this database is living in quadrant 3. When you try to failover your production database and it asks for 1.0 Gb of shared memory for the SGA it fails, not because you don't really have it, but because it is spread across two quadrants. The trick is, to either get your QA instance on the failover box to use its 500 Mb SGA in quadrant 4, or else to get the production database to split up its SGA into two chunks that will fit in the two quadrants. I'm not enough of a wizard to know how to do that, but that is what I think is happening.

JP

Re: Contiguous shared memory for oracle

Ashwani Kashyap — Wed, 11 Sep 2002 23:36:53 GMT

I think john is right and if I remember correctly there was patch which would adjust the quadrants . But I don't remember now .

I saw it in the knowledge base section . If you search there with key words shared memory or semaphores , you might get it .

Re: Contiguous shared memory for oracle

Dietmar Konermann — Thu, 12 Sep 2002 06:07:11 GMT

Hi, John!

Fitting large databases into the 32bit constraints is likely to be prolematic. You should be able to find several approaches in the Forum... one of them could be to get a SHMEM_MAGIC linked version of Oracle. Then Q2 is available for shared objects also, resulting in 3.75GB.

Another approach could be setting the use_bestfit kernel global to 1.

See Patch text of PHKL_16751:

The global variable (flag) `use_bestfit' determines what
allocation policy will be used. The default setting of this
flag is 0, resulting in first-fit being used for all
allocations for shared virtual addresses. To enable the
system to use best-fit, this flag (use_bestfit) must be set
to a non-zero value (say 1) using `adb.' The value can be
set/reset at any time during system operation. The policy
that will be used is based on the current value of this
flag.

---
The adb command would look like:

echo "use_bestfit/W1" | adb -w /stand/vmunix /dev/kmem

Maybe this allocation policy could cure your problems.

Regards...
Dietmar.