参数与索引I/O的代价有关，而和全表扫描并无关系，这与Tom所说的并不矛盾，
不过显然更精确一点。
最后我们其实应该看到，虽然有如上所说的代价变化问题，
同一访问路径下实际的运行性能并无区别，由于数据量比较小，上面的例子也许不能很好的说明这一点，
不过想想Oracle用相同的路径去执行，也没有理由不同性能吧。
OPTIMIZER_INDEX_CACHING值为0,值越大,系统越tendence去用nested loops .
Find out what values the sessions are running with. Up to Oracle9i Database,
this information could only be obtained by tracing the sessions with the trace
event 10053 at level 1 and examining the trace files. In Oracle Database 10g,
this is as simple as querying the V$SES_OPTIMIZER_ENV view.
可以通过10053事件查看SESSION相应的OPTIMIZER_INDEX_COST_ADJ 和OPTIMIZER_INDEX_CACHING值是多少,
在10g中省不了事,直接查V$SES_OPTIMIZER_ENV视图就可以了,下面的是例子:
select * FROM V$SES_OPTIMIZER_ENV WHERE NAME=LOWER('OPTIMIZER_INDEX_COST_ADJ') or
name=lower('OPTIMIZER_INDEX_CACHING');
SID ID NAME ISDEFAULT VALUE
--------------------------------------------------------
144 67 optimizer_index_caching YES 0
145 66 optimizer_index_cost_adj YES 100
145 67 optimizer_index_caching YES 0
因为oracle的optimizer依赖于表与索引的statistics,所以要确保现在的statistics能够代表现有数据,
不正确的statistics会让optimizer 产生低效的执行计划,当然statistics也不必天天更新,因为这样的话,
执行计划就也会天天更新,这对性能问题的分析会产生干扰
System-Level Diagnosis
V$SYSTEM_EVENT视图为系统级别的诊断提供数据,基中AVERAGE_TIME和TIME_WAITED与I/O相关事件关联
记住TIME_WAITED只是记录自实例启动以来的记录,当实例运行比较长的一段时间后,db file sequential read
通常较高.当然,经常查询V$SYSTEM_EVENT并且以TIME_WAITED排序,能够通过相互比较而找到比较明显的等待事件.
当db file sequential read 不位于top five时,不要担心,因为可能有更大的问题要去发现
当db file sequential read 位于top five时,也总能说明数据库进行了大量的single-block读.
这里可以看系统级别的诊断能力是非常受限的.但事件总是两面情,这里却可以看系统硬件上瓶颈
这在v$session_wait事件里可是看不到的.当你想升级系统,可是你的直接上司要求你提供系统瓶颈报告时,
下面就是那个好办法:
select a.event,
a.total_waits,
a.time_waited,
a.time_waited/a.total_waits average_wait, 这里的average_wait是很用的
sysdate – b.startup_time days_old
from v$system_event a, v$instance b
order by a.time_waited;
当average single-block读超过你所定的阀门的时候,你要看看I/O子系统是不是得到优化了.
当然用操作系统的I/O控制命令(iostat,vmstat)去监控硬盘,可以发现I/O的瓶颈,
可以去评估各I/O子系统之间是不是平衡.
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
dev8-0 3.93 17.03 34.66 54592552 111099454
dev8-1 12.08 56.68 99.93 181659920 320286944
dev8-2 23.38 194.11 189.93 622154550 608747464
dev8-3 16.00 230.43 128.04 738570544 410383416
dev8-4 4.73 59.89 80.98 191965458 259557752
通过上例,可以看到dev8-2,dev8-3的块读写是远远超过其它的,所以可以考虑平衡一下I/O
另外,除了从V$SYSTEM_EVENT视图中进行系统级别的db file sequential read average wait之外,
oracle也提供了另外一个视图v$filestat来获取single-block读的统计数据.
select a.file#,
b.file_name,
a.singleblkrds,
a.singleblkrdtim,
a.singleblkrdtim/a.singleblkrds average_wait
from v$filestat a, dba_data_files b
where a.file# = b.file_id
and a.singleblkrds > 0
order by average_wait;
FILE# FILE_NAME SINGLEBLKRDS SINGLEBLKRDTIM AVERAGE_WAIT
----- ----------------------------- ------------ -------------- ------------
367 /dev/vgEMCp113/rPOM1P_4G_039 5578 427 .076550735
368 /dev/vgEMCp113/rPOM1P_4G_040 5025 416 .08278607
369 /dev/vgEMCp113/rPOM1P_4G_041 13793 1313 .095193214
370 /dev/vgEMCp113/rPOM1P_4G_042 6232 625 .100288832
371 /dev/vgEMCp113/rPOM1P_4G_043 4663 482 .103366931
372 /dev/vgEMCp108/rPOM1P_8G_011 164828 102798 .623668309
373 /dev/vgEMCp108/rPOM1P_8G_012 193071 125573 .65039804
374 /dev/vgEMCp108/rPOM1P_8G_013 1