I’m not entirely sure of the point you want to make, but I think by “this argument” you mean the comment on the metalink note. Two things then: (a) the fact that the metalink note says it is a good argument for EBS is not the same as saying it’s a bad argument for everything else and (b) the blog I referenced has already made the point that I think that gathering system statistics is generally a bad idea.

Be careful that you distinguish between “gathering” system statistics and “using” system statistics. From 10g onwards you use system statistics by default, even if you haven’t gathered them.

The dev/qa question is interesting – if you are trying to check the probable performance of the production code on a box that is significantly different from the test box then you have to worry about much more than just the system statistics: but it make sense to set them to the values used on the production box if you want to get the best chance of consistent execution plans.

– Kumar

If you follow my “further reading” links you’ll note in the “System Stats Strategy” that I’ve made similar comments.

Possibly the SR makes the point it does because it is a benefit to the support team if they don’t have to factor in different values for system stats whenever they’re trying to work out what’s going wrong with a client’s query.

Thanks for the link.

Quick summary (slightly evolved from the “Further Posts” due to the passage of time).

Initial testing – from 10g onwards, don’t set them
If necessary – use set_system_stats to create realistic seek and transfer figures

Similarly, don’t set db_file_multiblock_read_count, and don’t set the two optimizer_ind% parameters (without extreme provocation.)

Thank you for supplying the warning.

My ability to read Russian is limited to pressing buttons on Google Translate – and assuming that the occasional strange word is the wrong literal translation of a word that can be used in many circumstances. Within the bounds that limitation, it seemed that most of the text made sense – but I hope readers following will be duly cautious.

7) Should dbms_stats.gather_system_stats be used with E-Business 11i or R12?

The use of dbms_stats.gather_system_stats to collect system stats is not recommended with Apps E-Business Suite 11i or R12.

Not collecting system stats will make the CBO (in DB 10g onwards) to use what are called “noworkload_stats”, which have quite sensible defaults.

The main reason for this recommendation is the desire for stability and the potential problems related to large plan variances from system to system and even within one system, which would depend on the workload when these stats were gathered

Thank you
Kumar

Which just goes to show, you can lead the CBO to order, but you can’t make it think.

Keeping my fingers crossed!

better ask to remove that Russian translation (http://www.oracle.com/global/ru/oramag/march2005/admin_sys_stat.html), it is enormously bad.

Oleksandr