If you had to unexpectedly stop replication (UNIX), or if an unforeseen condition such as database corruption or a system problem forced you to shut down SharePlex, especially if you had to re-run ora_setup, verify that the semaphores and shared memory that SharePlex was using have been released.
This procedure shows you how to do this:
1. Look for any SharePlex processes that did not shut down, and kill them.
$ ps -ef | grep sp_
$ kill -9 PID
2. Change directories to the rim sub-directory of the SharePlex variable-data directory, then issue the od -x command for the shmaddr.loc and shstinfo.ipc files.
# od -x shmaddr.loc
0000000 0000 00e1 ed40 0000 4400 9328 0080 0000 0000020 0002 0021 0000024
# od -x shstinfo.ipc
0000000 0000 00e0 ee90 0000 4100 9328 0010 0000 0000020 0002 0020 0000024
3. Make a note of the following values:
The first 32-bit word of each of the files above reveals the hexadecimal equivalent of the ?ID? of the shared memory segment. Convert this value to decimal.
For example, in the shmaddr.loc file shown in step 2, the first word is ?0000 00e1,? which equates to a decimal value of 225. In the shstinfo.ipc file, the first word is ?0000 00e0,?, which equates to a decimal value of 224.
The third word of the shmaddr.loc and the shstinfo.ipc files reveals the hexadecimal equivalent of the ?key? of the shared memory segment and the semaphore. Each set has the same key value. Do not convert this value to decimal. For example, in the shmaddr.loc file, the third word is ?4400 9328.? In the shstinfo.ipc file, the third word is ?4100 9328.?
The fifth word of each file is the semaphore ID. Convert this value to decimal. The semaphore IDs in the examples are hex ?0002 0021? and ?0020 0020,? which in decimal are 131105 and 131104, respectively.
4. Issue the ipcs -smaa command at the UNIX command prompt to see all of the shared memory segments and semaphores. Shared memory segments are listed first
and are denoted with an ?m.? Semaphores are demoted with an ?s.?. The display looks similar to the following, but will be more extensive.
5. Verify that the shared memory IDs from the shmaddr.loc and shstinfo.ipc are in the list and that the keys match.
# ipcs -smaa
T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Shared Memory: m 22 0x41009d0f --rw-r--r-- root spadmin root spadmin 0 1048576 6517 6517 8:04:10 8:39:23 13:57:15 m 23 0x44009d0f --rw-r--r-- root spadmin root spadmin 0 8388608 6517 6517 8:04:10 8:39:23 13:57:15 m 224 0x41009328 --rw-r--r-- root staff root staff 1 1048576 10030 13299 10:13:40 10:13:40 9:53:33 m 225 0x44009328 --rw-r--r-- root staff root staff 1 8388608 10030 13299 10:13:40 10:13:40 9:53:33
T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME Semaphores: s 30 0x41009d0f --ra-ra-ra- root spadmin root spadmin 12 8:39:19 13:57:15 s 31 0x44009d0f --ra-ra-ra- root spadmin root spadmin 2 8:39:19 13:57:15 s 131104 0x41009328 --ra-ra-ra- root staff root staff 12 9:53:43 9:53:33 s 131105 0x44009328 --ra-ra-ra- root staff root staff 2 10:13:40 9:53:33
6. For each shared memory segment, verify that the value in the NATTCH column is 0. This ensures that the SharePlex processes that you killed released their memory seg-ments.
7. For the semaphores, verify that the semaphore IDs and keys match the file values.
8. As root, issue the ipcrm -m command for the ID values (224 and 225 in the examples) to remove the memory segments.
# ipcrm -m 224
# ipcrm -m 225
9. As root, issue the ipcrm -s command for the key values (131104 and 131105 in the examples) to remove the semaphores.
# ipcrm -s 131104
# ipcrm -s 131105
