SUMMARY: [Q] What is most important UNIX kernel parameter for ORACLE

From: ora@www.co.mo.md.us
Date: Fri Apr 04 1997 - 15:23:09 CST


Thank you for so many people give me the answer. Most of the answer are still
focus on "share memory", 'semaphore". I have no comment for all the answer.
I list most of the answers people provide to me and let you decide which one
is most accuracy answer. Thank you again.

My original post:

>I have a telephone interview with ORACLE recruiter. One of the technical
>questions he asked me was "what is most important UNIX kernel parameters
>you need setup for ORACLE?". My answer was:
>
> 1. set DB_BLOCK_Size equal or multiple of UNIX I/O block size.

> 2. setup /etc/system share memory > SGA to avoid SGA be swap out from
> memory.
>
>Look like he does NOT like my answer. I would like get opinion from all
> of you. What should be the correct answer for that? Thank in advance.

==============================================================
From: Stephen Spence <sspence@mincom.com>

OK, Firstly read the question again :

"most important UNIX kernel parameters" NOT DB_BLOCK_Size which is an
oracle parameter :)

There are a number of important parameters, all of equal importance to
each other.

e.g.
    NPROC 8192
    SHMMAX 157286400
    NQUEUE 2048
    MAXUP 2048
    PTYCOUNT 512
    PERCENTBUF 40

Cheers,
Stephen

=========================================================================
>From sweh@mpn.com Thu Apr 3 01:26:05 1997

> 1. set DB_Block_size equal or multiple of I/O block sizes

Is that a kernel parameter, or a ora config option? I thought the latter...

> 2. setup /etc/system share memory size > SGA to avoid SGA to swap
> out from memory.

Not quite true, is it? I thought you needed to increase the shared memory
size because the SGA might be bigger than the maximum allowed request, not
to prevent swapping.

rgds
Stephen

=========================================================================
>From StephenH@EnerTel.nl Thu Apr 3 02:18:30 1997

The bottom line is that you haven't answered the question! All of your
answers are on tuning Oracle parameters. Look at the installation manual
for Oracle for your platform, and you'll find things like semaphore
requirements for the kernel, and shared memory requirements. These are
the sort of things that need to be tuned in an Unix kernel for a RDBMS
to run well.

Better luck next time!

Steve

======================================================================

>From zind.klaus-peter@ch.swissbank.com Thu Apr 3 02:27:05 1997

1. db_block_size is NOT a Unix kernel parameter but instead
        a parameter from the init-ora file. You must choose a blocksize
        at time of database creation, and you will not be able to change
        it later. Changing the blocksize means recreating the database
        from scratch. db_block_size for Oracle may be 2K, 4K or 8K.
        
2. if shmsys:shminfo_shmmax < SGA but your machine has enough
        physical memory the memory required for the SGA will be allocated
        in multiple shared memory segments (maximum of segments is
        shmsys:shminfo_shmseg).
        
In my opinion the most important Unix kernel parameter is
"semsys:seminfo_semmns" which gives you the maximum number of available
Semaphores. This parameter is directly related to the init-ora parameter
"processes" (and this one is again related to further init-ora parameters
like "transactions" and "sessions"). Each Oracle instance tries to allocate
at startup time as many semaphores as the init-ora parameter "processes" is
set to. The sum of the Oracle background processes and the user processes
may not exceed this limit.

If you have several instances you will need at least as many semaphores
configured in the kernel as you get when you sum up all values for the
"processes" parameter from the init-ora files of all instances. Therefore,
the "semmns" (probably means Maximum Number of Semaphores) is definitely
a limiting factor. Maybe, you won't be able to bring up a second Oracle
instance if your kernel does not provide enough free semaphores, or you won't
be able to change the "processes" parameter for an existing instance (to enable
acccess for a larger number of users).

Hope this helps and gives you some explanation.

Cheers,

=========================================================================
>From stots@elbit.co.il Thu Apr 3 05:03:26 1997

There is also the swmaphores parameters like :

*For Oracle:
set shmsys:shminfo_shmmax=8388608
set semsys:seminfo_semmni=300
set semsys:seminfo_semmns=300
set shmsys:shminfo_shmmni=140
set shmsys:shminfo_shmseg=15
set shmsys:shminfo_shmmin=1
set semsys:seminfo_semmsl=120

in the /etc/system as you know, not only the share memory size.

Stots

=========================================================================

>From rtrzaska@uk.mdis.com Thu Apr 3 05:39:13 1997

1) DB_BLOCK_SIZE is not a kernal parameter, it is an oracle
   parameter. Prefer to leave the default, especially if using
   raw partitions.
   
2) shared memory size is correct in that it MUST be greater than
   8MB, and I think the default is nearer to 4MB. the really
   critical one is shared memory max, but by the manual there are several
   shared memory and message queue parameters that need to be set (in /etc/system ).
   
   mine are:-
   
* oracle requirements
set semsys:seminfo_semmni = 70
set semsys:seminfo_semmns = 200
set semsys:seminfo_semmsl = 120
set shmsys:shminfo_shmmax = 10000000
set shmsys:shminfo_shmseg = 10
set shmsys:shminfo_shmmni = 100
 
I think the problem is that your recruiter expected you to know this since it
is heavily laboured as part of the Oracle intallation guide ( for any unix platform ).

ray

========================================================================
>From uocarroll@deagostini.co.uk Thu Apr 3 06:52:25 1997

     Hi ora@www.co.mo.md.us,
     
     In my experience and reading from manuals etc, in addition to 1,2
     (would add to 2 by saying max share mem -shmmax- (-maxdsiz- +
     -maxtsiz-)> SGA to allow oracle to start) you mention should also look
     at
     
     MAX_USERS (on hpux) to set
     max semaphores -semmap- + -semmni- + -semmns-,
     max filetable -nfile-,
     max processes -maxuprc-,
     max user files -maxfiles- + -maxfiles_lim-,
     
     
     Recruitment agents, who needs em.
     
     
     Ultan O'Carroll
     Systems Consultant
     Orbis Publishing Ltd
     uocarroll@deagostini.co.uk
     
=========================================================================
>From rsk@itw.com Thu Apr 3 07:49:32 1997

The correct answer is "One should not have to make extensive modifications
to one's kernel configuration in order to accomodate Oracle; instead,
Oracle should design and build its product so that it will function
adequately in a stock SunOS/Solaris environment."

---Rsk

==========================================================================
>From boss@netcom.com Thu Apr 3 10:05:58 1997

the ONLY kernel parameter any oracle weenie should care about is shared memory

set shmsys:shminfo_shmmax=<amt of memory Oracle server wants>

maybe he didnt' like the order you answered...or maybe he doens't know
what DB_Block_size can do for him because he's ignorant of Unix stuff.
If he's a true Dba odds are he doesn't know a whole lot about unix.

boss

==========================================================================
    I don't have the exact answer for you, but I think that you should
have said "anything to do with semaphores". The software company I work
for redistributes oracle as part their software, and thus I support
oracle installations ( via installing our software ). I know that a
oracle installation will fail if you do not have the follow kernel
variables set ( in either solaris or sunos):

SEMMNI IPC ( Inter Process Control ) maximum semaphore sets ( system
wide )
SEMMNS IPC maximum semaphores ( system wide )
SEMUME IPC maximum number of "undo" entries per process
SEMMNU IPC maximum number of "undo" structures system-wide
SHMMNI IPC maximum number of shared memory segments system-wide
SHMSIZE IPC maximum shared memory segment size (Kb) {
THIS IS IMPORTANT! }
IPCMESSAGE System V IPC message Facility
IPCSEMAPHORE System V IPC semaphore facility
IPCSHMEM System V IPC shared memory facility

    I hope these help.... If you have any other questions regarding this
please feel free to contact me directly.

Regards,

Timothy MacDonald

tim@trinicom.com

===========================================================================
>From john.darling@smtp.cnet.navy.mil Thu Apr 3 10:18:57 1997

     Ora,
     I'm not sure if the following kernel parameters are the 'most"
     important ones but they are the parameters listed in the Oracle7
     Server Installation Guide for HP 9000 Series 700/800 for Oracle
     7.3.2.2 on pages 2-3 on under the paragraph title "Configure Kernel
     Parameters for Shared Memory":
     
     SHMMAX SHMMIN SHMMNI SHMSEG SEMMNS SEMMNI
     
     R,
     John

=========================================================================
>From osorion@mis4.plk.af.mil Thu Apr 3 10:23:48 1997

Hi There,
He was probably looking for the actual parameters used in the
UNIX kernel. the parameters are: SHMAX, SHMSEG and others.
The DB_block_size has nothing to do with the kernel parameter.
And the second answer has more to do with the init.ora file
than the kernel parameters.
I think he was right!
-Nabil Osorio
 ORACLE DBA

=========================================================================
>From alexvi@ix.netcom.com Thu Apr 3 22:28:12 1997

Hi!

Well, I think the recruiter is being rather simplistic if he wants the ONE
MOST IMPORTANT kernel parameter for Oracle tuning. Kernel tuning is a
holistic art/science.

OK, now that I got that disclaimer out of the way, my choice would be either
(in 10.X) dbc_max_pct or shmmax. dbc_max_pct would be set rather low (10 ~
20%) so that Oracle could have more memory. I usually set the maximium
shared memeory segment size (shmmax) to about 75% of main memory.

Please summarize, as I think this could be a very interesting discussion.

Alex



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:50 CDT