Comments on: Bind Peeking

By: Bind Peeking, Ad Hoc Queries, Stable Performance. On 10G you can only pick any two.

Wed, 12 Mar 2008 13:04:36 +0000

[...] have been plenty of posts about bind peeking. Alex Gorbachev wrote about it last year, and so did Jonathan Lewis. It’s a well known issue. However what hasn’t been written about is when it is expected [...]

By: Vivek Sharma

Vivek Sharma — Tue, 03 Jul 2007 09:56:44 +0000

oops….I knew this but while testing it slipped my mind.

Explain Plan and AUTOTRACE reports wrong cardinality whereas, v$sql_plan shows correct figure and also that it peeks the bind variable.

Regards
Vivek

By: Vivek Sharma

Vivek Sharma — Tue, 03 Jul 2007 08:37:13 +0000

Hi Jonathan,

Optimizer used density to calculate the selectivity of the form column_name = constant or column_name = bind_variable. So, with histogram in place, the selecivity of a simple equality predicate can change even for queries involving bind variables.

I have tested this with Oracle 8i / 9i and 10g release 2, but have not found this. For a equality predicate with constant and histogram in place, optimizer is able get a correct cardinality but with bind variables in place, the cardinality comes out as 1/num_distinct * num_rows.

Where am I going wrong ?

Vivek

By: Alex Gorbachev

Alex Gorbachev — Thu, 14 Jun 2007 03:50:39 +0000

Alex, your example uses partitions, does this only happens with partitioned tables?
A bit late but still I should mention that the answer is no as far as I could see. Bind variable peeking happens all the time and presence of histograms is the most common for varying execution plans. Partition is another one. Ranges might be the third one and probably there are other cases as well.

By: Alberto Dell'Era

Alberto Dell'Era — Tue, 15 May 2007 20:57:38 +0000

Yuriy – 10g and dbms_stats with estimate_percent = AUTO or much less than 100% ?
I remember a test case – column GENDER, 1 ‘M’, 999,000 ‘F’. dbms_stats missed the only M, so it was outside the min/max range, so (check Jonathan’s “Cost Based Oracle”, page 49) it estimated a cardinality of 1 for “where gender = :b” when :b = ‘M’, and a cardinality close to 1 million when :b = ‘F’. Index scan for the former, full table scan for the last; it is the same plan you would get with an histogram.

By: Yuriy

Yuriy — Tue, 15 May 2007 15:27:37 +0000

Jonathan,

I believe David wanted to ask not “why” Oracle is creating two different plans, but “how” does he do it?

Say, table t1 has no histograms collected and hence no knowledge of data distribution. And yet for “select * from t1 where c1=:a1″ the optimizer comes up with two different plans, say index access for :a1=5 and fts for :a1=15, and rightly so as we have only 1% of data in t1 table where c1=5 and 99% of data where c1=15

Yet the question remains: How does Oracle know it? Again, there are no histograms collected, but bind variable peeking comes into play and somehow manages to realize that we have unevenly distributed data and produce different plans for different values of bind variables.

How?

By: Jonathan Lewis

Jonathan Lewis — Sun, 08 Apr 2007 15:52:18 +0000

David,
Oracle always peeks at binds when it optimizes a statement. (Bugs and hidden parameters excepted).

The obvious examples of getting multiple plans for the same text come from range-based predicates:
select from orders_table where order_date > :b1;

If your call to this query uses yesterday’s data and my call uses a date from 3 months ago, we probably ought to get different plans. In most cases, though, the first one to execute sets the plan for everyone else. There are cases though – different optimizer environments, for example – where different sessions force extra child cursors (i.e. separate optimizations) to appear.

By: David Perez

David Perez — Sun, 01 Apr 2007 09:32:18 +0000

Hi Alex and Jonathan

I was wondering how CBO can choose different plans when there no histograms (assumming statistics is unchanged)? How can he know the data distribution and choose full or index scan?

Alex, your example uses partitions, does this only happens with partitioned tables?

I have seen bind peeking happens with no histograms but I cannot find a explanation (9.2.0.7). The queries which I have seen this happen are usually not a plain query involving tables, they always involves JOIN.

Cheers

David

By: Jonathan Lewis

Jonathan Lewis — Fri, 09 Feb 2007 16:14:45 +0000

Marc, I'm always a little dubious about setting up a system to automate things like this. Many systems are likely to have a few thousand SQL statements with SQL plans that need to be trapped. Writing code that gets "before" and "after" plans into a structured form that allows them to be cross-checked seems looks like a task that could take a lot of effort and still not work. I have to say that my strategy would be to capture the "before" plans (possibly as simple flat text using the 10132 event I have mentioned previously) and then simply wait for the (few ?)problem statements to appear after the upgrade and check them back manually.

By: Marc

Marc — Fri, 09 Feb 2007 11:27:00 +0000

Jonathan,
I came to the same idea of examining plan – diff’s ( from that oracle white paper you are here refering to )
But it seems they have never used their approach on a real system ( e.g. migration 9i-10g ). Oracle 10g has changed the PLAN notation of operations for PQ … e.g. PX SEND / RECEIVE which in 9i could be represented as PARTITION HASH/RANGE etc.
Anyway I still like the approach and like to know if you think that it would produce reasonable good results by filtering out all the PQ-nodes of the plan and only focussing on (operation,options,object_name) in the diff ?
Kind regards
Marc.