Re: Solaris Unix Shared Memory Semaphores - 3113 Problem

You wanted to know which shared memory segment belongs to which DB - *connect internal* to the databases still running normal - do the oradebug and you'll know
their shared memory segment ... at least this way you know which segments not to remove !

It looks to me your DB crashed and smon was unable to clean up it's shared memory - so any
client trying to connect through IPC fails to attach to the segment. I had this several times back in
the days of oracle 7 - not only on solaris but also on AIX ... which has a dynamic kernel (so no
fiddling around with /etc/systems and reboots :-) ) - no offense - but DA Morgan's response
reminds me of Oracle support :-)

"JustAnotherDBA" <jadba_at_bellsouth.net> wrote in message news:CmS5a.11813$1N4.3149_at_fe05.atl2.webusenet.com...
>
> "DA Morgan" <damorgan_at_exesolutions.com> wrote in message
> news:3E57E5D2.21EF6CE2_at_exesolutions.com...
> > JustAnotherDBA wrote:
> >
> > > Interesting... but, not sure that would have helped me today.
> > >
> > > I couldn't get a successful connect internal.
> > >
> > > Before issueing a connect, svrmgrl would generate the error 3113 and
any
> > > command I issued like connect would fail with 3113.
> > >
> > > "koert54" <nospam_at_nospam.com> wrote in message
> > > news:A7Q5a.68694$Jd.8164_at_afrodite.telenet-ops.be...
> > > > as you're using oracle 8 :
> > > > svrmgrl
> > > > connect internal
> > > > oradebug ipc
> > > > ->>> shows you all the info you need
> > > >
> > > > "JustAnotherDBA" <jadba_at_bellsouth.net> wrote in message
> > > > news:6UP5a.13220$A27.2303_at_fe03.atl2.webusenet.com...
> > > > > I had to do a ipcrm to zap the shared memory and semaphores for 1
> > > database
> > > > .
> > > > > I did this based on documents in Metalink and I am sure it was
> needed.
> > > > >
> > > > > But, I am wondering if anyone knows how to tell which shared
memory
> and
> > > > > semaphores go with which database.
> > > > >
> > > > > I couldn't find a way, so I shutdown all of the databases. Then, I
> did
> > > the
> > > > > ipcrm command to remove the 1 remaining .
> > > > >
> > > > > No problems after that with the 1 database that I was getting a
3113
> on
> > > it
> > > > > (just by running svrmgrl).
> > > > >
> > > > > Some more info...
> > > > >
> > > > > Solaris 8
> > > > > Oracle8i 8.1.6.2.0
> > > > > 5 databases
> > > > >
> > > > > Fyi... below is the output of ipcs before running ipcrm, but after
> > > > shutting
> > > > > down 1 database...
> > > > >
> > > > > % ==> ipcs
> > > > > IPC status from <running system> as of Sat Feb 22 12:08:52 CST
2003
> > > > > T ID KEY MODE OWNER GROUP
> > > > > Message Queues:
> > > > > Shared Memory:
> > > > > m 0 0x66ac8bec --rw-r----- or02sup sccdba
> > > > > m 2 0xbf400f48 --rw-r----- or02sup sccdba
> > > > > m 403 0xf2ff35a4 --rw------- or02sup sccdba
> > > > > m 404 0x717ed15c --rw------- or02sup sccdba
> > > > > Semaphores:
> > > > > s 196608 0x5857945 --ra-r----- or02sup sccdba
> > > > > s 196610 0x509aa45 --ra-r----- or02sup sccdba
> > > > > s 458755 0x387a875 --ra------- or02sup sccdba
> > > > > s 458756 0x51782c5 --ra------- or02sup sccdba
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> >
> > What does CONNECT INTERNAL have to do with anything?
> >
> > Use vi to open /etc/system
> > Put in the kernel parameters exactly as recommended in the Oracle
> installation
> > documentation
> > Reboot the machine
> > Then you'll likely have no problem with Oracle.
> >
> > Daniel Morgan
> >
>
> Wrong. I only mentioned connect internal in my last reply because of the
> previous poster's comments to run something AFTER doing a connect, which I
> was not able to do.
>
> And, doing a ipcrm fixed my problem. I only wish I didn't have to shutdown
> any other databases other than the 1 that was having a problem.
>
> Your recommendation would have me do something that was obviously not
> required AND rebooting the server which was also not required.
>
> The kernel parameters are just fine.
>
>
>
>
>
Received on Sat Feb 22 2003 - 16:48:59 CST