Wrong statistics in AUX_STATS$ might puzzle the optimizer
Posted
by Mike Dietrich
on Oracle Blogs
See other posts from Oracle Blogs
or by Mike Dietrich
Published on Tue, 29 Nov 2011 04:21:17 -0600
Indexed on
2011/11/29
17:56 UTC
Read the original article
Hit count: 301
/Oracle/Best Practice
We do recommend the creation of System Statistics for quite a long time. Since Oracle 9i the optimizer works with a CPU and IO cost based model. And in order to give the optimizer some knowledge about the IO subsystem's performance and throughput - once System Statistics are collected - they'll get stored in AUX_STATS$. For this purpose in the old Oracle 9i days some default values had been defined - and you'll still find those defaults in Oracle Database 11g Release 2 in AUX_STATS$. But these old values don't reflect the performance of modern IO systems. So it might be a good best practice post upgrade to create fresh System Statistics if you haven't done this before.
You can collect System Statistics with:
exec DBMS_STATS.GATHER_SYSTEM_STATS('start');
and end it later by executing:
exec DBMS_STATS.GATHER_SYSTEM_STATS('stop');
You could also run DBMS_STATS.GATHER_SYSTEM_STATS('interval', interval=>N)
instead where N
is the number of minutes when statistics gathering is stopped automatically.
Please make sure you'll do this on a real workload period. It won't make sense to gather these values while the database is in an idle state. You should do this ideally for several hours. It doesn't affect performance in a negative way as the values are anyway collected in V$SYSSTAT and V$SESSTAT. And in case you'd like to delete the stats and revert to the old default values you'd simply execute:
exec DBMS_STATS.DELETE_SYSTEM_STATS;
The tricky thing in Oracle Database 11.2 - and that's why I'm actually writing this blog post today - is bug9842771. This leads to wrong values in AUX_STATS$ for SREADTIM and MREADTIM by factor 1000 guiding the optimizer sometimes into the totally wrong directon. The workaround is to overwrite these values manually and divide them by 1000. Use the DBMS_STATS.SET_SYSTEM_STATS procedure. See this MOS Note:9842771.8 for the above bug for some further information. This issue is fixed in Oracle Database 11.2.0.3 and above.
To get some background information about the statistics collected in please read this section in the Oracle Database 11.2 Performance Tuning Guide. And gathering System Statistics might have some implication if you have mixed workloads - and interacts with DB_FILE_MULTIBLOCK_READ_COUNT. For more information please read section 13.4.1.2.
© Oracle Blogs or respective owner