Semaphores and Shared memory
Semaphores are a system resource that Oracle utilizes for inter-process communication (IPC) 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.
Operating System kernel parameters change can take effect only after system is rebooted.
Both semaphore and 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 appears 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, its 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.
This can be avoided:
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.
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.
On most Unix systems, current semaphore allocation can be displayed with the OS command 'ipcs -s'.
% ipcs -s
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
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.
Remember that SHMMAX is a high water mark, meaning that the OS will attempt to allow up to that amount for an application.
How to clear a stuck session:
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
Note: We can also use the ipcs command to obtain a list of the system current shared memory segments and semaphore sets, along with their identification numbers and owner. The ipcrm command can be used to clear the stuck session using the shmid.
Semaphores are a system resource that Oracle utilizes for inter-process communication (IPC) 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.
Operating System kernel parameters change can take effect only after system is rebooted.
Both semaphore and 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 appears 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, its 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.
This can be avoided:
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.
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.
On most Unix systems, current semaphore allocation can be displayed with the OS command 'ipcs -s'.
% ipcs -s
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
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.
Remember that SHMMAX is a high water mark, meaning that the OS will attempt to allow up to that amount for an application.
How to clear a stuck session:
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
Note: We can also use the ipcs command to obtain a list of the system current shared memory segments and semaphore sets, along with their identification numbers and owner. The ipcrm command can be used to clear the stuck session using the shmid.
No comments:
Post a Comment