Oracle 9与Oracle 8中CPU_COSTING有什么变化?
Oracle 9与之前的Oracle 7和8中CPU_COSTING有什么变化?
Oracle 9 引入了一套更精细和全面的代价机制。这是对Oracle 7/8版的重大改进,但我认为这一改变类似从基于规则转变至基于代价。如果你不理解它是如何运作的,你会看到奇怪的事件。
你可以用dbms_stats包收集一段适当的时间内的系统统计,以此来激活CPU_COSTING。
假定的CPU速度(MHz)
单块读时间(ms)
多块读时间(ms)
一般达到的多块读
这些数字可产生三个主要效用:
Oracle并不假定单块读与多块读一样昂贵,它知道相对速度。这大致与根据数据库文件xxxx读取的平均等待时间设置参数optimizer_index_cost_adj相同――由于Oracle现在认为表扫描比原先理解更昂贵,这将鼓励Oracle使用索引访问路径而不是表扫描。
其次,Oracle将使用“达到的”(achieved)平均多块读取数来计算扫描一张表所需的读请求数,而不是使用一个db_file_multiblock_read_count的调整值。由于很多人使用的db_file_multiblock_read_count值并不合适,这样就造成Oracle可能增加表扫描(和索引快速全扫描)的代价,并由此减少表扫描(和索引快速全扫描)的可能性。注意――记录的值是用于计算的,当真正进行扫描时,Oracle会尝试使用init.ora中的值。
最后,Oracle知道(例如)to_char(日期列)=字符值的CPU代价比数字列=数值要打,所以Oracle可能修改索引的选择,若使用一个有更小选择性的索引的连续读代价(consequential cost)低于CPU的使用代价,则会选择这一索引。(另外,Oracle将重新安排非访问(non-access)的谓词顺序来减小CPU代价,但在多数情况下不会察觉性能的差异。)
总之――这肯定是一个好事。事实上,你可以发现对索引访问路径更强的偏好,这将影响性能。