关于Oracle9i的Peeking of User-Defined Bind Variables

eygle

最初由 sansanmei 发布
[B]你应该把两次
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#,
sample_size, minimum, maximum, distcnt, lowval, hival, density, col#,
spare1, spare2, avgcln
from
hist_head$ where obj#=:1 and intcol#=:2
具体的值列出来给大家看一下,看看为什么oracle会选择不同的计划 [/B]

为什么会选择不同的执行计划?
我想这个是显而易见的!

sansanmei

当发生peeking的时候，plan被重用，但为什么这时候hard parse还是照样增加

biti_rainy

最初由 sansanmei 发布
[B]当发生peeking的时候，plan被重用，但为什么这时候hard parse还是照样增加 [/B]

peeking 是指 产生执行计划的时候去 看 这个值

而不是先peeking 再决定是否重用执行计划！

biti_rainy

test

eygle

最初由 biti_rainy 发布
[B]test [/B]

d.c.b.a

值得学习，可以用于性能调整中。

grassbell

好像还没有定论

biti_rainy

这个功能直接的影响就是 即使bind var了，对象的分析也可能导致执行计划的变化
比如我这里遭遇的这个问题，就是这个原因导致的

http://blog.itpub.net/post/330/2230

wing hong

Tom Kyte in his "Effective Oracle by Design" book also have a section to talk about the bind variable peeking feature. In essance, optimizer will peek the value when it hard parse the query.

And since it is bind variable, so the optimizer only hard parse once. and therefore the peeking only happens in the first time.

And therefore depends on the value optimizer first see it, the plan may be different, That was what biti_rainy experienced .

But Tom kyte also gave some interesting use of this feature in his book too .

hanjs

这个主要是说明什么问题呢？