Comments on: Stale Stats

By: Simple scripts « Oracle Scratchpad

Simple scripts « Oracle Scratchpad — Sat, 05 Jan 2013 10:09:31 +0000

[...] Similar to “drawing an index”, but listing just the branch blocks in index order. Stale Stats: A simple piece of pl/sql to report objects with stale or missing [...]

By: savvinov

savvinov — Thu, 03 Jan 2013 08:41:47 +0000

Thanks Jonathan.

By: savvinov

savvinov — Thu, 03 Jan 2013 08:23:28 +0000

Hi Sayan,

I agree that this method has many drawbacks, it’s just that I wasn’t aware of all the alternatives. It looks like that USER_TAB_MODIFICATIONS is the best way available (provided that database monitoring info was flushed recently).

Thanks!

By: Jonathan Lewis

Jonathan Lewis — Thu, 03 Jan 2013 07:06:30 +0000

Guest,

Thanks for that.
I like your use of the obj_filter_list (available only in 11g, I believe). I didn’t think of that in my version.
I wrote a version with a couple of default values and a check on the options – otherwise very similar.

By: Guest

Guest — Wed, 02 Jan 2013 15:17:17 +0000

[sourcecode language="sql" wraplines="false" collapse="false"] CREATE OR REPLACE FUNCTION stats_required (i_option IN VARCHAR2, i_user IN VARCHAR2) RETURN DBMS_STATS.objecttab PIPELINED AS /* This function uses autonomous transaction pragma to avoid: ORA-04092: cannot COMMIT in a trigger */ PRAGMA AUTONOMOUS_TRANSACTION; l_object_list DBMS_STATS.objecttab; filter_list DBMS_STATS.objecttab := DBMS_STATS.objecttab (); BEGIN filter_list.EXTEND (1); filter_list (1).objtype := 'TABLE'; DBMS_STATS.gather_schema_stats (ownname => i_user, options => i_option, objlist => l_object_list, obj_filter_list => filter_list); FOR i IN 1 .. l_object_list.COUNT LOOP PIPE ROW (l_object_list (i)); END LOOP; RETURN; END stats_required; / [/sourcecode]

By: Jonathan Lewis

Jonathan Lewis — Wed, 02 Jan 2013 14:01:10 +0000

Jared,

Give it a few more hours for the effects of new year’s celebrations to wear off, and someone’s sure to succumb to temptation. (If not, I’ll do it this evening.)

By: Jared

Jared — Wed, 02 Jan 2013 01:13:22 +0000

Gee, I was really hoping someone else would have pipelined this by now. :)

By: Sayan Malakshinov

Sayan Malakshinov — Tue, 01 Jan 2013 23:56:25 +0000

Yes, it would be really great!

By: Jonathan Lewis

Jonathan Lewis — Tue, 01 Jan 2013 20:32:30 +0000

One of the things I’m not so keen on with the *_tab_modifications views is that it’s often the case that a large fraction of the updates you do are on columns which aren’t likely to be used in where clauses. Along with being able to set table-level preferences for what percentage change constitutes stale, it would be nice if we could specify which actions (inserts, updates, deletes) should be considered as relevant. (Count them all to keep the in-memory code easy, but have three flags decoded when deciding on staleness).

By: Jonathan Lewis

Jonathan Lewis — Tue, 01 Jan 2013 20:27:56 +0000

Owen, Depending on the version of Oracle the underlying tables aren't necessarily updated in a timely fashion, so you have to remember to call the procedure to flushing monitoring info before querying the views (Randolf Geist supplies the name of the procedure this in his comment on the thread). There are also a few gaps - for example the stats on a nested table need to be collected separately from the stats on the parent table (unless I've missed another new option somewhere). user_tab_statistics doesn't report nested tables at all - the call to "list stale" can. Apart from that I'd simply forgotten to keep up to date with the various new columns and procedures that appear with monotonous regularity with Oracle upgrades and leave you doing things the hard way instead of using the new, easy way. (Although the new easy way sometimes isn't quite as easy to get right as one hopes.)