No, it’s not necessary.

The best strategy depends on version of Oracle, options licensed, time available, and rate of change.

In 11g I would look at using the default (auto_sample_size) because this allows Oracle to use its new ‘approximate NDV’ to calculate the number of distinct values for each column; however I would disable all histogram collection and write code to generate histograms where I thought it necessary.

There’s also the question of partitioning – a monolithic table (with indexes) of 1TB is probably not a good thing (nor is 100GB, for that matter), and you should probably looking at partitioned tables and gathering stats only for changed partitions.

The topic is too big for a blog note – but it’s one a talk about in my chapter of Expert Oracle Practices

I think Stefan has probably answered your question correctly.

There is a memory structure (x$) which collects (approximate) information about data changes, and various things flush this in-memory information to the table. You can flush the information with an explicit call, and there are various routines which do the flush as their first step. Your example probably demonstrates a timing issue about whether or not the flush takes place.

You could always investigate by enabling tracing and seeing what SQL gets generated behind the scenes as you do your tests.

Guess: I assume, not tested, upon using the list stale option, this is done internally as well. An this is
the reason why this information is seen after the call.

I created a partition table (monthly) and inserted rows into it.Gathered the stats of the table using exec dbms_stats.gather_table_stats(‘ANAND’,'SALES_PART’);. Then i locked the stats of the table using dbms_stats.lock_table_stats and did insert into sales_part select * from sales_part where time_id >’01-NOV-10′; which inserted data in December partition.

After doing the insert checked dba_tab_statistics

21:17:31 SQL> select OWNER,TABLE_NAME,PARTITION_NAME,PARTITION_POSITION,STATTYPE_LOCKED ,STALE_STATS
21:17:35 2 from dba_tab_statistics
21:17:35 3 where owner =’ANAND’
21:17:36 4 and STATTYPE_LOCKED is not null
21:17:36 5 order by 2
21:17:37 6 /

OWNER TABLE_NAME PARTITION_NAME PARTITION_POSITION STATT STA
—————————— ————— ————————- —————— —– —
ANAND SALES_PART ALL NO
ANAND SALES_PART SALE_APR 4 ALL NO
ANAND SALES_PART SALE_AUG 8 ALL NO
ANAND SALES_PART SALE_DEC 12 ALL NO
ANAND SALES_PART SALE_FEB 2 ALL NO
ANAND SALES_PART SALE_JAN 1 ALL NO
ANAND SALES_PART SALE_SEPT 9 ALL NO
ANAND SALES_PART SALE_JUN 6 ALL NO
ANAND SALES_PART SALE_MAY 5 ALL NO
ANAND SALES_PART SALE_MCH 3 ALL NO
ANAND SALES_PART SALE_NOV 11 ALL NO
ANAND SALES_PART SALE_OCT 10 ALL NO
ANAND SALES_PART SALE_JUL 7 ALL NO

So, the STALE_STATS column for SALE_DEC partition shows NO.

Immediately, then i ran

select * from table(list_stale(‘LIST AUTO’)); –> It didn’t list the table/partition name .

After, which dba_tab_statistics started showing STALE_STATS value as YES for SALE_DEC partition.

21:21:24 SQL> select OWNER,TABLE_NAME,PARTITION_NAME,PARTITION_POSITION,STATTYPE_LOCKED ,STALE_STATS
21:21:26 2 from dba_tab_statistics
21:21:27 3 where owner =’ANAND’
21:21:27 4 and STATTYPE_LOCKED is not null
21:21:28 5 order by 2
21:21:28 6 /

OWNER TABLE_NAME PARTITION_NAME PARTITION_POSITION STATT STA
—————————— ————— ————————- —————— —– —
ANAND SALES_PART ALL YES
ANAND SALES_PART SALE_APR 4 ALL NO
ANAND SALES_PART SALE_AUG 8 ALL NO
ANAND SALES_PART SALE_DEC 12 ALL YES
ANAND SALES_PART SALE_FEB 2 ALL NO
ANAND SALES_PART SALE_JAN 1 ALL NO
ANAND SALES_PART SALE_SEPT 9 ALL NO
ANAND SALES_PART SALE_JUN 6 ALL NO
ANAND SALES_PART SALE_MAY 5 ALL NO
ANAND SALES_PART SALE_MCH 3 ALL NO
ANAND SALES_PART SALE_NOV 11 ALL NO
ANAND SALES_PART SALE_OCT 10 ALL NO
ANAND SALES_PART SALE_JUL 7 ALL NO

Why is it that after running the function dba_tab_statistics is showing stats as STALE, why not before it?

Thanks for the link – I hadn’t noticed that post.

Extended stats can be very helpful and I would expect to find a few cases on any site I visit where they could be useful. However, although I might look at the capturing table and report to see what it said, I don’t think I would let Oracle generate extended stats automatically.

I have the same opinion of virtual columns, by the way. It’s another variation on the same theme, of course, but again I would expect to find a few cases on any system where they could be helpful.

Thanks for the correction – now fixed.

SQL> desc mon_mods$
Name Null? Type
—————————————– ——– —————————-
OBJ# NUMBER
INSERTS NUMBER
UPDATES NUMBER
DELETES NUMBER
TIMESTAMP DATE
FLAGS NUMBER
DROP_SEGMENTS NUMBER

Please, delete this comment when dequeued end consumed.

On a side note, have probably read this but just curious, in terms of stats collection, what your experience has been with “having” to collect extended stats:

http://blogs.oracle.com/optimizer/2011/03/how_do_i_know_what_extended_statistics_are_needed_for_a_given_workload.html

Thanks and great post.