Re: Solaris Unix Shared Memory Semaphores - 3113 Problem

JustAnotherDBA wrote:

> Don't get me wrong, I do appreciate your post. After reading your post, it
> did occur to me about making that command part of a normal startup process
> for future protential problems.
>
> I do the basic kernel stuff as step1 of new hardware, so I knew in this case
> the kernel was not the problem.
>
> I just wanted info like you provided... only wish it could be displayed when
> a problem like this occurs.
>
> DA Morgan's response would be good for a newbie, but I thought I gave enough
> info to indicate I had the basics down. It appeared to me that my post was
> not completely read, and that bothers me more than anything. I would prefer
> no comments to my posts than someone posting a reply and it is obvious they
> did not read my entire post.
>
> "koert54" <nospam_at_nospam.com> wrote in message
> news:v7T5a.68937$Jd.8195_at_afrodite.telenet-ops.be...
> > 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.
> > >
> > >
> > >
> > >
> > >
> >
> >

If you are interested ... what made me suspect you were a newbie was the reference to CONNECT INTERNAL. Had you indicated that you had dealt with kernel parameters, the cause of ORA-03113 in 95+% of all cases, I would have responded differently.

Don't expect those of us out here answering questions to be mind readers. If you have a situation where most of the time the solution is X and you don't want it suggested ... just state that you have that you have already dealt with the issue.

And not to cause offense ... but as I can't look over anyone's shoulder, read anyone's mind, and my crystal ball has been broken for some time ... I err toward answering for the most likely solution ... not the least likely.

Daniel Morgan Received on Sun Feb 23 2003 - 12:13:05 CST