Re: Solaris Unix Shared Memory Semaphores - 3113 Problem

"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:11:31 CST