topic Re: kernel parameters for oracle in Operating System - HP-UX

kernel parameters for oracle

Henk Geurts — Fri, 06 May 2005 01:48:58 GMT

hi everybody.

we run app. 30 to 35 oracle instances configured in packages in a 2 node MC/SG-cluster.

HPUX B.11.11 (11iv1)
ServiceGuard A.11.14
Oracle from 8.1 to 9.2.0.6

however our kernel parms for the semaphores are not oke when trying to run all databases on one node ...

our current semaphore parms:

kmtune |grep -i sem
sema 1 - 1
semaem 16384 - 16384
semmap 1026 - (SEMMNI+2)
semmni 1024 - 1024
semmns 32767 - 32767
semmnu 2328 - (NPROC-4)
semmsl 2048 Y 2048
semume 512 - 512
semvmx 32768 - 32768

can someone advise what they should be ?
and why?

Re: kernel parameters for oracle

Nguyen Anh Tien — Fri, 06 May 2005 02:03:50 GMT

Hi Henk
You should know what kernel parameter mean
see attached file for detail explaination
and then check this docs for how to tune it
http://docs.hp.com/en/1219/tuningwp.html
HTH
tienna

Re: kernel parameters for oracle

Henk Geurts — Fri, 06 May 2005 02:21:45 GMT

hi Tienna.
thanks for your quick reply.
i know what these parms mean , however i don't know what values i should set to be able to run all 30/35 oracle instances on one node.
so i am looking for someone who has similar configuration who can advise me in settings.
regards.

Re: kernel parameters for oracle

Isralyn Manalac_1 — Fri, 06 May 2005 02:50:48 GMT

Hi Henk,

Usually, application or database vendors would have their own recommended kernel parameter values. It is best to ask Oracle to determine what their recommended values are.

Regards,

Isralyn

Re: kernel parameters for oracle

Henk Geurts — Fri, 06 May 2005 02:55:13 GMT

Tienna
please replay again as i had submitted points
i was surprised when to see 0 points!!
i will assign points to your next replay....

Re: kernel parameters for oracle

Eric Antunes — Fri, 06 May 2005 03:34:48 GMT

To be able to run all 30/35 oracle instances on one node? Minimum memory requirements are:

32 Mb for each shared_pool_size (16 Mb for 32 bits OS) + 8Mb db_block_buffers (db_buffer_cache in Oracle 9i) for a db_block_size of 8K. So I think you'll need a minimum 50Mb SGA for each instance, wich means 2 Gb minimum physical memory.

Regards,

Eric Antunes

Re: kernel parameters for oracle

Victor BERRIDGE — Fri, 06 May 2005 03:37:11 GMT

Hi,

How many users concurent accesses? How many total users?

I would start to try with:

semaem 16384 - 16384
semmap 1026 - (SEMMNI+2) (SEMMNI+2)
semmni 1024 - 1024 6000
semmns 32767 - 32767
semmnu 2328 - (NPROC-4) 5120
semmsl 2048 Y 2048
semume 512 - 512
semvmx 32768 - 32768

All the best
Victor

Re: kernel parameters for oracle

Victor BERRIDGE — Fri, 06 May 2005 03:44:23 GMT

Now,
What makes you think you have trouble with semaphores? when you say not OK what do you mean? The 25th instance will not start?
This for me is more like you have left all the previous instances use (reserve! it may never sue all that...) up all the shared memory...

All the best
Victor

Re: kernel parameters for oracle

Darrel Louis — Fri, 06 May 2005 04:01:48 GMT

Henk,

Isn't a two node cluster too small for 30 to 35 applications?

See the following Best practices document
http://h21007.www2.hp.com/dspp/files/unprotected/database/HP3KOracle.ppt

nproc
specifies the maximum number of processes that can exist simultaneously on the system at any given time (limited by memory). May need to be increased if the server runs both the application and the database.

Make semmni equal to nproc, this will change all related semaphore kernel parameters, because this is too small.
Good Luck

Darrel

Re: kernel parameters for oracle

Henk Geurts — Fri, 06 May 2005 08:47:24 GMT

thanks to all
will increase semmni... abd
discovered that semmns is limited to 32767
Ther database parameters initSID.ora PROCESSES on the system needs to be reconsidered as now they are set to 2000 per database which implicates max 16 packages on one node....
(http://forums1.itrc.hp.com/service/forums/questionanswer.do?admit=716493758+1115386947939+28353475&threadId=856675 )
Darrel: thanks for the very usefull best practices link...