| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: identifying shared memory segments
Here's a little something I wrote up on memory errors that relates:
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
SVRMGR> Where are the memory segments?
Ruth
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
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: sorr_at_arzoo.com 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: ListGuru_at_fatcity.com (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).Received on Wed Mar 21 2001 - 12:35:13 CST
 |
 |