Comments on: Bind Variable Peeking with no Histograms http://www.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/ The Alex Gorbachev Oracle Blog Sun, 12 Oct 2008 19:08:59 +0000 http://wordpress.org/?v=2.5.1 By: Appunti sul funzionamento di CBO in Oracle - Parte II « Oracle and other http://www.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-18282 Appunti sul funzionamento di CBO in Oracle - Parte II « Oracle and other Tue, 15 Jul 2008 14:56:04 +0000 http://blog.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-18282 [...] NON SONO LE CATTIVE PRESTAZIONI O LE SCELTE SBAGLIATE DI CBO. Come dice bene Alex Gorbachev in un commento al suo post intitolato “Bind peeking with no histograms” l’unico e vero problema [...] [...] NON SONO LE CATTIVE PRESTAZIONI O LE SCELTE SBAGLIATE DI CBO. Come dice bene Alex Gorbachev in un commento al suo post intitolato “Bind peeking with no histograms” l’unico e vero problema [...]

]]> By: Polarski Bernard http://www.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-17653 Polarski Bernard Fri, 30 May 2008 07:12:46 +0000 http://blog.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-17653 sorry I press too fast, the facts are : peek=1 : Access Path: TableScan Cost: 86.84 Resp: 86.84 Degree: 0 Cost_io: 80.00 Cost_cpu: 3117218 Resp_io: 80.00 Resp_cpu: 3117218 peek=9000001 Access Path: TableScan Cost: 2.02 Resp: 2.02 Degree: 0 Cost_io: 2.00 Cost_cpu: 7851 Resp_io: 2.00 Resp_cpu: 7851 sorry I press too fast, the facts are :

peek=1 :
Access Path: TableScan
Cost: 86.84 Resp: 86.84 Degree: 0
Cost_io: 80.00 Cost_cpu: 3117218
Resp_io: 80.00 Resp_cpu: 3117218

peek=9000001

Access Path: TableScan
Cost: 2.02 Resp: 2.02 Degree: 0
Cost_io: 2.00 Cost_cpu: 7851
Resp_io: 2.00 Resp_cpu: 7851

]]> By: Polarski Bernard http://www.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-17652 Polarski Bernard Fri, 30 May 2008 07:08:24 +0000 http://blog.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-17652 Why is it that cost of full tablescan is different between the 2 peeking ? peek=1 : Access Path: TableScan Cost: 86.84 Resp: 86.84 Degree: 0 Cost_io: 80.00 Cost_cpu: 3117218 peek=9000001 Cost: 86.84 Resp: 86.84 Degree: 0 Cost_io: 80.00 Cost_cpu: 3117218 Resp_io: 80.00 Resp_cpu: 3117218 Why is it that cost of full tablescan is different between the 2 peeking ?

peek=1 :

Access Path: TableScan
Cost: 86.84 Resp: 86.84 Degree: 0
Cost_io: 80.00 Cost_cpu: 3117218

peek=9000001

Cost: 86.84 Resp: 86.84 Degree: 0
Cost_io: 80.00 Cost_cpu: 3117218
Resp_io: 80.00 Resp_cpu: 3117218

]]> By: Alex Gorbachev http://www.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-17461 Alex Gorbachev Tue, 13 May 2008 18:24:01 +0000 http://blog.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-17461 There are cases when you want to use bind variables (majority I'd say) and when you want to use literals (rather exceptional). Unfortunately, most developers don't bother and either used binds everywhere or nowhere (there are good developers as well that do it properly - I'm luck to work with some of those). BVP is a workaround for code where BV are used everywhere even where a literal would be more appropriate. cursor_sharing=force/similar is workaround for the opposite - when binds are not used at all. I think Oracle did good job disabling cursor sharing workaround by default (i.e. cursor_sharing=exact) but they did a mistake enabling BVP by default and, actually, not even exposing the underscore parameter to disable it. Btw, when those two features are combined -- you have the more "intriguing" effects (and bugs). There are cases when you want to use bind variables (majority I’d say) and when you want to use literals (rather exceptional). Unfortunately, most developers don’t bother and either used binds everywhere or nowhere (there are good developers as well that do it properly - I’m luck to work with some of those).

BVP is a workaround for code where BV are used everywhere even where a literal would be more appropriate.

cursor_sharing=force/similar is workaround for the opposite - when binds are not used at all.

I think Oracle did good job disabling cursor sharing workaround by default (i.e. cursor_sharing=exact) but they did a mistake enabling BVP by default and, actually, not even exposing the underscore parameter to disable it.

Btw, when those two features are combined — you have the more “intriguing” effects (and bugs).

]]> By: David Jones http://www.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-17448 David Jones Mon, 12 May 2008 10:05:46 +0000 http://blog.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-17448 Thanks to all the contributors to this thread, which has been very useful in confirming and addressing our own similar problems. I'm intrigued by the extract of Oracle documentation posted by Jonas: >> When bind variables are used in a statement, it is assumed that cursor sharing is intended and that different invocations are supposed to use the same execution plan. If different invocations of the cursor would significantly benefit from different execution plans, then bind variables may have been used inappropriately in the SQL statement. Bind peeking works for a specific set of clients, not all clients.” >> It seems to me Oracle have painted themselves into a logical corner: In a situation where it is not the case that "different invocations of the cursor would significantly benefit from different execution plans", then there is no point in peeking the bind variable to determine the best path. So, if the one time that peeking the variable would be useful is the scenario where "bind variables may have been used inappropriately in the SQL statement", why bother to implement bind variable peeking at all, ever?! Did I miss something? David Thanks to all the contributors to this thread, which has been very useful in confirming and addressing our own similar problems.

I’m intrigued by the extract of Oracle documentation posted by Jonas:

>>
When bind variables are used in a statement, it is assumed that cursor sharing is intended and that different invocations are supposed to use the same execution plan. If different invocations of the cursor would significantly benefit from different execution plans, then bind variables may have been used inappropriately in the SQL statement. Bind peeking works for a specific set of clients, not all clients.”
>>

It seems to me Oracle have painted themselves into a logical corner: In a situation where it is not the case that “different invocations of the cursor would significantly benefit from different execution plans”, then there is no point in peeking the bind variable to determine the best path. So, if the one time that peeking the variable would be useful is the scenario where “bind variables may have been used inappropriately in the SQL statement”, why bother to implement bind variable peeking at all, ever?!

Did I miss something?

David

]]> By: Bind Peeking, Ad Hoc Queries, Stable Performance. On 10G you can only pick any two. http://www.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-16380 Bind Peeking, Ad Hoc Queries, Stable Performance. On 10G you can only pick any two. Wed, 12 Mar 2008 13:04:29 +0000 http://blog.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-16380 [...] 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 [...] [...] 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 [...]

]]> By: Alex Gorbachev http://www.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-16010 Alex Gorbachev Fri, 22 Feb 2008 03:11:54 +0000 http://blog.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-16010 Thanks for the references, Milen. In my experience _optim_peek_user_binds parameter has helped pretty much every time and especially in cases with CURSOR_SHARING=SIMILAR. There is another interesting Metalink Note (<a href="https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=387394.1"387394.1</a rel="nofollow">) that references couple other bugs causing execution plan instability in the section "CONCLUSION" -- bugs 4567767 and 5364143. Thanks for the references, Milen.
In my experience _optim_peek_user_binds parameter has helped pretty much every time and especially in cases with CURSOR_SHARING=SIMILAR.
There is another interesting Metalink Note () that references couple other bugs causing execution plan instability in the section “CONCLUSION” — bugs 4567767 and 5364143.

]]> By: Milen Kulev http://www.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-15969 Milen Kulev Wed, 20 Feb 2008 14:43:36 +0000 http://blog.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-15969 Hello agian Alex, whether a bind variable is peeked depends not only the presence of histograms, bit also on the value of the parameter CURSOR_SHARING. CBO decides to peek (provided that “_optim_peek_user_binds”=TRUE & in absense of bugs -> see my latest post ) the deepending on whether the bind variable is considered "unsafe". A very good read are ML 296377.1 and 377847.1. According to ML 296377.1 the "ultimate" proof (but not the reason why ! ;( ) that a bind variable is considered as "unsafe" is the oacfl2 attribute in a 10046 trace file. Short excerpt from the first ML note: --------------------------------------------------- It is also possible to tell from 10046 trace (level 4/12 - BINDS) if a bind is considered to be unsafe The flag oacfl2 in 9i and fl2 in 10g will show if a variable is unsafe. BINDS #2: bind 0: dty=2 mxl=22(04) mal=00 scl=00 pre=00 oacflg=10 oacfl2=500 size=24 offset=0 bfp=1036d6408 bln=22 avl=04 flg=09 value=16064 bind 1: dty=2 mxl=22(04) mal=00 scl=00 pre=00 oacflg=10 oacfl2=500 size=24 offset=0 bfp=1036d4340 bln=22 avl=04 flg=09 If you note oacfl2=500 #define UACFBLTR 0x00000100 /* Bind was generated by LiTeRal replacement */ #define UACFUNSL 0x00000200 /* UNSafe Literal */ #define UACFNDTL 0x00000400 /* Non-DaTa LiteRal */ --------------------------------------------------- HTH. Milen Hello agian Alex,
whether a bind variable is peeked depends not only the presence of histograms, bit also on the value of the parameter CURSOR_SHARING.
CBO decides to peek (provided that “_optim_peek_user_binds”=TRUE & in absense of bugs -> see my latest post ) the deepending on whether the bind variable is considered “unsafe”.
A very good read are ML 296377.1 and 377847.1.
According to ML 296377.1 the “ultimate” proof (but not the reason why ! ;( ) that a bind variable is considered as “unsafe” is the oacfl2 attribute in a 10046 trace file. Short excerpt from the first ML note:

—————————————————
It is also possible to tell from 10046 trace (level 4/12 - BINDS) if a bind is considered to be unsafe

The flag oacfl2 in 9i and fl2 in 10g will show if a variable is unsafe.

BINDS #2:
bind 0: dty=2 mxl=22(04) mal=00 scl=00 pre=00 oacflg=10 oacfl2=500 size=24
offset=0
bfp=1036d6408 bln=22 avl=04 flg=09
value=16064
bind 1: dty=2 mxl=22(04) mal=00 scl=00 pre=00 oacflg=10 oacfl2=500 size=24
offset=0
bfp=1036d4340 bln=22 avl=04 flg=09

If you note oacfl2=500
#define UACFBLTR 0×00000100 /* Bind was generated by LiTeRal replacement */
#define UACFUNSL 0×00000200 /* UNSafe Literal */
#define UACFNDTL 0×00000400 /* Non-DaTa LiteRal */

—————————————————

HTH. Milen

]]> By: Alex Gorbachev http://www.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-15968 Alex Gorbachev Wed, 20 Feb 2008 14:37:53 +0000 http://blog.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-15968 Thanks for this Milen. The bug itself is not public but Metalink Note <a href="https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=5082178.8" rel="nofollow">5082178.8</a> says that <i>In <b>some</b> situations bind peeking can occur when it should not</i>. Do you have more details about <b>some</b> situations? Thanks for this Milen. The bug itself is not public but Metalink Note 5082178.8 says that In some situations bind peeking can occur when it should not.

Do you have more details about some situations?

]]> By: Milen Kulev http://www.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-15966 Milen Kulev Wed, 20 Feb 2008 14:27:58 +0000 http://blog.oracloid.com/2006/07/bind-variable-peeking-with-no-histograms/#comment-15966 Alex, very useful and refreshing post. The problem is that due to a bug 5082178 , bind variables are peekded, even if "_optim_peek_user_binds"=FALSE. I have had enormous problems with plan stability (on 10.2.0.2 ) with some SQLs, and "_optim_peek_user_binds" was set to FALSE. So, the problem should have been fixed in 10.2.0.4 , accourt to Oracle Corp. (see http://www.dbatools.net/doc/bug10204.html). But first I want to see and then (eventually) believe it ;) . Best Regards. Milen Alex,
very useful and refreshing post.
The problem is that due to a bug 5082178 , bind variables are peekded, even if
“_optim_peek_user_binds”=FALSE.
I have had enormous problems with plan stability (on 10.2.0.2 ) with some SQLs,
and “_optim_peek_user_binds” was set to FALSE.
So, the problem should have been fixed in 10.2.0.4 , accourt to Oracle Corp.
(see http://www.dbatools.net/doc/bug10204.html). But first I want to see and then (eventually) believe it ;) .

Best Regards. Milen

]]>