Oracle DBA Tips Corner      Return to the Oracle DBA Tips Corner.

Setting Solaris Kernel Parameter for Oracle

by Jeff Hunter, Sr. Database Administrator

Before starting the Oracle RDBMS, the Oracle kernel needs adequate shared memory and semaphores to accommodate the SGA. Server Manager (or SQL*Plus in Oracle9i or higher) will not start up the database unless the Solaris kernel is configured correctly. The Table A.1 shows in detail the Shared Memory kernel parameters while Table A.2 explains all Semaphore kernel parameters.

Parameter Name	Description	Default Value	Set By the DBA
SHMMAX	The maximum size, in bytes, of a single shared memory segment. For best performance, it should be large enough to hold the entire SGA.	1048576	YES
SHMMIN	The minimum size (in bytes) of a single shared memory segment.	1	YES
SHMSEG	The maximum number of shared memory segments that can be attached (i.e. used) by a single process.	6	YES
SHMMNI	This determines how many shared memory segments can be on the system.	100	YES
SHMMNS	The amount of shared memory that can be allocated system-wide.	???	NO
SHMALL	The total amount of shared memory available (in 4K pages). It should be significantly larger than the SGA.	???	NO

Table A.1 :Shared Memory Kernel Parameters

Together these imply some obvious limits on the SGA via:

1. No SGA may exceed SHMMAX*SHMSEG. The formula: SHMMAX * SHMSEG is the total allowable shared memory for a given process.

2. The total size of SGAs for actively running databases on a machine may not exceed SHMMAX*SHMMNI.

Ideally the SGA should fit into a single contiguous shared memory segment. Use the ipcs -b command to obtain a list of the system's current shared memory and semaphore segments, and their identification number and owner.

NOTE: Because shared memory in Solaris 2.x is dynamically loaded, when you run ipcs -b you may receive a message that the shared memory facility is not in the system. The shared memory is loaded after the Oracle Server is executed. You can check the /etc/system file to verify that the system has been configured with enough shared memory.

Parameter Name	Description	Default Value	Set By the DBA
SEMMNI	The maximum number of semaphore sets on the system.	10	YES
SEMMSL	The maximum number of semaphores per set.	25	YES
SEMMNS	The maximum number of semaphores available systemwide.	60	YES
SEMMNU	The maximum number of undo structures.	30	NO
SEMUME	The maximum number of undo entries per process.	10	NO
SEMMAP	Entries in semaphore map.	10	NO
SEMOPM	The maximum operations per semop call.	10	NO

Table A.2 : Semaphore Kernel Parameters

The maximum number of available semaphores on the system is the lesser of SEMMNS and the product (SEMMNI*SEMMSL).

Unix processes are usually written to use semaphores to coordinate access to shared resources. If a shared resource is locked, a process will suspend and wait for that resource to become available. Typically, Oracle uses one semaphore per Oracle process. Minimally, there should be more semaphores that the value of the PROCESSES parameter in init.ora. In fact, since semaphores are a systemwide resource, the kernel settings for semaphores must be adequate to handle the needs of all concurrent applications on the system. If you have multiple instances on the same server, you will need enough semaphores to support all of the instances that will be open at any one time.

Semaphores are allocated in sets, with each set having multiple semaphores and the system having multiple sets. There is a system-defined upper limit on the total number of individual semaphores. Oracle claims all the semaphores it will use at instance startup by claiming complete sets of semaphores. Any unused semaphores in the last set are not available to other processes.

NOTE: You can identify the semaphore id of an Oracle SGA (this gives semaphores, shared memory sizes also) from Server Manager using the command "oradebug ipc": % svrmgrl SVRMGRL> connect internal SVRMGRL> oradebug ipc