Re: ipcs problems - possibly - in oracle 8?

Thanks David, but I know it's not the listener that's causing the problems.

When they attempt to logon, they get past their username/password deal and then get a bizarre message (which I don't have to hand) about a trigger not being recognised. This isn't down to the application however as it can all start working again in a few minutes with nothing changed by DBA/Unix/client...

Last night's reboot *appears* to have cured it at the moment, but we'll see...

Thanks again.

"David Fitzjarrell" <oratune_at_aol.com> wrote in message news:9429kk$8qe$1_at_nnrp1.deja.com...
> In our last gripping episode David Fitzjarrell <oratune_at_aol.com> wrote:
> > In article <979668449.24111.0.nnrp-10.c30bdde2_at_news.demon.co.uk>,
> > "andrew_webby at hotmail" <spam_at_no.thanks.com> wrote:
> > > Hi
> > >
> > > Can anyone give me a clue here?
> > >
> > > I've a couple of test databases recently upgraded to Oracle 8.1.6r2
 on
> > > Solaris 2.7.
> > >
> > > The test users are complaining that sometimes they can get in,
 sometimes
> > > they can't (we've checked the usual suspects like listener, alert
 log
 etc,
> > > but no dice). As nothing was changing in between (neither client nor
> > > database), my suspicions fell on unix itself.
> > >
> > > About the only thing that looks out of the ordinary is shared memory
 ISM
> > > attaches which worryingly looks like this:
> > >
> > > (ipcs -i)
> > > T ID KEY MODE OWNER GROUP ISMATTCH
 NATTCH
> > > Shared Memory:
> > > m 0 0x500e0dd9 --rw-r--r-- root root 1
> > > m 1 0x790 --rw-rw-rw- root root 0
> > > m 2 0x9ae7520 --rw-r----- oracle dba 10
 11 -
> > > RBTEST
> > > m 3 0xbf67de8 --rw-r----- oracle dba 25
 25 -
> > > HOULIVE
> > > m 4 0x98a5f10 --rw-r----- oracle dba 37
 36 -
> > > RBLIVE
> > > m 5 0xb4e6bf8 --rw-r----- oracle dba 8
 8 -
> > > HOUTEST
> > > m 6 0x1503facc --rw-r----- oracle dba
 4,294,966,760 10 -
> > > RBDEV
> > > m 7 0xb45ab788 --rw-r----- oracle dba
 4,294,964,292 7 -
> > > HOUDEV
> > > m 8 0x280267 --rw-r--r-- root root 0
> > >
> > > (sorry, here's hoping you use Courier font... :-)
> > >
> > > As you'll see, the ism attch column is mental. Also, it's going
 down.
 I
> > > appreciate that this may be more of a solaris problem, so I've
 posted
 there
> > > as well. The man pages don't give too much detail on why this might
 occur
> > > (though the large number leads me to believe an overflow of an
 unsigned
> > > integer or similar has occured).
> > >
> > > Any ideas if this is something for concern and if anyone can point
 me
> > > towards something useful on ISMATTCH (I've tried Sun search, general
> > > web/usenet search etc), that would be top (no unix-pun intended).
 I'm
> > > certainly giving it a good go here, but our top unix man is off on
> > > compassionate leave and there's danger of a crowd forming around my
 desk...
> > >
> > > Andrew
 

> Yet more related information:
>
> Doc ID: Note:69016.1
> Subject: Solaris Bug Causes Listeners To Stop Responding To Incoming
> Connection Requests
> Type: ALERT
> Status: PUBLISHED
> Content Type: TEXT/PLAIN
> Creation Date: 11-MAR-1999
> Last Revision Date: 12-MAR-1999
> Language: USAENG
>
>
> Platform Affected
> ~~~~~~~~~~~~~~~~~
>
> Solaris 2.51 and 2.6
>
> Description
> ~~~~~~~~~~~
>
> Solaris bug causes listeners to stop responding to incoming connection
> requests
> from browsers.
>
> There is a Solaris Bug, number 4089811, that causes the accept() C
> function call
> to return multiple file handles when a control parameter, so_qlen, is
> set to
> 1, which is the means of specifying to the TCP driver that only one
> file handle
> is to be returned per accept() call. When this happens, the socket
> structure
> associated with the file handle is damaged, and the socket must be
> closed and
> reopened before new connection requests will be honored. The damage is
> to the
> operating system's copy of the socket, so this is the only possible
> recovery.
> The bug will happen when two or more connection requests are received
> between
> CPU quanta (while the process is asleep and other processes are
> running), which
> implies that it will only be seen under conditions of heavy load.
>
> This bug was introduced in Solaris 2.51 in patch 103588 beginning with
> version
> -11. It was fixed in 103588 beginning with version -20. It was
> present in
> Solaris 2.6 from inception, for programs that use the old-style socket
> structure (as we do) and is fixed in patch 105529 beginning with
> version -05.
>
> Identifying the bug:
>
> If the listener stops processing incoming browser requests, but the
> listener
> process is still running and previous requests are honored even after
> it has
> stopped servicing new ones, you may have encountered the bug.
>
> Check the OS version with uname -a. Then check for 103588-11 through
> 103588-19
> on 2.51, or 105529-01 through 105529-04, or 105529 missing completely,
> on 2.6.
> You can check patches on Solaris with showrev -p. If you are running
> 2.51 with
> 103588-11 through -19, or 2.6 unpatched or with 105529-04 or less, then
> you may
> be seeing this bug.
>
> Fixing the bug:
>
> You must download 103582-20 or later if you are running 2.51, or 105529-
> 05 or
> later if you are running 2.6. As with many Solaris patches, this one
> must be
> installed as root, and a reboot is required. If you have questions
> about these
> patches, You should call Sun Microsystems for assistance.
>
> Workaround
> ~~~~~~~~~~
>
> There is a workaround available if you need an immediate fix, while you
> are in
> the process of downloading the patch, but this workaround has an
> associated
> risk. The original problem, both in 103582-11 and in 2.6, was
> introduced as a
> result of a fix for Sun Bug #1182957, the infamous SYN Bombing bug. To
> avoid
> this bug, and protect your Internet servers, the socket structure was
> changed, but a mistake was made in the coding and bug #4089811 was
> introduced.
> This workaround will temporarily undo the fix for #1182957, so you will
> be
> vulnerable to SYN Bombing again. You must understand that Oracle
> cannot accept
> responsibility for the results of a SYN Bombing attack on your system
> (s). The
> results will be temporary denial of connection requests for a period of
> about 5
> minutes following each attack. For complete details, you should visit
> Sunsolve web site (http://sunsolve.sun.com/) and examine both of these
> bugs,
> with especial attention to bug #1182957.
>
> If you are still anxious to implement the workaround after all of this,
> then
> give the following command as root:
>
> # ndd -set /dev/tcp tcp_conn_req_max_q0=0
>
> This command must be repeated after each reboot of the system to reset
> the
> parameter in the TCP driver.
>
>
>
> --
> David Fitzjarrell
> Oracle Certified DBA
>
>
> Sent via Deja.com
> http://www.deja.com/
Received on Wed Jan 17 2001 - 04:30:21 CST