[oracle tech overview]Semaphores and Shared Memory (zt )

nomood

Semaphores and Shared Memory - An Overview
-------
To provide an overview of shared memory and semaphores, answer common questions related to these OS resources and provide links to more detailed information.

SCOPE & APPLICATION
-------------------
This document is intended for anyone who is responsible for creating or administering an Oracle Database. It is intended to compliment the semaphore and shared memory information already provided in the Oracle Installation Guides.

[NOTE:116638.1] Understanding and Obtaining Oracle Documentation

BACKGROUND
----------------------------------------------------------------------------------
Semaphores and shared memory are two very distinct sets of Operating System resources. Semaphores are a system resource that Oracle utilizes for interprocess communication and they occupy a relatively small memory space, while shared memory is utilized to contain the SGA and can garner a large portion of physical memory.
How many of these resources are available and how they are allocated is controlled by the configuration of the operating system kernel('kernel' referring to the centralized core components of the underlying operating system).
There are three OS kernel parameters that work together to limit semaphore allocation and one OS kernel paramater that dictates the maximum size of a shared memory segment.
Operating System kernel parameters generally cannot be tuned on the fly. If they are modified, the changes will not take place until the system is rebooted.
Remember also that the kernel parameters related to semaphores and shared memory   represent 'high-water' marks.  Meaning that the OS will not automatically allocate a given amount, but will allow up to that given amount to be available upon request.

When do semaphore or shared memory errors most often occur?
----------------------------------------------------------------------------------
Both semaphore or shared memory errors appear primarily at instance startup (The 'startup nomount' stage specifically). This is the only time that Oracle tries to acquire semaphores and shared memory for the instance.  Errors related to semaphores or shared memory rarely appear during normal database operations.
  The most common circumstance in which these errors occur is during the creation of a new database.  
Sometimes when an Oracle instance crashes, however, it's shared memory segments may not be released by the OS.  This limits the overall amount of shared memory available for the instance to start up again. In this case, you will need to remove those  segments manually.

How to resolve semaphore and shared memory errors:
----------------------------------------------------------------------------------
In addressing both semaphore and shared memory errors at instance startup, there are two separate areas that should be considered for reconfiguration.
  The first and most simple fix is to modify the init<sid>;.ora to reduce the number of  semaphores or the amount of shared memory Oracle will try to grab at instance startup.   
  If your situation requires that you not reduce the appropriate init<sid>;.ora parameters,
  you will have to modify the operating system kernel to allow the OS to provide more   semaphores or allow larger shared memory segments.

SEMAPHORES
======================================================================
IMPORTANT NOTE: ORACLE DOES NOT UTILIZE SEMAPHORES ON AIX OR DIGITAL/TRU64.

What kind of ORA errors are related to semaphores?         
----------------------------------------------------------------------------------         
'Out of memory' type errors are seldom related to semaphores.
Error messages which reference a 'SEMM*****' function are related to semaphores.
   
IMPORTANT NOTE: THESE ERRORS ONLY OCCUR AT INSTANCE STARTUP.

     ORA-7250  "spcre: semget error, unable to get first semaphore set."
     ORA-7279  "spcre: semget error, unable to get first semaphore set."
     ORA-7251  "spcre: semget error, could not allocate any semaphores."
     ORA-7252  "spcre: semget error, could not allocate any semaphores."
     ORA-7339  "spcre: maximum number of semaphore sets exceeded."
      
     [NOTE:115235.1] Resolving ORA-7279 or ORA-27146 errors when starting instance
   
  VERY COMMON On Oracle8i and Oracle9i:
      
     ORA-3113  "end-of-file on communication channel" at instance startup.
     ORA-27146 "post/wait initialization failed"  
      
     [NOTE:115235.1] Resolving ORA-7279 or ORA-27146 errors when starting instance

  If you want a very specific explanation of causes for the above errors, refer to:
         
     [NOTE:15566.1]  TECH Unix Semaphores and Shared Memory Explained

  However, while their exact cause varies, all these error messages indicate that
  your init<sid>;.ora is configured to grab more semaphores than the OS has available.

  If you configure your OS as indicated in the following sections, you will not
  get any of the errors indicated above.

The Basic Steps to Semaphore Success:
----------------------------------------------------------------------------------

  1.  Understand The Basic Concept Behind Semaphores
  2.  Understand How Many Semaphores Your Oracle Instance(s) Will Attempt
      to Grab From The Operating System.
  3.  Configure Your OS Kernel To Accomodate all Your Oracle Instance(s) And
      also Allow For Future Growth.

[STEP 1] How are semaphores released by the OS for use by an application?
----------------------------------------------------------------------------------

  There are 3 OS kernel parameters that work together to limit semaphore allocation.

    When an application requests
    semaphores, the OS releases them in 'sets'.  Illustrated here as 2 sets:
    +---+  +---+  
    |   |  |   |
    |   |  |   |  
    +---+  +---+

    Controlled by SEMMNI -->;OS limit on the Number of Identifiers or sets.   

  Each set contains a tunable number of individual semaphores.

    Illustrated here as 2 semaphores per semaphore set:
    +---+  +---+  
    | S |  | S |
    | S |  | S |  
    +---+  +---+

    Controlled by SEMMSL -->;The number of semaphores in an identifier or set.(Semaphore List)

    Ultimately however, the OS can limit the total number of semaphores available from the OS.
    Controlled by:
   
      SEMMNS -->; The total Number of Semaphores allowed system wide.   

  For instance:
  Let's say SEMMNI = 100000000 and SEMMSL= 100000000 while  SEMMNS=10
  Even though SEMMNI is 100000000 and SEMMSL is 100000000, the max # of semaphores
  available on your system will only be 10, because SEMMNS is set to 10.

  Inversely:
  Let's say SEMMNI = 10 and SEMMSL = 10 while  SEMMNS= 100000000000000000000000000
  Because SEMMNI is 10 and SEMMSL is 10, the max # of semaphores avail on your
  system will only be 100 or (10 X 10), despite what SEMMNS is set too.

  THIS NOTION CAN BE SUMMARIZED BY THE FOLLOWING STATEMENT:

  The max # of semaphores that can be allocated on a system will be the lesser  
  of: (semmsl * semmni) or semmns.

     On HP:
     semmsl is hardcoded to 500. [NOTE:74367.1]  HP-UX SEMMSL Kernel Parameter

     SEMMNI, SEMMSL & SEMMNS are the basic names for OS semaphore kernel parameters,
     the full name may vary depending on your OS.  Consult your OS specific Oracle
     Install guide.   

     [NOTE:116638.1] Understanding and Obtaining Oracle Documentation)

[STEP 2] How many semaphores will my Oracle instance(s) require?
----------------------------------------------------------------------------------

  With Oracle7:
     The number of semaphores required by an instance is equal to the setting the
     'processes' parameter in the init<sid>;.ora for the instance.

  With Oracle8, Oracle8i and Oracle9i:
     The number of semaphores required by an instance is equal to 2 times the
     setting of the 'processes' parameter in the init<sid>;.ora for the instance.
     Keep in mind, however, that Oracle only momentarily grabs  2 X 'processes' then
     releases half at instance startup.
     This measure was apparently introduced to ensure Oracle could not exhaust a system
     of semaphores.   

  Oracle may also grab a couple of additional semaphores per instance for internal use.
[STEP 3] Configure your OS kernel to accomodate all your Oracle instances.
----------------------------------------------------------------------------------

  There seems to be some confusion of how to deal with lack of semaphore errors.   
  The popular theory being that if Oracle cannot find enough semaphores on a system,  
  increase semmns.  This is not always the case, as illustrated in [STEP 1].

  Once you have determined your semaphore requirements for Oracle and compensated for  
  future growth, contact your System Administrator or OS vendor for assistance in  
  modifying the OS kernel.


What should I set 'semmni', 'semmsl' & 'semmns' to?
----------------------------------------------------------------------------------

  Oracle Support typically does not recommend specific values for semaphore kernel  
  parameters.  Instead, use the information provided in this document to set the  
  parameters to values that are appropriate for your operating environment.

  For more info please look at the following note :
  [NOTE:15654.1] TECH:  Calculating Oracle's SEMAPHORE Requirements


Quick fix for resolving lack of semaphore errors:
----------------------------------------------------------------------------------

  Reduce the number of semaphores Oracle requires from the OS.

  The first and most simple fix is to modify the init<sid>;.ora to reduce the number of
  semaphores or the amount of shared memory Oracle will try to grab at instance startup.

  Keep in mind, with Oracle8, we grab 2 X 'processes' then release half.
  This measure was apparently introduced to ensure Oracle could not exhaust a system
  of semaphores.   


How can I find out how my OS kernel is configured for semaphores?
----------------------------------------------------------------------------------
  The files that are used to tune kernel parameters varies depending on your Operating  
  System.  Consult your system administrator or OS vendor, because viewing the system  
  file may not show accurate information about the runtime values.

  However, an important point to remember is that if a typographical error is made
  while editing these files, the OS will defer to a default value which is usually
  to low to accomodate Oracle.  So it's a good idea to check runtime values with
  utilities like '/etc/sysdef'.


I've tuned my OS kernel parameters, but I am still having semaphore problems....
----------------------------------------------------------------------------------

  This may mean that you made a typographical error or did not rebuild your
  Operating System kernel correctly(if a typographical error is made while editing  
  these files, the OS will defer to a default value which is usually to low to
  accomodate Oracle).   

    On Solaris, check current OS kernel values with this command:
           >; /etc/sysdef|grep -i semm
           If these values do not reflect what you put in your 'system' file,
           you likely made a typographically error.

    On HP, be sure the OS kernel was rebuilt correctly and that the OS was
           booted off the correct file.  Contact your System Administrator or HP for
           more information.


How can I determine how many semaphores are currently being utilized?
----------------------------------------------------------------------------------         

  On most Unix systems, current semaphore allocation can be displayed with the  
  OS command 'ipcs -s'.

     % ipcs -s

  While good to know, this command is seldom used as part of troubleshooting semaphore
  errors.


SHARED MEMORY
==================================================================================

How is shared memory allocated by the OS?
----------------------------------------------------------------------------------

  This process varies slightly depending on Unix platform, but the basic
  premise is this:

  An application requests a given amount of contiguous shared memory from the OS.   
  The OS dictates how large of a shared memory segment it will allow with the kernel  
  parameter SHMMAX(Shared Memory Maximum). If the amount of shared memory requested  
  by the application is greater than SHMMAX, the OS may be granted the shared memory  
  in multiple segments.  Ideally, however, you want the amount requested by the  
  application to be less than SHMMAX so that the application's request can be fulfilled  
  with one shared memory segment.

  <BUG.2585697>; 817 SGA USING 3 MEMORY SEGMENTS ON DIGITAL UNIX/TRU64   

How does SHMMAX relate to my SGA?
----------------------------------------------------------------------------------

  Since the SGA is comprised of shared memory, SHMMAX can potentially limit how
  large your SGA can be and/or prevent your instance from starting.

What limits the size of my SGA?
----------------------------------------------------------------------------------

  In no particular order.
     1.  The amount of Physical Memory and Swap space available on your system.
     2.  The kernel paramater SHMMAX.
     3.  Other OS specific limitations on shared memory.

       Memory       SHMMAX       OS Limits
     +----------+ +----------+ +----------+
     |          | |          | |          |              +------+  
     |          | |          | |          |              | S    |
     |          | |          | |          |        >;     |  G   |
     |          | |          | |          |              |   A  |  
     |          | |          | |          |              +------+
     +----------+ +----------+ +----------+
  
     Some OS specific limitations are discussed in the following documents:
      
     "Oracle Administrator's Reference" available on the Oracle Install CD
         
       Additionallly:
                
           HP-UX:
                 [NOTE:77310.1] HP-UX Large SGA support for HP, Memory Windows
                 [NOTE:69119.1] HP-UX SGA Sizing Issues on HP-UX
         
           Solaris:
                  [NOTE:61896.1] SOLARIS: SGA size, sgabeg attach address and Sun  


What kind of ORA errors are related to shared memory?         
----------------------------------------------------------------------------------         

  Error Messages referencing a 'SHMM****' function are related to shared memory.  

  ORA-7306, ORA-7336, ORA-7329, ORA-7307, ORA-7337, ORA-7320, ORA-7329, ORA-7334

    VERY COMMON IN 8i:
      ORA-27100 "shared memory realm already exists"
      ORA-27102 "out of memory"
      ORA-27125 "unable to create shared memory segment" and/or "linux 43 identifier removed"
      ORA-27123 "unable to attach to shared memory segment"
      
      [NOTE:115753.1] UNIX Resolving the ORA-27123 error
      [NOTE:1028623.6] SUN SOLARIS: HOW TO RELOCATE THE SGA

What should I set 'shmmax' to?
----------------------------------------------------------------------------------

  On some Unix platforms, the Install Guide recommends specific values.  Previous
  versions of the Install Guide recommended setting SHMMAX to
  0.5 *(physical memory present in machine). Most recently it's been suggested SHMMAX
  be set to 4294967295 (4GB). This may not seem appropriate, particularly if  
  the system has considerably less physical memory available, but it does prevent
  you from having to modify your system kernel everytime a new instance is created
  or additional physical memory is added to the system.  Remember that SHMMAX is
  a high water mark, meaning that the OS will attempt to allow up to that amount
  for an application.

Quick fix for resolving lack of shared memory errors:
-----------------------------------------------------------------------------------

  NOTE: If you have never configured your OS kernel for shared memory, you cannot  
  employ this 'Quick Fix'. You will have to first configure the OS kernel.
  The amount of shared memory Oracle requests is roughly equal to the size of the SGA.
  The first and most simple fix is to modify the init<sid>;.ora to reduce the amount of
  shared memory Oracle will try to grab at instance startup.  

  This document lists the init<sid>;.ora parameters that contribute to the size  
  of the SGA:

       [NOTE:1008866.6] HOW TO DETERMINE SGA SIZE (8.0, 8i, 7.x)


My instance crashed.  When I try to restart it, I receive errors related to shared
memory. What should I do?
-----------------------------------------------------------------------------------

  This may indicate that the shared memory segment associated with the SGA of the  
  crashed instance is still in memory.  In this case it may be appropriate to  
  manually remove the segment using OS commands.

  THIS PROCESS SHOULD NOT BE ATTEMPTED UNLESS YOU FULLY UNDERSTAND THE CONCEPTS
  BEHIND IT!!!

  The basic steps are:
     1.  Identify the shared memory segment that is 'stuck' in memory.
     2.  Remove the 'stuck' shared memory segment using the OS command 'ipcrm'.

          This note describes the new 8i 'sysresv' utility that
          can be used on Solaris to associate a given ORACLE_SID with it's shared  
          memory segment(s).
.

from metalink.oracle.com
系统参数调整之一