Re: Solaris Unix Shared Memory Semaphores - 3113 Problem

"DA Morgan" <damorgan_at_exesolutions.com> wrote in message news:3E590F31.756E2307_at_exesolutions.com...
> 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.
>

Ok. I should have said I know the kernel is ok.

> 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.
>

I should say I appreciate your comments too because anyone who spends their time freely by posting in here should be appreciated. Tanks.

> Daniel Morgan
>
Received on Sun Feb 23 2003 - 12:41:17 CST