[unbelievable shameless plug]
or they van use my analyzethis package: http://freekdhooge.wordpress.com/analyzethis/
[/unbelievable shameless plug]

:)

Thanks for the comment – I mentioned the relevant tables in the original note (wri$_opsstat_%_history) but I always think of wri$ tables as being part of AWR and therefore needing the licence. The correction and the comment about the new functions in dbms_stats in 10.2.0.4 are both useful.

For users of 9i, I wrote a note some time ago about how you can easily capture old stats as you create new stats.

In 10g Oracle also takes automatic backups when gathering new statistics, so even without AWR license you could look at the backup statistics to compare them.
In 10.2.0.4 there are even diff_table_stats_* functions that you can use to compare statistics.

regards

Freek

If you disable bind-peeking for this update, the optimizer changes from:

"batch_date = {peeked value which is higher than the high_value}"

to

"batch_date = {unknown value that is assumed to be one of the num_distinct values in the column}"

so the aritmetic can change. In this particular case, if the “badness” of the stats is in the high value, but the rest of the stats (e.g. num_rows, num_distinct) are about right then the optimizer could produce a better plan.

Anthony,
I wouldn’t do this to solve problems with one or two queries. But on a temporary basis, to handle an urgent migration, it would be something I’d test if I had a huge number of problems that couldn’t be addressed any other way.

The experiences I’ve had of problems caused by peeking are largely related to the 10g upgrade resulting in lots of “unexpected” histograms being generated by the automatic stats collection.

I believe you’re right about the outer/inner thing. When I saw it, I couldn’t think of an example of this type where it would make a difference (even if you have a nvl(sum()) in the subquery) and it wouldn’t make any difference in this case.

In fact, if you check the original SQL you’ll see that one predicate is “outered” and the other is “innered”. Because of the latter, Oracle will remove the “outer” anyway – but you would only be able to see that if you checked the filter predicates of the execution plan.

I thought that adding outer join in the subquery add no meaning in the updating process. Is this my opinion correct ?

Thank you,
Rudi Kristanto