Comments on: Unstable Plans (Oracle Plan Stability/Instability)

By: osborne

osborne — Mon, 19 Jul 2010 00:17:06 +0000

I think you are confusing plan_hash_value with hash_value (and old_hash_value). A statement can have only one sql_id and only one hash_value (its based on the text of the statement). A statement can have many plan_hash_values. And yes you can influence a statement to use a particular plan. I’ve done a number of posts on using SQL Profiles to do just that. See SQL Profiles for example.

Kerry

By: Yuvaraj

Yuvaraj — Mon, 05 Jul 2010 00:27:25 +0000

I thought of checking with you whether if it is possible to force oracle to use the plan from old hash value then the newer one. There are two hash values for a same SQL_ID. I would like to force the old hash value.

By: osborne

osborne — Mon, 05 Jul 2010 00:22:15 +0000

I’m sorry Yuvaraj, but I have not done anything with old_hash_value. Nor do I know of anyone who has written about it. Tanel Poder has written about calculating SQL_ID from hash_value though.

Kerry

By: Yuvaraj

Yuvaraj — Mon, 05 Jul 2010 00:13:56 +0000

Thanks. I am trying to find a procedure to use old hash value instead of a new hash value. There are two hash values for a same SQL_ID. Could you pls provide a link if you have written a doc on this?

By: osborne

osborne — Sun, 04 Jul 2010 19:47:36 +0000

SELECT * FROM table(dbms_xplan.display_awr(nvl(’&sql_id’,'a96b61z6vp3un’),nvl(’&plan_hash_value’,null),null,’typical +peeked_binds’));

By: Yuvaraj

Yuvaraj — Sun, 04 Jul 2010 19:41:13 +0000

Could you paste the “@dplan_awr” script?

By: osborne

osborne — Thu, 09 Jul 2009 13:05:55 +0000

Hi Paul,

The find_sql.sql script is here:

http://www.oracle-guy.com/scripts/find_sql.sql

Sometimes I don’t post the text for scripts I use regularly (if I’ve already posted them). A quick search for the script name in the blog search box will usually turn them up. I probably should do a post that lists my most used scripts with links to them. I’ll see if I can get that done soon.

Kerry

By: Paul

Paul — Thu, 09 Jul 2009 09:20:52 +0000

Hi Kerry,
Nice piece of work. Could you please post the ‘find_sql.sql’ script??
thx
Paul

By: osborne

osborne — Fri, 12 Jun 2009 13:27:05 +0000

Julio,

Not much to go on in you’re question, but I’ll hazard a couple of suggestions any way. Plan instability is often the result of bind variable peeking. The worst cases often happen when you have a histogram on a skewed column in combination with a bind variable in a where clause that references the column. The best way to fix this issue is to use literals instead of bind variables for such columns. Creating a SQL Profile or Outline to lock in one of the plans can often be a pretty quick short term fix as well. Also, you should be aware that 10g’s standard method of gathering stats does not do a very good job (in my opinion) of picking which columns to gather histograms on (it usually creates too many). The auto sample size is often too small to create an accurate histogram as well. So you may want to re-evaluate the stats gathering. I’ve written several posts about bind variable peeking and methods for dealing with the issue. Here are a couple you might want to look at:

Bind Variable Peeking Drives Me Nuts!
Outlines - aka Plan Stability
SQl Profiles

Or just search the blog for “Plan Instability” or “Bind Variable Peeking”.

Hope that helps.

Kerry

By: Julio Cesar

Julio Cesar — Wed, 10 Jun 2009 20:36:37 +0000

Hi Kerry, we are facing this trouble now, the same query can run in 1 minute or in a hour, we disabled the AMM and set all the memory parameters manually, but the problem persists in a dangerous way, do you have some idea in solving it?

Best regards and I wish you luck if you’re still with this trouble.

Júlio César