Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Solaris Unix Shared Memory Semaphores - 3113 Problem

Re: Solaris Unix Shared Memory Semaphores - 3113 Problem

From: JustAnotherDBA <jadba_at_bellsouth.net>
Date: Sat, 22 Feb 2003 17:49:54 -0600
Message-ID: <INT5a.26341$75.15908@fe10.atl2.webusenet.com>


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.
> >
> >
> >
> >
> >
>
>
Received on Sat Feb 22 2003 - 17:49:54 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US