Kbase 15912: How to find Shared Memory used by database proutil -C dbipcs
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
29/01/2008 |
|
Status: Verified
GOAL:
How to find Shared Memory used by database proutil -C dbipcs
GOAL:
How to find and remove invalid or orphaned Shared Memory using dbipcs and IPCRM.
FACT(s) (Environment):
UNIX
Progress/OpenEdge Versions
FIX:
In some support cases you may need to know what Shared Memory Segments are attached to Progress Databases. (For example; in the case of a database crash where the shared memory was not released and you cannot restart the database - when you are getting a 'shared memory already in use' error) In cases like this to determine what shared memory segments are used by databases use the command:
proutil -C dbipcs (notice no dbname!)
This will display all databases on system and the shared memory ID used by each as in the example below.
PROGRESS SHARED MEMORY STATUS
ID ShMemVer Seg# InUse Database
68 - - - (not PROGRESS)
100 3 0 YES /db/work5/sports
101 3 1 - /db/work5/sports
120 3 0 NO /db/work5/test
150 2 - - (unsupported shared memory version)
ID indicates the shared-memory ID.
ShMemVer specifies the shared memory version.
Seg# indicates the shared-memory segment number. One database can own more than one segment.
InUse Specifies whether the segment is in use. YES or NO are display only if the segment # is 0. All other segments show a dash(-)
Database represents full pathname to database - This column will even represent non-progress db's and different versions of progress db's ( an unsupported shared memory version (-) is another version of progress)
If InUse = NO, you can then use the UNIX command ipcrm -m (ID#), if necessary, to remove the shared memory for the database which has crashed and you wish to restart. (See the man pages on your system)
If InUse = YES and you are 100% sure that the shared memory is related to the database that you are trying to start, it may be that a process has not exited properly and is still holding onto the shared memory. You will need to determine which process is locking the memory and terminate it. To do this on UNIX you can use syntax similar to the following:
a) Use "ps -ef | grep sports" to list processes that contain the word "sports". You will need to determine whether the returned processes are indeed the correct ones. Also note that you may need to use a ps command that gives the complete process command line, otherwise some database parameters (like the database name) may be truncated and therefore the grep won't find them. (Linux = ps -auww, Solaris = /usr/ucb/ps auxww).
b) Use "lsof | grep sports" to list all processes that have file handles that contain the word "sports". You can then determine the PID to kill.
To see the amount of shared memory in use by a database, use the PROMON activity screen for that database.