Here's a little something I wrote up on memory errors that relates:
---------------------------------------------------------------
ORA-07306: sms1sg: shmget error, unable to get a shared memory segment.
This indicates a problem with shared memory so you need to clean it up. Just
killing off the background processes doesn't always do it but you "should"
be able to do this without rebooting the server using the ipcrm -m shmid
command. Here's how you do it:
Step 1. First you need to find the status of shared memory. Here's an
example:
$ ipcs -m
IPC status from /dev/kmem as of Wed Feb 21 11:19:57 2001
T ID KEY MODE OWNER GROUP
Shared Memory:
m 0 0x2fd80002 --rw------- root sys
m 1 0x41dc361e --rw-rw-rw- root root
m 2 0x4ecc0002 --rw-rw-rw- root root
m 3 0x41e0383e --rw-rw-rw- root root
m 4 0x0c6629c9 --rw-r----- root root
m 5 0x06347849 --rw-rw-rw- root root
m 48134 0xb55feaac --rw-r----- oracle oinstall
m 140296 0x67c69240 --rw-r----- oracle oinstall
m 8713 0x1a2d39d4 --rw-r----- oracle oinstall
The above shows three shared memory segments for oracle so which one needs
to be cleaned up? You don't want to remove shared memory from a running
instance!
Step 2. Run the oradebug command to determine which shared memory segment to
remove by process of elimination. The oradebug utility is not covered
(AFAIK) in any of the Oracle docs but it does have "help." Type "oradebug
help."
Step 2a. Run sqlplus on an active instance and connect as internal:
$ sqlplus internal/oracle
Step 2b. Then run oradebug:
SQL> oradebug ipc
Information written to trace file.
Step 2c. Look at the trace file generated from 2b:
The oradebug ipc command writes to the user_dump_dest. Change to that
directory and do an ls -lrt then look at the contents of the latest trace
file.
$ vi orasid_ora_4141.trc
Step 2d. Do a search on "Shmid" -this is the column header for the shared
memory segment. The number below that should correspond to one of the values
in the "ID" column which was output from the ipcs -m command above. Here's a
sample clipping from a trace file:
Dump of unix-generic realm handle `/u01/app/oracle/product/8.1.6...
Area #0 `Fixed Size' containing Subareas 0-0
Total size 0000000000010ec0 Minimum Subarea size 00000000
Area Subarea Shmid Stable Addr Actual Addr
0 0 8713 0000000080000000 0000000080000000
(Another way to match shared memory segments with instances is to look at
the ctime (creation time) in the output of ipcs, and compare it to the start
time of the instance but the oradebug ipc command is more foolproof.)
Step 2e. Repeat the above steps until you've identified the orphaned shared
memory segment by process of elimination.
Step 3. Finally, clean up the mess left by the ill behaved database:
$ ipcrm -m 48134
Try starting the database and if you are still get the ORA-07306 error. If
you do then you may need to adjust the shmsys:shminfo_* and semsys:seminfo_*
kernel parameters. (Check the Oracle install manual.) Before changing kernel
parms you may want to gracefully shutdown all instances and restart them to
see if they fit into memory.
Good luck.
-----Original Message-----
Gramolini
Sent: Wednesday, March 21, 2001 9:46 AM
To: Multiple recipients of list ORACLE-L
Walt,
This is all I get:
SVRMGR> connect / as sysdba
Connected.
SVRMGR> oradebug ipc
Shared memory information written to trace file.
-------------------- Semaphores --------------------
Total number of semaphores = 200
Number of semaphores per set = 0
Number of semaphore sets = 0
Semaphore identifiers:
SVRMGR>
Where are the memory segments?
Ruth
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Wednesday, March 21, 2001 11:21 AM
> Try: oradebug ipc
>
> --Walt Weaver
> Bozeman, Montana, USA
>
> -----Original Message-----
> Sent: Wednesday, March 21, 2001 8:01 AM
> To: Multiple recipients of list ORACLE-L
>
>
> A while back someone posted a method for determining which shared memory
> segments belonged to an instance. Can someone repost that and CC me?
Thanks.
>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Steve Orr
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
