April 2010

[Phew. At last. The first draft of this was dated more than two weeks ago .... One of the problems with blogging about copying stats was the balance between explaining it and pointing out some of the problems I've encountered. So I've broken up this post, with a little explanation first ...]

Oracle have a lot of on-site consultants, designers and developers who are out working with customers on very large databases and they no doubt have their own internal systems too, so you shouldn't make the mistake of thinking they're unaware of the problems that people face in gathering accurate and timely statistics on large partitioned tables. I don't say that based on any inside knowledge but by

• Attending conferences, listening to presentations, reading White Papers and blog posts; and
• Because they are constantly introducing new features to try to address the issues.

Over the next few posts, I'll look at some of those new features, some of which appear more successful than others. First of all, copying statistics using DBMS_STATS.COPY_TABLE_STATS.

Copying stats is a variation of a technique I've seen used on a couple of Oracle Data Warehouse projects in the past where we decided that spending time and system resources gathering object statistics wasn't useful. Think about some of the problems you'll face when gathering stats on large partitioned objects that I've highlighted so far :-

• It takes time.
• It sucks system resources.
• As you change your strategy and the parameters to reduce the resource and time consumption, the stats are likely to be less accurate.

Then consider why we're gathering these stats in the first place :-