Re: DBMS_STATS

From: Tim Johnston <tjohnston_at_quallaby.com>
Date: Thu, 06 May 2004 16:42:42 -0400
Message-ID: <409AA342.40803@quallaby.com>

Hi Joe...

I think this goes back to the lowest common denominator argument... =20 Think of it this way...=20

Experienced users... They should understand what stats are and how they =

are used... They know if they need to update them or not depending on=20 their usage patterns... These folks are knowledgeable enough to realize =

this behavior has changed in 10g and that they can turn it off if they=20 desire...=20

Inexperienced users... They have no idea what stats are or why you=20 would need them... They load their database up with data and then=20 complain that things are slow...

Enter automatic stats... It allows Oracle to add another "self=20 managing" feather to the cap... Inexperienced users are amazed at the=20 self managing improvements... And how the database "tunes itself"... =20 Experienced users complain about being forced into things like this... =20 They are knowable enough to read new the manual and figure out how to=20 disable it...

Basically, I think Oracle feels it's a lot easier for an experienced DBA =

to disable stats then it is for an inexperienced DBA to enable stats=20 when necessary... And to be honest, they are probably right... =20 Especially on the low end deployments where they are fighting with that=20 whiz bang self managing GUI controlled beast from Redmond...

My $0.02

Tim

Joe Cooper wrote:

>I know I'm waaaayyy late responding to this one, but I've been busier th=

an usual the past few weeks.  But I must ask one question (and anyone can=
 hop in on this one!!) . . . You, and several others whose opinions I val=
ue, seem to have been quite successful with this don't-over-analyze-the-d=
atabase approach.  Why then does Oracle choose in 10g to automatically co=
llect statistics every night, whether you want it to do so or not??  (See=
 Mr. Freeman's book on 10g New Features, pp.18-19 -- or the pile of trace=
 files that accumulated in my bdump directory shortly after migrating my =
dev instance!!)  You can go in manually and change it, but I prefer doing=
 my own configuration (rather than have it thrust upon me).  Needs may va=
ry widely among instances within an enterprise (i.e. between OLTP and dat=
awarehouse applications) or even among schemas within a database (one app=
 I administer has some tablespaces that are read-only, and others that ex=

perience significant inserts and updates d
> aily). =20
>=20
>Thanks in advance for any insights.
>=20
>Joe Cooper
>Senior Oracle DBA
>Sheshunoff Information Services
>(A Thomson Media company)
>Austin, TX
>Wolfgang Breitling <breitliw_at_centrexcc.com> wrote:
>
>If you had read my presentation/paper you would know that I argue agains=
t=20
>the practice of analyzing on a daily/weekly schedule to keep stats=20
>up-to-date. Most stats in the database I had been managing until last fa=
ll=20
>were over 2 years old.
>
>
> =09
>---------------------------------
>Do you Yahoo!?
>Win a $20,000 Career Makeover at Yahoo! HotJobs=20
>
>----------------------------------------------------------------
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>----------------------------------------------------------------
>To unsubscribe send email to: oracle-l-request_at_freelists.org
>put 'unsubscribe' in the subject line.
>--
>Archives are at http://www.freelists.org/archives/oracle-l/
>FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
>-----------------------------------------------------------------
> =20
>

--=20
Regards,
Tim Johnston
Tel: 978-322-4226
Fax: 978-322-4100

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Thu May 06 2004 - 15:39:55 CDT