Its a great article, very easy to understand about bind peeking and histograms, thanks for sharing the knowledge.

I am not good in sql coding, could you please explain the description of the columns in unstable_plans.sql, awr_plan_stats.sql scripts.

Thanks in advance

Any statement that runs for hours should be captured by AWR, so the scripts in the this post should help you identify that issue. Occasionally statements that run very quickly are not captured by AWR, but if they are run often (which sounds like they are in your case) they will be captured. If they run very quickly and are not capture by AWR when they are running well you may have to capture the plans directly out of the shared pool while they are running or use the ability of AWR to color a SQL statement (using dbms_workload_repository.add_colored_sql) so that it will be captured by AWR regardless of whether it makes it into the top of any category that AWR captures. Whether the instability is caused by BVP or not, the awr_plan_change.sql statement should allow you to get a pretty good idea as to when a key statement is slowing down and hopefully help you diagnose why. Hope that helps.

Kerry

I agree that setting underscore parameters is not a good idea in general. However, in this case it may be warranted. The combination of bind variable, histograms and skewed data can be deadly. While it’s true that you would not be in the majority if you set _OPTIM_PEEK_USER_BINDS to false, you may be surprised to know that there are a fair number of systems that run with that setting. SAP for example uses this setting when they run on top of Oracle. That said, my preference would be to use literals where necessary to get the plans that I want. This does not mean that all statements need to use literals. In fact, it is even possible to write code that is smart about when to use literals. It is often possible to to use literals for a limited number of values while using bind variables where the optimizer doesn’t really need to know the value to get a decent plan. You’re also correct in that gather stats with histograms is expensive. I do believe that in many cases they are gathered where they are not needed. I wrote a pretty lengthy chapter in the recently released Apress book “Pro Oracle SQL” on Plan Stability and Control, by the way. It covers my thoughts on the subject in some detail.

Kerry