Oracle开发技术：[Oracle]变量绑定

[Oracle]变量绑定

　　Parent-Child cursor (父子游标)

　　父游标：只要SQL语句文本相同，它们就对应同一个parent cursor。

　　子游标：在某些情况下，虽然SQL语句的文本相同，但是因为其它因素不同(这些因素可以在视图V$SQL_SHARED_CURSOR中查看)，导致产生不同的child cursor。(重新生成child cursor，也就意味着一次硬解析)

　　cursor_sharing

　　对于是否使用绑定变量这个问题，最好是交给应用程序决定，在数据库层面是很难正确判断。(这也是为什么cursor_sharing参数默认值为exact)

　　但是，有些时候，由于应用程序没有正确使用绑定变量，导致数据库性能问题，又因为此时系统已上线，要改应用代码有很多的阻力(大多都是人为的因素)。为此，Oracle提供了应急(事后补救)方案，可以在数据库级别强制使用绑定变量。

　　当cursor_sharing=force时，对于只有谓词条件不一样的SQL语句，Oracle统统都认为是一样的。但是这样会有一个问题，就是可能后续的执行计划不是最优。为了解决这个问题，可以设置cursor_sharing=similar，这样如果谓词条件的变化可能生成不同的执行计划，Oracle都会进行硬解析(生成child cursor)。

　　但是，设置cursor_sharing=similar要非常小心，因为有很多bug，需要经过充分的测试才能在生产库上修改。

　　Bind Peeking (变量窥视)

　　从Oracle9i开始，Oracle在第一次解析SQL(hard parse)时，如果SQL上有变量绑定，会查看这个变量的值，以便于更准确的指定执行计划;但在后续的分析中(soft parse)，将不会理会这个变量的值。

　　适用场景

　　执行计划几乎不改变(oltp)

　　大量的并发

　　大量的除谓词外几乎相同的SQL。

　　不适用场景

　　执行计划会随变量值的变化而改变。

　　少量的SQL(OLAP).

　　ACS (Adaptive Cursor Sharing)

　　Oracle11g用于解决变量绑定带来的负面影响，通过不断观察bind的值，来决定新的SQL是否重用之前的执行计划，解决绑定变量导致后续执行计划不变的问题。

　　缺点

　　更多的硬分析

　　产生更多的子游标，需要更多的内存。

　　消耗更多的CPU

　　绑定变量的适用场景

　　适用于OLTP

　　用户并发很高

　　表中有主键

　　操作的数据少

　　执行计划稳定

　　SQL的重复率高

　　不适用于OLAP

　　执行计划多变

　　并发用户少

　　SQL解析对系统性能影响小