UNIX for Dummies Questions & Answers

Hello All,

can someone clarify finally what are the kernel parameter settings
for ORACLE9i on SOLARIS9 ?

the following first part is copy paste from the sun's web rquirements
page for the installation


Kernel Parameter
Setting
Purpose
SEMMNI
100
Defines the maximum number of semaphore sets in the entire system.
SEMMNS
1024
Defines the maximum semaphores on the system. This setting is a
minimum recommended value, for initial installation only.

The SEMMNS parameter should be set to the sum of the
PROCESSES parameter for each Oracle database, adding the largest
one twice, and then adding an additional 10 for each database.
SEMMSL
256
Defines the minimum recommended value, for initial installation
only.
SHMMAX
4294967295
Defines the maximum allowable size of one shared memory segment.

4 GB = 4294967295
SHMMIN
1
Defines the minimum allowable size of a single shared memory
segment.
SHMMNI
100
Defines the maximum number of shared memory segments in the
entire system.
SHMSEG
10
Defines the maximum number of shared memory segments one
process can attac


AND THE FOLLOWING PART IS copy paste of another INSTALLATION GUIDE FOR ORACLE
VERSION 9.2..0.1.0
This is what they say:

Add or modify the following parameters, using any higher val
ues if they
already exist on your system. These settings can be placed at the end of the file.

set semsys:seminfo_semmni=100
set semsys:seminfo_semmns=1024
set semsys:seminfo_semmsl=256
set shmsys:shminfo_shmmax=4294967295
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=100
set shmsys:shminfo_shmseg=10


Please i will appreciate your time and help if you
can explain what are the right setings and format.

thanks,

Normally you don't tune the kernal for Solaris. It should already be set for it to run correctly. Following the Oracle recommended parameters is also normal to do for setting up Oracle (or any other SQL database) on a SUN server. The only parameter I would disagree with is the following:

set shmsys:shminfo_shmmax=4294967295

Normally in our shop we give 80% to 90% of the memory not the whole thing. More of a 'just in case' way of thinking than it being a scientific tested theory. Realize that Oracle is saying "give it all" and it will use it...so what's left for the OS? Sybase does the same and we do the same to it too. 80-90% but not the whole ball of wax.

I don't know exactly what you are looking for but this may help a bit.

SEMMNI - Processes that use semaphores often group all their semaphores together in a set so they can manage them as 1 unit. Sometimes processes will have many sets, but often they only have one. If I remember correctly on Sun, if you request a semaphore you must put it in a set. In other words you cannot have a semaphore and no semaphore set. So semmni defines how many sets the system can allocate at one point in time.

SEMMNS - Here is a very bad joke we have at work: What is a Semaphore? Haulin' stuff. I know it's bad. Really a semaphore is used to ensure your process is the only process updating a piece of data. This is to ensure you and I don't both try to update the same data at the same time. Who would win? SEMMNS defines how many semaphores can be allocated on the system at one time.

One value that is not mentioned below is SEMMAP. This keeps track of unused semaphores. This could cause potential problems for you if you have a high SEMMNS value. Think of semaphores as being resident in one continuous memory space. If Process A requests a semaphore, a chunk of this space is broken off and given to Process A. When Process A is done, in theory it gives the semaphore back to the OS. This isn't always true though. Do an ipcs -a and look for semaphores with "no entry". Anyway, when the chunk is given back to the OS, it's SEMMAP's job to keep track of the available chunks. In this case there would be 2, the one returned from Process A and the rest of the original chunk. Over time the pieces, or fragments, can become numerous. If your semmap value is set to 100 and you end up with 101 fragments, semmap drops 1 because it can only keep track of 100. You do not get that back until you reboot. You can see how this could be a problem over time. In reality, this happens very slowly or never but is something to be aware of if your process requests a semaphore and can't get one.

From memory I do not recall what SEMMSL is. Sorry.

SHMMAX is the largest size one shared memory segment can be. I haven't read the docs for Solaris 9 fully yet as I just installed it on my machine a few weeks ago. Older versions of Solaris would limit this value to 25% of your Real Memory (RAM). So if you had 1 GB of mem, set this to 4G, the largest segment that could ever be allocated on your system is 250 MB. This 25% consists of the total of ALL shared memory segments so your it is not likely you would get 250 MB for 1 process as some will probably be used by another process by the time Oracle comes up. If this is no longer the case in Solaris 9, it leaves room for the concerns RTM mentioned. If Solaris 9 still has the 25% limit, I would not worry much because you are guaranteed to have ~75% of RAM left for 'other stuff'.

SHMMIN should be left at 1. Several pieces of software I have used in the past request shared memory by requesting a segment of size 1, and then releasing it, and asking for a size of 2, etc until it gets to the size it should be. This is a bad implementation in most cases but this way the program can figure out the max segment size it can request based on the last good one it was given. If you have it set higher then 1, the program will request 1 and fail (since it must request at least the minimum). At that point the process will usually fail. I know of no practical reason to change it but others on the forum may. By the way, this is the minimum 'piece' of shared memory a process can request.

SHMMNI is the max number of shared memory segments that can exist on the box at one time. It works similar to the semaphore concept where thier is one continuous memory space for all the shared memory. In your case you are saying it is OK to break this up into no more then 100 pieces.

SHMSEG says a given process can only reques X (10 in your case) shared memory segments. For a multi-process piece of software like Oracle, it could be possible to get more since each process can have 10. Oracle in general will have 1 large one and sometimes a few smaller ones.

The examples you have look fine. You just add them to the end of the /etc/system file and reboot for them to take affect. If nothing else is running on the system you should be fine.

Hope this help someone if it does not help you.
TioTony