What Is Shared Memory and Semaphores
Shared memory and semaphores are two important resources for an Oracle instance on UNIX.
An instance cannot start if it is unable to allocate what it needs.
Shared memory is a memory region that can be shared
between different processes. Oracle uses shared memory for implementing the
SGA, which needs to be visible to all database sessions. Shared memory is also used in the
implementation of the SQL*Net V1 Fast driver as a means of communicating
between the application and shadow process. Each shadow process stores its PGA
in a shared memory segment. In the latter two cases, Oracle allocates the
shared memory dynamically as opposed to the allocation of the SGA, which occurs
at instance STARTUP.
Semaphores can be thought of as flags. They are
either on or off state. A process can
turn ON, the flag or turn it OFF. If the flag is already on, processes who try
to turn on the flag will sleep until the flag is off. Upon awakening, the process will reattempt to
turn the flag on, possibly succeeding or possibly sleeping again. Such behaviour allows semaphores to be used
in implementing a post-wait driver - a system where processes can wait for
events (i.e. wait on turning on a semaphore) and post events (i.e. turning of a
semaphore). This mechanism is used by
Oracle to maintain concurrency control over the SGA, since it is writeable by
all processes attached. Also, for the same reasons, use of the Fast Driver
requires additional semaphores. However,
these semaphores will be allocated dynamically instead of at instance STARTUP.
Configuring Shared Memory and Semaphores
Clear Shared Memory And Semaphore (HP-UX)
Sometimes it happens that after a crash or after an abnormal shutdown the oracle database instance does not release the shared memory or semaphores.
Error
##################################################
SQL> startup
ORA-27121: unable to determine size of shared memory segment
Error 13: Permission denied
##################################################
Cause
SHUTDOWN ABORT
CLUSTER FAILOVER
KILL PMON
Action
Shared Memory:
# ipcs -pmb | egrep 'oracle|orar12'
m 997425174 0xf5039ea8 --rw-rw---- oracle dba
m 163864 0x4c17eb4c --rw------- oracle dba
m 786457 0x00000000 --rw-rw---- orar12 dba
Clear Shared Memory
ipcrm -m <SharedMemory ID>
Semaphores:
# ipcs -s |egrep 'oracle|orar12'
s 10321961 0xd9da4e50 --ra------- oracle dba
s 77168682 0x709a05d8 --ra-ra---- oracle dba
s 2162731 0xd9da4ff0 --ra------- orar12 dba
Clear Semaphores
ipcrm -s <SemaphoreID>
Allocate More Semaphores in KERNEL Parameter File
If Oracle Database creates more segments for the instance than the number of protection keys, then increase the value of the shmmax kernel parameter.
How To identify the Semaphores for a particular Oracle Instance
Get the shared memory and semaphore IDs
In Oracle 8i
$ export ORACLE_SID=ORCL
$ svrmgrl
SVRMGR> connect internal
SVRMGR> oradebug ipc
Information written to trace file.
SVRMGR> exit
In 9i & Above
$ export LD_LIBRARY_PATH=$ORACLE_HOME/lib
$ cd $ORACLE_HOME/bin
$ sysresv
$ sysresv ORCL
IPC Resources for ORACLE_SID "ORCL" :
Shared Memory:
ID KEY
324468764 0x0f73169c
Semaphores:
ID KEY
22085675 0x13c503f0
Oracle Instance alive for sid "ORCL"
Check the Semaphores ID and compare with above
ps -ef | grep ORCL| grep LOCAL
oracle 14848 1 0 07:11:10 ? 2:05 oracleORCL (LOCAL=NO)
SQL> oradebug setospid 14848
SQL> oradebug ipc
In udump location
List of Semaphore ID as below
Number of semaphore sets: = 1
Semaphore identifiers: = 1
Semaphore List=
35684397
-------------- system semaphore information -------------
IPC status from /dev/kmem as of Tue Oct 1 14:21:45 2013
T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME
Semaphores:
s 0 0x4f20037e --ra------- root root root root 1 14:20:40 19:48:16
s 1 0x412011f3 --ra-ra-ra- root root root root 1 16:32:00 19:48:17
No comments:
Post a Comment