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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx >put 'unsubscribe' in the subject line. >-- >Archives are at //www.freelists.org/archives/oracle-l/ >FAQ is at //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@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------