[...]Kerry Osborne’s Oracle Blog » Blog Archive » Unstable Plans (Oracle Plan Stability/Instability) – Kerry Osborne’s Oracle Blog[...]…

[...]Kerry Osborne’s Oracle Blog » Blog Archive » Unstable Plans (Oracle Plan Stability/Instability) – Kerry Osborne’s Oracle Blog[...]…

That’s more difficult but do-able. You’d have to change the group by to use some portion of the sql_text (that presumably matches). I have a rough script that does something like that based on matching the first 80 characters of the SQL text. It is very rough but should give you an idea of how to go about what you are after. Unfortunately I don’t have time right now to work on this, but you can try this as a starting point:

-- unstable_plans_by_sqltext.sql
set lines 155
col execs for 999,999,999
col min_etime for 999,999.99
col max_etime for 999,999.99
col avg_etime for 999,999.999
col sql_text for a80
break on sql_text skip 1
select a.sql_id,
substr(dbms_lob.substr(sql_text,3999,1),1,80) sql_text, b.execs, min_etime, max_etime, norm_stddev
from dba_hist_sqltext a, (
select sql_id, sum(execs) execs, min(avg_etime) min_etime, max(avg_etime) max_etime, stddev_etime/min(avg_etime) norm_stddev
from (
select sql_id, plan_hash_value, execs, avg_etime,
stddev(avg_etime) over (partition by sql_id) stddev_etime
from (
select sql_id, plan_hash_value,
sum(nvl(executions_delta,0)) execs,
(sum(elapsed_time_delta)/decode(sum(nvl(executions_delta,0)),0,1,sum(executions_delta))/1000000) avg_etime
-- sum((buffer_gets_delta/decode(nvl(buffer_gets_delta,0),0,1,executions_delta))) avg_lio
from DBA_HIST_SQLSTAT S, DBA_HIST_SNAPSHOT SS
where ss.snap_id = S.snap_id
and ss.instance_number = S.instance_number
and executions_delta > 0
and elapsed_time_delta > 0
group by sql_id, plan_hash_value
)
)
group by sql_id, stddev_etime
) b
where norm_stddev > nvl(to_number('&min_stddev'),2)
and max_etime > nvl(to_number('&min_etime'),.1)
and substr(dbms_lob.substr(sql_text,3999,1),1,80) like nvl('&sql_text',substr(dbms_lob.substr(sql_text,3999,1),1,80))
and a.sql_id = b.sql_id
order by 2
/

Thanks

Just to provide a little more info to casual observers, here’s a bit of the MOS bug report:

RELEASE NOTES:
]]You may see a different plan hash value after every compilation of a SQL stat
]]ement even when the execution plan is the same when it involves cursor tempor
]]ary tables (name predixed by SYS_TEMP).
REDISCOVERY INFORMATION:
If you see a different plan hash value after every compilation of a SQL
statement even when the execution plan is the same and the plan involves
cursor temporary tables (name predixed by SYS_TEMP) then you are likely
to have encountered the same problem.
WORKAROUND:
None

It’s supposed to be fixed in version 12.1 by the way. ;)

Kerry