RE: Optimizer Stats collection for Datawarehouses
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <jaromir@xxxxxxxxxxxx>, <smishra_97@xxxxxxxxx>
- Date: Thu, 19 Nov 2009 09:30:27 -0500
all good advice. and it is especially important in some cases to update the
low/high values for some columns to what they might be at the end of the
day, week, or month rather than what values of the empty new partition are.
Jonathan might have mentioned that, but I didn't re-read the link (possibly
I've never read it, but I'm sure I've heard Jonathan's reasoning on the
matter.) As per usual you can probably trust JL, but he makes it easy to
confirm his results for your case by experiment as well. Likewise you can
test your mileage on plans generated with low/high statistics set for the
set of columns where you know the slightly future answer. That is the sweet
spot where human knowledge of what is likely in the future for a specific
application beats the default auto stuff. While it is technically feasible
to create a few models of synthesizing new partition statistics from old
partitions, I'm not aware of it being there or even anyone thinking about it
seriously yet. Even then someone with knowledge of the appropriate
abstraction from existing partitions to new would have to suggest which
model to use. But you probably know reasonable low/high values for the key
predicate columns of the new partition when you make it.
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of jaromir nemec
Sent: Thursday, November 19, 2009 6:10 AM
To: smishra_97@xxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Optimizer Stats collection for Datawarehouses
Hi Sanjay,
In case the partition and loading schema are equal the statistics should
be calculated by the application (as Nuno pointed) - i.e. create
partition, load and analyze in one step.
If the partitioning and loading schema differ highly (e.g. monthly
partition populated in real time) the same is valid as for OLTP objects
(monitoring or periodic gathering).
> when new partition created and utiliZed can experience some performance
> slowness on the first day of the month
One possible solution is to set some precalculated statistics after the
creation of the empty partition. The idea behind is: the CBO is probably
less confused if it things that all partitions are full filled. One
catastrophic scenario of projection of the statistics from empty partition
to filled partition is documented under
http://www.jlcomp.demon.co.uk/faq/bind_peek.html
Additionally:
Staging objects (used few times only) are not analyzed and processed with
dynamic sampling
Regards,
Jaromir
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
