Thanks for the insight.

Looking forward to your session at AIOUG, Hyderabad :)

If you can’t do this live, then generating the trace at level 4 will give you the bind variable values and types, which may help you to fake the plan. Note that you may have to change the code so that all references to bind variables have explicit conversion functions applied. You may end up having to hint the SQL to force the plan.

Inevitably there will be cases where it is extremely difficult to get “explain plan” to reproduce exactly the same path (down to the predicate level) even if you put in hints that make the plan look the same. But since it’s usually the statistics or the variable types that make the differences, you can often fiddle around and get a pretty good idea.

If you’ve got a closed cursor from your tkprof output, you’ll have the row counts returned as well – which gives you extra information about which execution lines did most work, and that’s important information that you can use to confirm your suspicions.

My question is bit different from the content in the post.

While reading an explain plan output i find predicate information very useful for checking the columns on which access & filter operations are happening. But in the execution plan printed in the tkprof output there is no predicate information. How do we make up for this missing piece of information, if we are given a tkprof output to analyze ?

What i generally try to do is that take explain plan of the query and see the predicate stuff from there. But in many of the cases the execution plan in the tkprof (actual execution plan) & the plan given by explain plan differ. Would like to know that how to troubleshoot the expensive steps in the execution plan in such cases ?

Thanks !

Regards,
Amardeep Sidhu

select id,acc_or_fil,predicates
from (
select id,’access’ acc_or_fil ,access_predicates predicates
from plan_table
where access_predicates is not null
union all
select id,’filter’,filter_predicates
from plan_table
where filter_predicates is not null
) order by 1,2
/

Nice Blog BTW.

Regards

Ian

Highlights are:
There is no SELECTIVITY hint in 10g.
There is a CARDINALITY hint in 10g and 9.2

As the SELECTIVITY hint is not a documented item there is no bug here but you can use the undocumented CARDINALITY hint instead, but it too may be obsoleted in future.

set heading off
set pagesize 0

delete from plan_table;
explain plan for
select * from drawscan10; /* yeah */

set linesize 3000
spool plan.dot

select ‘digraph a {‘ from dual union all
select op from(
select pid, prior op||’->’||op||’;’ op
from (
select id, parent_id pid,
‘”‘||id||
‘ ‘||operation||
‘\n’||options||
‘\n’||object_name||’ (‘||cardinality||’)'||
‘\nACCESS: ‘||replace(replace(access_predicates,’”‘,”),’AND’,'\nAND’)||
‘\nFILTER: ‘||replace(replace(filter_predicates,’”‘,”),’AND’,'\nAND’)||
‘”‘ op
from plan_table
)
start with pid is null
connect by pid = prior id
) where pid is not null
union all
select ‘};’ from dual;

spool off

spool plan.txt
select * from table(dbms_xplan.display);
spool off

set heading on
set pagesize 20

host open plan.dot

set linesize 90

Materialize and Cardinality I first saw (I think) in SQL dumped from the executable and then I searched Metalink although I’m sure I found cardinality somewhere in the documentation once.

Materialize is actually given as a workaround to a bug (3528916.8). So it is semi-official.

I can’t find the original documentation reference I had for the cardinality hint (which was incomplete anyway) – but it arrived in 9i and there was a document somewhere on metalink which says something about its existence and the disappearance of the selectivity hint in 10g.