----- Original Message ----- > Wouldn't it be nice if dbms_stats could do an "incremental" refresh, > tracking ONLY stats changes that might make a difference to execution plan:
I'd settle for a flag I could turn on and off, saying: "do/do not change stats for this object". I know which of them need to be analyzed and which don't. Better than Oracle will ever, deltas or no deltas, workload managers or not. > a) Allow for dbms_stats to collect, store and compare changes to > historical execution plans, using historical SQL from STATSPACK (or new 10g > workload views) Sadly, this workload feature of 10g if I know anything about how Oracle works, will evolve into another monster elephant gun. Completely forgetting the problem out there is in most cases mosquito-size and can be addressed with a simple fly-swat. Yes, there is such a thing as over-engineering a solution. This will be one of them. And like anything that is over-engineered, it will be buggy - sorry Pete, "feature-reluctant". Or perheaps "document-challenged"? And it will create a bad name for itself while the developers "evolve" it until Oracle 12r2... > b) Allow the DBA control about whether to implement the new > statistics That, sadly, is totally outside of Oracle's plans for the traditional production DBA role in future. > It would cost these clients many thousands of dollars to have adjusted these > plans, and management says "If it ain't broke, why fix it". My problem too. Try and convince a damager that something that is working fine should have thousands of buckeroos spent on it to become "compatible" with new CBO! Like Heck it's gonna happen... Cripes, I know quite a few sites here that are STILL running Prime computers with Prime Information (for those who don't know, look-up "Pick" in google), 13 years after the company vanished! And no plans whatsoever to update. Why? Heck, it WORKS! Talk about TCO, eh? > Oracle made a big-deal about going to the CBO in 11i, yet when we look at > the SQL, a significant number of statement employ the "rule" hint! > Connect-the-dots and you can guess why the RBO IS NOT being removed from > Oracle10g. . . . Bingo!... Cheers Nuno Souto [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Souto INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
