Just for knowledge though this is opt for [Release 7.3.0 to 10.2] -
To provide an overview of shared memory and semaphores, answer common questions related to these OS resources and provide links to more detailed information.
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
To provide an overview of shared memory and semaphores, answer common questions related to these OS resources and provide links to more detailed information.
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
DETAILS
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.
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.
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:
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:
- Understand The Basic Concept Behind Semaphores
- Understand How Many Semaphores Your Oracle Instance(s) Will Attempt to Grab From The Operating System.
- 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:
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:
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.
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, Oracle9i and Oracle10g:
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:
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.
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, Oracle9i and Oracle10g:
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'.
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.
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.
- The amount of Physical Memory and Swap space available on your system.
- The kernel paramater SHMMAX.
- 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 (7.x - 10.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:
"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 (7.x - 10.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:
- Identify the shared memory segment that is 'stuck' in memory.
- Remove the 'stuck' shared memory segment using the OS command 'ipcrm'.
Example:
Find the shmid
% $ORACLE_HOME/bin/sysresv
IPC Resources for ORACLE_SID "PROD" :
Shared Memory:
ID KEY
12189717 0x7c4602e0
Semaphores:
ID KEY
41484299 0xdfc4f220
Oracle Instance alive for sid "PROD"
Linux:
% ipcrm shm 12189717
Other Unix:
% ipcrm -m 12189717
No comments:
Post a Comment