I’d love to see a SQL statement who’s text doesn’t change but who’s SQL_ID does. Please send me some details.

Kerry

It is Siebel application database.

select
extractvalue(value(t),’.') hint
from
table(
select
xmlsequence(
extract(xmltype(other_xml),’/other_xml/outline_data/hint’)
)
from
v$sql_plan
where
sql_id = ‘&m_sql_id’
and child_number = &m_child_no
and other_xml is not null
) t
/

That’s an interesting case. Just to clarify, when you say the plan had changed you mean that the plan steps were operating on different objects. And so in reality, the plan had changed even though it wasn’t reflected in the plan text, and thus the plan_hash_value didn’t change. Randolf’s post points out a bunch of things that are not used in calculating the plan_hash_value and the fact that it only looks at the texts of the plan steps (and knows nothing about the underlying objects – so synonyms pointing to different objects or multiple objects with the same name could all trip it up). I personally believe that the calculation of the plan_hash_value should probably be modified to include more information (such as the predicates and the object_id’s). Thanks for the link to the post by the way.

Kerry

A big difference in the oracle-l example was that the plan HAD changed, even though the plan_hash_value hadn’t changed and a cursory inspection of the tkprof output suggested that the plan itself hadn’t changed. I’ve now written up a blog article about it, with a simplified model of the demonstrating the issue: http://jonathanlewis.wordpress.com/2013/06/07/same-plan/

Regards
Jonathan Lewis