isitdevops.com/databases

When a process runs, it grabs from the “shared memory”. There could be one or many shared memory segments by this process. The processes send messages to each other (“inter-process communication”, or IPC) and use semaphores. To display information about shared memory segments, IPC message queues, and semaphores, you can use a single command: ipcs.

The –m option is very popular; it displays the shared memory segments.

# ipcs -m
 
—— Shared Memory Segments ——–
key        shmid      owner      perms      bytes      nattch     status     
0xc4145514 2031618    oracle    660        4096       0                      
0x00000000 3670019    oracle    660        8388608    108                    
0x00000000 327684     oracle    600        196608     2          dest        
0x00000000 360453     oracle    600        196608     2          dest        
0x00000000 393222     oracle    600        196608     2          dest        
0x00000000 425991     oracle    600        196608     2          dest        
0x00000000 3702792    oracle    660        926941184  108                    
0x00000000 491529     oracle    600        196608     2          dest        
0x49d1a288 3735562    oracle    660        140509184  108                    
0x00000000 557067     oracle    600        196608     2          dest        
0x00000000 1081356    oracle    600        196608     2          dest        
0x00000000 983053     oracle    600        196608     2          dest        
0x00000000 1835023    oracle    600        196608     2          dest        

This output, taken on a server running Oracle software, shows the various shared memory segments. Each one is uniquely identified by a shared memory ID, shown under the “shmid” column. (Later you will see how to use this column value.) The “owner”, of course, shows the owner of the segment, the “perms” column shows the permissions (same as unix permissions), and “bytes” shows the size in bytes.

The -u option shows a very quick summary:

# ipcs -mu

—— Shared Memory Status ——–
segments allocated 25
pages allocated 264305
pages resident  101682
pages swapped   100667
Swap performance: 0 attempts     0 successes

The –l option shows the limits (as opposed to the current values):

# ipcs -ml
 
—— Shared Memory Limits ——–
max number of segments = 4096
max seg size (kbytes) = 907290
max total shared memory (kbytes) = 13115392
min seg size (bytes) = 1

If you see the current values at or close the limit values, you should consider upping the limit.

You can get a detailed picture of a specific shared memory segment using the shmid value. The –i option accomplishes that. Here is how you will see details of the shmid 3702792:

# ipcs -m -i 3702792
 
Shared memory Segment shmid=3702792
uid=500 gid=502 cuid=500        cgid=502
mode=0660       access_perms=0660
bytes=926941184 lpid=12225      cpid=27169      nattch=113
att_time=Fri Dec 19 23:34:10 2008 
det_time=Fri Dec 19 23:34:10 2008 
change_time=Sun Dec  7 05:03:10 2008   

Later you will an example of how you to interpret the above output.

The -s shows the semaphores in the system:

# ipcs -s
 
—— Semaphore Arrays ——–
key        semid      owner      perms      nsems    
0x313f2eb8 1146880    oracle    660        104      
0x0b776504 2326529    oracle    660        154    
… and so on … 

This shows some valuable data. It shows the semaphore array with the ID 1146880 has 104 semaphores, and the other one has 154. If you add them up, the total value has to be below the maximum limit defined by the kernel parameter (semmax). While installing Oracle Database software, the pre-install checker has a check for the setting for semmax. Later, when the system attains steady state, you can check for the actual utilization and then adjust the kernel value accordingly.

Usage for Oracle Users
How can you find out the shared memory segments used by the Oracle Database instance? To get that, use the oradebug command. First connect to the database as sysdba:

# sqlplus / as sysdba

In the SQL, use the oradebug command as shown below:

SQL> oradebug setmypid
Statement processed.
SQL> oradebug ipc
Information written to trace file.

To find out the name of the trace file:

SQL> oradebug TRACEFILE_NAME
/opt/oracle/diag/rdbms/odba112/ODBA112/trace/ODBA112_ora_22544.trc

Now, if you open that trace file, you will see the shared memory IDs. Here is an excerpt from the file:

Area #0 `Fixed Size’ containing Subareas 0-0
  Total size 000000000014613c Minimum Subarea size 00000000
   Area  Subarea    Shmid      Stable Addr      Actual Addr
      0        0 17235970 0x00000020000000 0x00000020000000
                              Subarea size     Segment size
                          0000000000147000 000000002c600000
 Area #1 `Variable Size’ containing Subareas 4-4
  Total size 000000002bc00000 Minimum Subarea size 00400000
   Area  Subarea    Shmid      Stable Addr      Actual Addr
      1        4 17235970 0x00000020800000 0x00000020800000
                              Subarea size     Segment size
                          000000002bc00000 000000002c600000
 Area #2 `Redo Buffers’ containing Subareas 1-1
  Total size 0000000000522000 Minimum Subarea size 00000000
   Area  Subarea    Shmid      Stable Addr      Actual Addr
      2        1 17235970 0x00000020147000 0x00000020147000
                              Subarea size     Segment size
                          0000000000522000 000000002c600000
… and so on …

The shared memory id has been shown in bold red. You can use this shared memory ID to get the details of the shared memory:

# ipcs -m -i 17235970

Another useful observation is the value of lpid – the process ID of the process that last touched the shared memory segment. To demonstrate the value in that attribute, use SQL*Plus to connect to the instance from a different session.

# sqlplus / as sysdba

In that session, find out the PID of the server process:

SQL> select spid from v$process
  2  where addr = (select paddr from v$session
  3     where sid =
  4        (select sid from v$mystat where rownum   5  );
 
SPID
————————
13224

Now re-execute the ipcs command against the same shared memory segment:

# ipcs -m -i 17235970
 
Shared memory Segment shmid=17235970
uid=500 gid=502 cuid=500        cgid=502
mode=0660       access_perms=0660
bytes=140509184 lpid=13224      cpid=27169      nattch=113
att_time=Fri Dec 19 23:38:09 2008 
det_time=Fri Dec 19 23:38:09 2008 
change_time=Sun Dec  7 05:03:10 2008

Note the value of lpid, which was changed to 13224, from the original value 12225. The lpid shows the PID of the last process that touched the shared memory segment, and you saw how that value changes.

The command by itself provides little value. The next command – ipcrm – allows you to act based on the output, as you will see in the next section.

 
(Extracted from oracle technet notes author Arup Nanda)