RE: full-scan vs index for "small" tables
- From: "Laimutis Nedzinskas" <Laimutis.Nedzinskas@xxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 28 Jun 2006 18:15:40 -0000
But isn't it such that once you are happy you stop collecting statistics?
Else it is simply a craziness: one may collect statistics when some tables are
empty, etc, etc.
Even the collection phase itself is a craziness:
- Suppose you set option not to invalidate cached sql plans.
- But CBO is primarally for DW
- Which means some sql is literal
- Which means this sql may get into cache just in the middle of statistics
collection
- Which means that CBO will see old statistics for some tables and new
statistics for another tables.
Imho, this is just crazy.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Nuno Souto
Sent: 28. júní 2006 14:21
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: full-scan vs index for "small" tables
Cary Millsap wrote,on my timestamp of 28/06/2006 11:44 PM:
>
> RBO is dramatically inferior to CBO in every case except for the one
> where the operational manager doesn't do a good job of making sure
> that the statistics are a reasonable representation of the production data.
>
Yes Cary, I hear what you say and agree with it. But if a significant portion
of the data is dropped overnight and then is re-created, is the ops person then
supposed to reset stats with every change in volume in the database? Based on
what criteria should (s)he act, then?
Dynamic sampling is not always the perfect solution.
The problem I'm having is with the definition of "reasonable representation" of
the production data, when such data is highly volatile. Particularly with
9ir2...
--
Cheers
Nuno Souto
in sunny Sydney, Australia
dbvision@xxxxxxxxxxxx
--
//www.freelists.org/webpage/oracle-l
Fyrirvari/Disclaimer
http://www.landsbanki.is/disclaimer
--
//www.freelists.org/webpage/oracle-l
Other related posts:
