DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=ViMddDxCqLHUR8Z8Cw1YlAt2tCw5i8swyMR839BhKb27fkjcSYFKDld1jNwgOZyj94UeomrTl9rBXzVXpXDCbhzuDZzSJ8R5lj4WUCQGyG4ITePlDI8KtJJHY2gnTh8VzOcrP6kfn1J6wvLckeg6pY27yQzVJJzKe92SKEtukbc=
Message-ID: <716f7a630709141424o4f7647dehf34e44cfb2caff6e@mail.gmail.com>
Date: Fri, 14 Sep 2007 16:24:57 -0500
From: "Don Seiler" <don@seiler.us>
To: "Jeremiah Wilton" <jeremiah@ora-600.net>
Subject: Re: Weird database hanging
Cc: "Elliott, Patrick" <patrick.elliott@medtronic.com>, 
 oracle-l <oracle-l@freelists.org>
In-Reply-To: <46EAF2F2.2020006@ora-600.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <716f7a630709141119p6b28d084h1ee33adec81944ca@mail.gmail.com>
	 <302F06193D7F4D48ABC997408E786BD0026FC3B0@MSPM1BMSGM09.ent.core.medtronic.com>
	 <716f7a630709141209y3cbf7d8ay920a22bfd6d6edf4@mail.gmail.com>
	 <46EAF2F2.2020006@ora-600.net>
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-to: don@seiler.us

The two largest items are Concurrency and Other.  The concurrency
events deal with latches (shared pool and library cache).  The Other
events deal with "block change tracking buffer space" and "latch
free".

There is also a large number of "Configuration" class events, but
those come at 11:28, after all the fun, so might just be another
symptom.

Don.

On 9/14/07, Jeremiah Wilton <jeremiah@ora-600.net> wrote:
> Don,
>
> Do you have any reason to believe that your system exceeded these limits
> during your issue?  I am certain that reaching this limit would not have
> caused PMON and process creation timeouts such as those you saw.  Unix
> returns an error, and does not hang, when the resource limit is reached.
>   For instance, your login as SYSDBA would have failed, not hung and
> eventually succeeded.
>
> I believe this is a red herring, and in fact another shot in the dark.
> You could easily reach a limit like this during a hang, since inbound
> requests would require additional sessions to be started, but that's not
> a root cause, it is a result.
>
> In fact, by increasing limits like this, you could easily make such
> hanging situations worse, by allowing incoming requests to completely
> swamp the host with no checks until over 16000 processes are spawned. I
> don't think that is what you want.  We shouldn't set values based on
> what "experts" tell us, but rather to the correct value for the system
> in question based on business and technical needs.
>
> Again, I recommend finding out where all that time was going on the
> instance when PMON was timing out.  ASH is your friend.
>
> Jeremiah Wilton
> ORA-600 Consulting
> http://www.ora-600.net
>
> Don Seiler wrote:
> > oracle ~ $ ulimit -u
> > 2047
> > oracle ~ $ ulimit -n
> > 1024
> >
> > This is a big gaffe.  According to Puschitz those values should be set
> > in the .bash_profile to 16384 and 63536, respectively.  Mea culpa on
> > completely missing these in the setup.
>
>


-- 
Don Seiler
oracle: http://ora.seiler.us
ultimate: http://www.mufc.us
--
http://www.freelists.org/webpage/oracle-l