Before finishing an article about bind variables, less detailed, re-add.
Oracle bind variables
http://www.cndba.cn/Dave/article/1275
One. Bind variables
bind variable： A variable in a SQL statement that must be replaced with a valid value, or the address of a value, in order for the statement to successfully execute.
Variable bindings is the OLTP system in a very interesting technology. Good variable bindings make the OLTP system database in SQL to perform fast, high memory efficiency; not using bind variables may cause OLTP database overwhelmed, resources are SQL parsing severely depleted, the system is running slow.
When a user connects to the database, the operation will send a request to the database, ie the database to send over SQL statement. Oracle in receiving these SQL back, this will be the first SQL to do a hash function operation to obtain a Hash value, and then to find out whether there is a shared pool and the hash value matches the SQL existence. If found, the Oracle will directly use an existing SQL execution plan to execute the current SQL , then returns the results to the user. If the same is not found in the shared pool Hash value of SQL , the Oracle will think this is a new SQL . It will be resolved.
Oracle parsing step as follows:
(1) parsing
(2) Semantic Analysis
(3) generate an execution plan, where sub-soft and hard analytical resolution. Hard analysis is very resource intensive.
(4) SQL execution
About SQL parsing, see Blog :
Oracle SQL hard and soft parsing parsing
http://www.cndba.cn/Dave/article/1185
Understanding of SQL execution process, in view of some of the bind variables, the nature of the bind variables that would have to do Oracle hard parsing SQL becomes soft resolved to reduce the ORACLE spent on SQL time and resources on the resolution.
There are two join SQL:
Select salary from user where name=’A’;
Select salary from user where name=’B’;
If you do not use bind variables, this 2 Tiao SQL is parsed 2 times, because they are not the same predicate part. If we use the bind variables, such as:
Select salary from user where name=:X;
At this time, before the 2 pieces SQL becomes a SQL , the Oracle only for each SQL to do a hard analysis, after a similar SQL uses this SQL execution plan generated, so that you can greatly reduce the cost of database in SQL resource overhead on the resolution. This effect when SQL more performed, the more obvious.
Simply put, is to take a bind variable variable in place predicate constants, let Oracle every time a user sent to SQL make hash during operation, the result is the same computed Hash value, and then will be sent to all users SQL seen as the same SQL to object.
two. OLAP and OLTP systems bind variables
OLAP and OLTP systems are very different. The difference between them, detailed reference Blog :
Oracle OLAP and OLTP introduction
http://www.cndba.cn/Dave/article/1462
In the OLTP system, we can use bind variables because the OLTP , the SQL statement is mostly the result set is relatively simple or very small operation. When the index is created on a table, then use the index operation this minimal result set the most appropriate, and almost all of the SQL implementation plan of the index will be selected, as in this case, the index may only need to scan several data data block can be positioned, and the full table scan will be very resource intensive. Therefore, in this case, even if each user predicate conditions are not the same, the implementation plan is the same, that are used to access data index, the basic situation of full table scan does not occur. In this implementation plan is almost unique situation, using bind variables instead of predicate constants, is appropriate.
In the OLAP system, SQL operations on many complex, OLAP Some reports most of the time the database is running SQL , these SQL is often used aggregate queries (eg: Group by ), and the result set is very large, in which case , the index is not an inevitable choice, and sometimes even a full table scan performance will be better than the index, even if the same SQL , if the predicate different execution plans may be different.
For OLAP system bind variables, the following principles:
（1） OLAP 系统完全没有必要绑定变量，那样只会带来负面的影响，比如导致SQL选择错误的执行，这个代价有时是灾难性的；让Oracle对每条SQL做硬分析，确切的知道谓词条件的值，这对执行计划的选择至关重要，这样做的原因是，在OLAP系统中，SQL硬分析的代价是可以忽略的，系统的资源基本上是用于做大的SQL查询，和查询比起来，SQL解析消耗的资源显得微不足道。所以得到一个最优的执行计划就非常重要。
（2） 在OLAP系统中，让Oracle确切地知道谓词的数值至关重要，它直接决定了SQL执行计划的选择，这样做的方式就是不要绑定变量。
（3） 在OLAP系统中，表，索引的分析显得直观重要，因为它是Oracle 为SQL做出正确的执行计划的信息的来源和依据，所以需要建立一套能够满足系统需求的对象分析的执行Job。
三．Bind peaking
先看一段官网的说明：
The query optimizer peeks at the values of user-defined bind variables on the first invocation of a cursor. This feature enables the optimizer to determine the selectivity of any WHERE clause condition as if literals have been used instead of bind variables.
To ensure the optimal choice of cursor for a given bind value, Oracle Database uses bind-aware cursor matching. The system monitors the data access performed by the query over time, depending on the bind values. If bind peeking takes place, and if the database uses a histogram to compute selectivity of the predicate containing the bind variable, then the database marks the cursor as bind-sensitive.
Whenever the database determines that a cursor produces significantly different data access patterns depending on the bind values, the database marks this cursor as bind-aware. Oracle Database switches to bind-aware cursor matching to select the cursor for this statement. When bind-aware cursor matching is enabled, the database selects plans based on the bind value and the optimizer estimate of its selectivity. With bind-aware cursor matching, a SQL statement with user-defined bind variable can have multiple execution plans, depending on the bind values.
When bind variables appear in a SQL statement, the database assumes that cursor sharing is intended and that different invocations use the same execution plan. If different invocations of the cursor significantly benefit from different execution plans, then bind-aware cursor matching is required. Bind peeking does not work for all clients, but a specific set of clients.
From：http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/optimops.htm#PFGRF94588
Bind Peeking是Oracle 9i中引入的新特性，它的作用就是在SQL语句硬分析的时候，查看一下当前SQL谓词的值，以便生成最佳的执行计划。 而在oracle 9i之前的版本中，Oracle 只根据统计信息来做出执行计划。
要注意的是，Bind Peeking只发生在硬分析的时候，即SQL被第一次执行的时候，之后的变量将不会在做peeking。我们可以看出，Bind peeking并不能最终解决不同谓词导致选择不同执行计划的问题，它只能让SQL第一次执行的时候，执行计划选择更加准确，并不能帮助OLAP系统解决绑定变量导致执行计划选择错误的问题。这也是OLAP不应该使用绑定变量的一个原因。
总结：
对于OLTP系统，相同的SQL重复频率非常高，如果优化器反复解析SQL，必然会极大的消耗系统资源，另外，OLTP系统用户请求的结果集都非常小，所以基本上都考虑使用索引。 Bind Peeking 在第一次获得了一个正确的执行计划之后，后续的所有SQL都按照这个执行计划来执行，这样就极大的改善了系统的性能。
对于OLAP系统，SQL执行计划和谓词关系极大，谓词值不同，可能执行计划就不同，如果采用相同的执行计划，SQL的执行效率必然很低。另外，一个OLAP系统数据库每天执行的SQL数量远远比OLTP少，并且SQL重复频率也远远低于OLTP系统，在这种条件下，SQL解析花费的代价和SQL执行花费的代价相比，解析的代价可以完全忽略。
所以，对于OLAP系统，不需要绑定变量，如果使用可能导致执行计划选择错误。 并且，如果用了绑定变量，Bind Peeking也只能保证第一条硬分析SQL能正确的选择执行计划，如果后面的谓词改变，很可能还是会选择错误的执行计划。 因此在OLAP系统中，不建议使用绑定变量。