Most of the scripts are already on the site in other posts but here is a list of the ones that I used in this post, linked to the script itself.

find_sql_acs.sql
dplan.sql
child_load_time.sql
diff_table_stats.sql
flush_sql.sql
find_sql_by_cost.sql
find_sql.sql

Note that I change these little scripts occasionally, so the output may not exactly match the session above, but it should be very close.

Kerry

Those are pretty cool scripts. Would you mind sharing them? :)

Thanks!

NO_INVALIDATE has been around for a while as part of the DBMS_STATS package. If I remember correctly, the default value was FALSE in 9i and changed to AUTO_INVALIDATE in 10g. This basically allows cursors to not be invalidated when stats are generated. There is a related hidden parameter (_optimizer_invalidation_period) which defaults to 1800 seconds (5 hours) that tells Oracle how long to allow the affected cursors to remain viable. But it is unclear to me exactly how that works, as it appears in my 11g example that cursors stuck around for a much longer period of time than the 5 hours. There is a pretty good thread on the oracle-l list about this issue here:

http://www.freelists.org/post/oracle-l/dbms-statsauto-invalidate

And another good one on OTN here:

http://forums.oracle.com/forums/thread.jspa?threadID=592771

Also, Jonathan Lewis had a post about it here:

http://jonathanlewis.wordpress.com/2008/02/13/statistics-problem/

Kerry

Kerry,

Interesting. Is this a “new feature” or has been there in earlier versions as well? I was under impression (and have observed as well) that the queries are re-parsed (or hard parsed) when the stats on underlying tables change.

We had exactly the same issue on one of our Data Warehouse databases. A query which would normally take few seconds took several minutes. The fix was to copy stats from the previous partition.