Re: Oracle Failed to release Shared Memory on Solaris

Chuck <ccarson_at_echeeba.com> wrote in message news:<3E80FBA5.3010800_at_echeeba.com>...
> I was cloning a database by using a recent hot backup via the following
> steps:
>
> 1) copy datafiles into correct locations
> 2) startup mount
> 3) recover database using backup controlfile until cancel
> 4) after desired archived logs are applied I type cancel
> 5) alter database open resetlogs
>
> I then did a shutdown of the instance, however, the sahred memory
> segments for oracle were not released. I was unable to startup a new
> instance not try and shutdown the previous instance again. I have to
> explictly remove the shared memory segments (using ipcrm as the oracle user)
>
> Once this was done I could start the instance back up.
>
> Just curious why this occured, and if it is related to any memory/sga
> configurations. I had just changed the hard limit for open file
> descriptors to 4096 from 1024.
>
> Thanks,
> CC

If you can reproduce, it must be an Oracle bug. If you can't, well, ask if anybody kill'ed -9 on pmon, or just keep doing ipcrm. SysV IPC is notorious in not removing shared memory segment automatically. So the programmer has to be careful making sure it's removed before the process exits. If somebody does a kill -9 on pmon, then it's not Oracle's fault since that signal can't be caught by the process to clean up the shared memory.

There shouldn't be any relationship between increasing file descriptor limit and not removing shared memory.

BTW, how many shared memory segments are for this instance? Before Solaris 8, do /usr/proc/bin/pmap [anyoracleprocess] | grep -c shmid. On Solaris 8, look at the line [ anon ] below [ heap ] (there may be another bug filed on this).

Yong Huang Received on Wed Mar 26 2003 - 13:19:49 CST