今天发现现场有个oracle11.0.0.2的库感觉有问题,执行任何sql语句(包括ddl)都很慢;
后来发现他的共享内存有问题,在root和oracle下都有dest的共享内存。
在metlink上搜了一下,oracle在不重启主机的情况下提供了一个解决方案。
Unable to Remove Shared Memory Segment with Status of dest (文档 ID 1319087.1) |
SYMPTOMS
Instance has been shutdown however the shared memory segment is not removed.
$ ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x6faedb68 3604484 grid 660 4096 0
0x00000000 4718597 oracle 660 17181966336 1 dest
0x00000000 4521990 oracle 660 17181966336 1 dest
0x682f74fc 4980743 oracle 660 17181966336 78
0x68449b18 5046280 oracle 660 17181966336 81
0x681a4ee0 5111817 oracle 660 17181966336 80
$ ipcrm -m 4521990
$ ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x6faedb68 3604484 grid 660 4096 0
0x00000000 4718597 oracle 660 17181966336 1 dest
0x00000000 4521990 oracle 660 17181966336 1 dest
0x682f74fc 4980743 oracle 660 17181966336 79
0x68449b18 5046280 oracle 660 17181966336 81
CHANGES
RDBMS instance shutdown failed to clean-up all active bequeath connections.
The status column for the problem shared memory segment has a flag status of 'dest'.
The flag "dest" in the status column means that SHM_DEST flag has been set for that memory segment.
Setting this flag allows the operating system to automatically clean up the shared memory segment when it is no longer used.
CAUSE
There is still an active process associated with the shared memory segment, preventing the removal via ipcrm.
SOLUTION
Identify active processes holding open files on the shared memory segment using lsof.
For each problem shared memory ID# using lsof to identify the process ->
lsof |egrep "<shmid>|COMMAND"
$ lsof |egrep "4718597|COMMAND"
oracle 1903 oracle mem REG 0,19 0 3985532
$ kill -9 1903
Re-running ipcs will show that the shared memory segment is now removed.
In the above example we only had 1 process reported.