Statistics gathering in 10g - Histograms

Question

I went through some articles in the web as well as in the forum regarding stats gathering which I have posted here.
http://structureddata.org/2008/03/26/choosing-an-optimal-stats-gathering-strategy/
In the above post author mentions that
"It may be best to change the default value of the METHOD_OPT via DBMS_STATS.SET_PARAM to 'FOR ALL COLUMNS SIZE REPEAT' and gather stats with your own job. Why REPEAT and not SIZE 1? You may find that a histogram is needed somewhere and using SIZE 1 will remove it the next time stats are gathered. Of course, the other option is to specify the value for METHOD_OPT in your gather stats script"
Following one is post from Oracle forums.
Statistics
In the above post Mr Lewis mentions about adding
method_opt => 'for all columns size 1' to the DBMS job
And in the same forum post Mr Richard Foote has mentioned that
"Not only does it change from 'FOR ALL COLUMNS SIZE 1' (no histograms) to 'FOR ALL COLUMNS SIZE AUTO' (histograms for those tables that Oracle deems necessary based on data distribution and whether sql statements reference the columns), but it also generates a job by default to collect these statistics for you.
It all sounds like the ideal scenario, just let Oracle worry about it for you, except for the slight disadvantage that Oracle is not particularly "good" at determining which columns really need histograms and will likely generate many many many histograms unnecessarily while managing to still miss out on generating histograms on some of those columns that do need them."
http://richardfoote.wordpress.com/2008/01/04/dbms_stats-method_opt-default-behaviour-changed-in-10g-be-careful/
Our environment Windows 2003 server Oracle 10.2.0.3 64bit oracle
We use the following script for our analyze job.
BEGIN DBMS_STATS.GATHER_TABLE_STATS
(ownname => ''username'', '
'tabname => TABLE_NAME
'method_opt => ''FOR ALL COLUMNS SIZE AUTO''
'granularity => ''ALL'', '
'cascade => TRUE, '
'degree => DBMS_STATS.DEFAULT_DEGREE);
END;
This anayze job runs a long time (8hrs) and we are also facing performance issues in production environment.
Here are my questions
What is the option I should use for method_opt parameter?
I am sure there are no hard and fast rules for this and each environment is different.
But reading all the above post kind of made me confused and want to be sure we are using the correct options.
I would appreciate any suggestions, insight or further readings regarding the same.
Appreciate your time
Thanks
Niki

Answer 1

Niki wrote:
I went through some articles in the web as well as in the forum regarding stats gathering which I have posted here.
http://structureddata.org/2008/03/26/choosing-an-optimal-stats-gathering-strategy/
In the above post author mentions that
"It may be best to change the default value of the METHOD_OPT via DBMS_STATS.SET_PARAM to 'FOR ALL COLUMNS SIZE REPEAT' and gather stats with your own job. Why REPEAT and not SIZE 1? You may find that a histogram is needed somewhere and using SIZE 1 will remove it the next time stats are gathered. Of course, the other option is to specify the value for METHOD_OPT in your gather stats script"
This anayze job runs a long time (8hrs) and we are also facing performance issues in production environment.
Here are my questions
What is the option I should use for method_opt parameter?
I am sure there are no hard and fast rules for this and each environment is different.
But reading all the above post kind of made me confused and want to be sure we are using the correct options.As the author of one of the posts cited, let me make some comments. First, I would always recommend starting with the defaults. All to often people "tune" their dbms_stats call only to make it run slower and gather less accurate stats than if they did absolutely nothing and let the default autostats job gather stats in the maintenance window. With your dbms_stats command I would comment that granularity => 'ALL', is rarely needed and certainly adds to the stats collection times. Also, if the data has not changed enough why recollect stats? This is the advantage of the using options=>'gather stale'. You haven't mentioned what kind of application your database is used for: OLTP or data warehouse. If it is OLTP and the application uses bind values, then I would recommend to disable or manually collect histograms (bind peeking and histograms should not be used together in 10g) using size 1 or size repeat. Histograms can be very useful in a DW where skew may be present.
The one non-default option I find myself using is degree=>dbms_stats.auto_degree. This allows dbms_stats to choose a DOP for the gather based on the size of the object. This works well if you dont want to specify a fixed degree or you would like dbms_stats to use a different DOP than the table is decorated with.
Hope this helps.
Regards,
Greg Rahn
http://structureddata.org