Re: When we need to remove Oracle share memory ID?

On Aug 17, 11:35 am, "newbie" <n..._at_new.com> wrote:
> Hi ,
>
> It's Oracle 9.2.0.8 on Solaris 9.
>
> 1. When do we need to remove those Oracle share memory ID to release more
> memory?
>
> 2. Do following outputs look like normal or abnormal?
>
> Thanks,
> Alan
>
> $ ipcs -am
> IPC status from <running system> as of Sun Aug 17 23:18:53 CST 2008
> T         ID      KEY        MODE        OWNER    GROUP  CREATOR   CGROUP
> NATTCH      SEGSZ  CPID  LPID   ATIME    DTIME    CTIME
> Shared Memory:
> m        100   0          --rw-r-----   oracle      dba   oracle      dba
> 27    4194304   555  9106 23:18:30 23:18:39 17:06:18
> m          1   0          --rw-r-----   oracle      dba   oracle      dba
> 27 3053453312   555  9106 23:18:30 23:18:39 17:06:18
> m          2   0          --rw-r-----   oracle      dba   oracle      dba
> 27 2281701376   555  9106 23:18:30 23:18:39 17:06:18
> m          3   0          --rw-r-----   oracle      dba   oracle      dba
> 27 3422552064   555  9106 23:18:30 23:18:39 17:06:18
> m          4   0x9751468  --rw-r-----   oracle      dba   oracle      dba
> 27 3426746368   555  9106 23:18:30 23:18:39 17:06:18
>
> $ ipcs -am
> IPC status from <running system> as of Sun Aug 17 23:19:05 CST 2008
> T         ID      KEY        MODE        OWNER    GROUP  CREATOR   CGROUP
> NATTCH      SEGSZ  CPID  LPID   ATIME    DTIME    CTIME
> Shared Memory:
> m        100   0          --rw-r-----   oracle      dba   oracle      dba
> 28    4194304   555  9118 23:19:01 23:18:39 17:06:18
> m          1   0          --rw-r-----   oracle      dba   oracle      dba
> 28 3053453312   555  9118 23:19:01 23:18:39 17:06:18
> m          2   0          --rw-r-----   oracle      dba   oracle      dba
> 28 2281701376   555  9118 23:19:01 23:18:39 17:06:18
> m          3   0          --rw-r-----   oracle      dba   oracle      dba
> 28 3422552064   555  9118 23:19:01 23:18:39 17:06:18
> m          4   0x9751468  --rw-r-----   oracle      dba   oracle      dba
> 28 3426746368   555  9118 23:19:01 23:19:01 17:06:18
>
> $ ipcs -am
> IPC status from <running system> as of Sun Aug 17 23:28:50 CST 2008
> T         ID      KEY        MODE        OWNER    GROUP  CREATOR   CGROUP
> NATTCH      SEGSZ  CPID  LPID   ATIME    DTIME    CTIME
> Shared Memory:
> m        100   0          --rw-r-----   oracle      dba   oracle      dba
> 24    4194304   555  9329 23:28:33 23:28:33 17:06:18
> m          1   0          --rw-r-----   oracle      dba   oracle      dba
> 24 3053453312   555  9329 23:28:33 23:28:33 17:06:18
> m          2   0          --rw-r-----   oracle      dba   oracle      dba
> 24 2281701376   555  9329 23:28:33 23:28:33 17:06:18
> m          3   0          --rw-r-----   oracle      dba   oracle      dba
> 24 3422552064   555  9329 23:28:33 23:28:33 17:06:18
> m          4   0x9751468  --rw-r-----   oracle      dba   oracle      dba
> 24 3426746368   555  9329 23:28:33 23:28:33 17:06:18
> $

You only need to remove them when oracle has failed in some unusual manner or something like a kill -9 has occurred. In some cases you need to get rid of the shared memory and semaphore allocations.

In some cases like that as the oracle process(es) terminate they do not remove the shared memory segments created on oracle startup. ( If you have access to metalink then there's some fairly good tech notes from oracle in this area. )

It is fairly unusual anymore for that to happen but yes it can happen. You should do some experimenting on a test system with oracle and kill -9 to make sure you know how to diagnose and clear it up.

Is there just one oracle instance running on that system?

Looks like possibly the kernel parameters are not set correctly and that oracle has had to allocate muliple chunks of shared memory instead of ( more effectively ) getting it all in one chunk. Received on Sun Aug 17 2008 - 14:27:20 CDT