DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
  b=wh8QaYzvnJxaEqCTJa9DgKQkeb2q4MnvQzjNPUq05Sb9N/4iitQeemkhOWOSTKHPPDe0iKw9fRUlADd3i9Uk7ViCAIyNkDJJxAmXzUZoaB0cSBcoymorLlonOkHxfZO7topfilPEAflDkfckbLHYLAI7GsGVL7IOMrpl0SsFigs=;
Date: Fri, 30 May 2008 12:54:41 -0700 (PDT)
From: Yong Huang <yong321@yahoo.com>
Subject: Re: create table and create index monitor or nomonitor deprecated in 10g?
To: Jared Still <jkstill@gmail.com>
Cc: oracle-l@freelists.org
In-Reply-To: <bf46380805301022v1171bca3oe2c15940d8898eed@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Message-ID: <734468.65430.qm@web80607.mail.mud.yahoo.com>
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-to: yong321@yahoo.com

--- Jared Still <jkstill@gmail.com> wrote:

> On Fri, May 30, 2008 at 9:17 AM, Yong Huang <yong321@yahoo.com> wrote:
> 
> > Modification Monitoring: _dml_monitoring_enabled
> > This 10g param allows you to do what you used to be able to do in 9i with
> > alter
> > table (no)monitoring, but not at table level any more; it's system wide
> > either
> > all monitoring or all nomonitoring. But I think it’s still better to
> > disable
> > this parameter and leave statistics_level to typical than set
> > statistics_level
> > to basic when you want to disable table monitoring. Documentation writers
> > must
> > have a dilemma, though; they probably wish the first underscore were
> > dropped.
> >
> >
> There's at least one exception.
> 
> If you are stuck on 10.2.0.2 (not allowed to upgrade) then you best not
> use ASMM, and have statistics_level = basic, as well as db_cache_advice=off.
> 
> While benchmarking a 10.2.0.2 database a nasty performance bug appeared.
> 
> See ML 5918631.8 and 3452409.8  regarding waits on 'simulator lru latch'
> 
> -- 
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist

Thanks, Jared. I can't view 5918631.8 but I read 3452409.8 before. My article
also says (hope April Sims won't mind) that "Whatever %simulator$ latch
activity is probably due to these nearly unused advisors (people that know
don't use it; people that don't know never check it!)." I was talking about
"Shared Pool Advice: _library_cache_advice" but the idea is the same. Whether
it's 10.2.0.2 or not, if you see too much simulator related latch contention,
turn off db_cache_advice and _library_cache_advice. There're a few other
%advice% params but it's better to work with Oracle to pinpoint exactly the one
that caused the problem. Most (or all?) can be done with alter system
dynamically so checking the effect is quick. db_cache_advice is particularly
bad because you almost always give the rest of memory to buffer cache, and
using it means 100 bytes is wasted for each buffer (Note:148511.1).

Yong Huang


--
http://www.freelists.org/webpage/oracle-l