Kbase 17353: Shared Memory and Semaphore Ids stored in Master Block
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
4/14/2000 |
|
Shared Memory and Semaphore Ids stored in Master Block
As of 8.0B the shared memory and semaphore id's are stored in the
master block. In 8.0B, the system ftok() function was no longer used
to generate shm and sem ids (refer kbase 17251). Shm and sem id's are
now requested with a generic unique key which tells the system only
to provide unique id's or else fail. This required that we store the
shm and sem id's for the database in the master block in order to
provide a safe, known location for clients to find the id's. These
holders in the master block are cleared as part of normal shutdown.
In the case of a crash, the next process which tries to open the
database will read these values, to see if they still exist on the
system. If they are, it will see if the shared memory is still in use
(it is a check which looks to see if any processes are still attached
to the shared memory). If no processes are still attached, then the
"old" shared memory and semaphore set is cleaned up and the holders
in the master block are reset. If there are still processes attached
to shared memory, the restart fails in order to protect the integrity
of the database. Eventually, the processes attached to the shared
memory detect the death of the server, and disconnect from the db and
shared memory.
If the shared memory segments are still in use, you will see error
1260, followed by error 551.
In order to restart the database, you should either wait until the
shared memory is released by the processes still connected to it, or
else remove the shm and sem ids from the master block of the database.
Refer kbase 15912 for information on checking the shared memory
segments.
Possible ways of removing the shm and seg ids from the master block.
- truncating the bi file(V8.O and above)
- prorest the database (V8.2 and above)
- prostrct repair (V8.2 and above)
Note: The prostrct repair can be used on a single volume database
by simple typing "prostrct repair dbname" with no structure
file available.
Progress Software Technical Support Note # 17353