Re: Should we stop analyzing?

• 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
nsouto_at_optusnet.com.au

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Nuno Souto
  INET: nsouto_at_optusnet.com.au

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: ListGuru_at_fatcity.com (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).