OPTIMIZER_INDEX_COST_ADJ与成本计算

eygle · 发表于 2004-6-29 10:29

最初由 Fenng 发布
[B]只介绍这个参数而不提db_file_multiblock_read_count

有些可惜阿 [/B]

db_file_multiblock_read_count 这个参数打算单独说一说
绕在一起就复杂了

grassbell · 发表于 2004-7-10 18:36

最初由 biti_rainy 发布
[B]
另，其实关于这个参数，兴许大多情况下根据 system event 数据来调整可能是合理的(这个没检验过，但单个例子一定是不合理的)，但，这一定是可能有偏差的

因为 sql 总是复杂多样的，并且 sql 选取的数据的百分比也是变化的，还有就是 FTS 的成本跟很多因素有关，综合起来总是很困难的 [/B]

恩，eygle的例子可以让我们明白这个参数的原理。我们也知道这种方法只针对在这个表上的这条特定的sql起作用。biti_rainy提到兴许可以根据system event 数据来调整。原文中也提到，

SELECT EVENT,AVERAGE_WAIT
FROM V$SYSTEM_EVENT
WHERE EVENT LIKE ‘db file s%’;

EVENT AVERAGE_WAITS
========================= ==============
db file sequential reads .33178629
db file scattered reads 2.190087

这样就可以得到optimizer_index_cost_adj =0.33/2.1*100=15，对于这一点，我一直有点迷惑。

帮帮讲讲作者的意图好吗？

grassbell · 发表于 2004-7-13 19:19

这个问题有点若，但是困扰我很长时间了。
望能解惑焉。。。

xsb · 发表于 2004-7-15 14:03

如果没有针对CBO优化DB，定期进行分析可能有背于性能提高。
CBO在oracle眼里认为是优点多多，而且前提是要周期性地收集统计信息，于是好多情形下许多应用定期进行了统计信息的收集。
然而事实是作了统计分析后，对某些多表关联查询的性能却有了显著的下降，原本是索引扫描全变成了全表扫描，加了rule提示后速度明显加快或者删除统计信息后性能恢复正常。

于是定期收集统计信息让人产生疑惑！
看来如果不是有高人作全面的CBO优化，统计信息的定期收集还是要慎重啊！！！

eygle · 发表于 2004-7-15 22:27

在没有充分认识和技术准备就贸然转向CBO,显然是不明智的.

biti_rainy · 发表于 2004-7-16 09:06

最初由 grassbell 发布
[B]

恩，eygle的例子可以让我们明白这个参数的原理。我们也知道这种方法只针对在这个表上的这条特定的sql起作用。biti_rainy提到兴许可以根据system event 数据来调整。原文中也提到，

SELECT EVENT,AVERAGE_WAIT
FROM V$SYSTEM_EVENT
WHERE EVENT LIKE ‘db file s%’;

EVENT AVERAGE_WAITS
========================= ==============
db file sequential reads .33178629
db file scattered reads 2.190087

这样就可以得到optimizer_index_cost_adj =0.33/2.1*100=15，对于这一点，我一直有点迷惑。

帮帮讲讲作者的意图好吗？ [/B]

db file sequential reads --------  往往象征(不是等价于)了索引扫描的等待

db file scattered reads  ---------  象征了FTS（不是等价于）的等待

由于 optimizer_index_cost_adj  是一个衡量索引与全表扫描之间的分界点的平衡参数，于是，假定现在全表扫描产生的等待  就是其  cost ，假定索引查询的等待就是其 cost 。在系统级来观察，近似地认为就是这两个事件来衡量系统的这个参数。

optimizer_index_cost_adj =  100  的时候，观察系统的这两个等待事件，就可近似的认为：

全表扫描的代价 :  索引扫描的代价  =  db file scattered reads  : db file sequential reads

针对当前系统的事实，optimizer_index_cost_adj  本质上就是为了描述  索引扫描成本占全表扫描的成本的百分比。这个值越接近真实，则越能更好地给优化器提供选择执行计划的依据。所以正好可以参考下面的计算来设置这个值

optimizer_index_cost_adj =  索引扫描代价 / 全表扫描代价 = file sequential reads  / db file scattered reads

注意这里的这个等式的含义和 eygle文章中  的优化器选择的表达式并不是矛盾的，表达了不同的含义。这里是要设置的数据，使得和系统真实状况尽力一致，他那里是利用这个设置好的参数来评估  执行计划的选择