接着对oracle性能调整记载（二）

Disk_asynch_io，dbwr_io_slaves和异步I/O

异步I/O是线程发送一个I/O请求到内核，然后就可以处理其他的事情了，内核完成I/O请求后，将会通知线程I/O操作完成。

同步I/O是线程发送一个I/O请求到内核就进入等待状态，知道I/O操作完成后才继续执行别的事情。

Dbwr_io_slaves主要用于模拟异步环境，DB_WRITER_PROCESSES,和DBWR_IO_SLAVES是有区别的。DB_WRITER_PROCESSES生成多个DBWR进程；而DBWR_IO_SLAVES生效时，只有一个DBWR进程，仅当系统需要时，才生成多个DBWR从属进程。（默认dbwr_io_slaves为0，可见一般不使用此参数）

disk_asynch_io默认是true开启异步I/O，这样可以大幅度提高性能，可以有效的减少free buffer wait事件，不过需要你的系统支持异步I/O，不然即使设置true异步I/O也没有生效，可以对比一下在disk_asynch_io参数为true和false分别查询v$system_event中的db file parallel write事件的average_wait时间。

Free buffer waits事件：

这里简单说明下free buffer waits也就是在cache buffer中找不到空闲可用的buffer，使得session的进程处于free buffer waits，而oracle此时已经在进行dbwr清理脏块数据到数据文件了。

1 buffer cache太小

2 dbwn进程写速度慢或触发不快，或没有足够的dbwn进程

3 系统的硬件存在问题，I/O慢

对系统的磁盘性能，dbwn的数量和buffer cache大小着手！

Optimizer_index_caching和optimizer_index_cost_adj

Optimizer_index_caching缺省值为0，代表索引块在buffer cache中的平均百分比，0认为缓存区没有索引块，100认为全在缓存区中，一般缺省值是不合适的，在OTLP事务处理系统中，用接近于高速缓存命中率的某个值开始调整，查看对系统的影响。

Optimizer_index_cost_adj缺省值为100，也就是执行单个I/O（索引读取）的成本与全表扫描中多块I/O读取的成本百分比，在10G中范围是1~10000，缺省值100则认为是多块I/O读取的成本与单块索引I/O的读取成本相同，而很多情况索引成本是明显优于全表扫描的多块读取，cbo是按照oracle所计算的最低成本来选择cos最小的执行计划，所以这两个参数会影响cbo的cost计算，进而影响执行计划。

一般而言这两个参数:数据仓库optimizer_index_caching = 0 optimizer_index_cost_adj = 100

OLTP中optimizer_index_caching=90 optimizer_index_cost_adj在30~50之间。但是实际的取值还是要参照系统业务查看，在v$system_event表中对db file sequential reads/scattered reads进行比较

Select event,average_wait from v$system_event where instr(event,’db file s’)>0

语句顺序读取index range scan和离散读full table scan的等待值。

Recovery_parallelism并行恢复

Recovery_parallelism为并行恢复所用的进程数，0和1都是单进程恢复。

Fast_start_parallel_rollback并行回滚：

Fast_start_parallel_rollback执行并行回滚时进程的最大数量。

False：禁止并行回滚

Low：2*cpu个进程数

High：4*cpu个进程数

并行回滚会加快恢复的进度，但是在并行回滚过程中会启动很多slave进程，占用大量cpu，因此这个参数也默认是low（不过如果已经进行并行回滚又设置fast_start_parallel_rollback=false，很有可能导致系统hold住！）

Cursor_sharing参数(此参数没有很透彻的理解，也就只能简单说一下)

在10G中默认是exact，该参数有force simlar和exact三个取值。

Force是sql中一些不同，但是其他方面都相同，共享一个游标除非不同的地方影响语句含义。（cursor_sharing为force对histograms影响最大的。）

Simlar是某些不同，但其他方面都相同，共享一个游标，除非不同的地方影响了语句的含义或者执行计划. (CBO有可能要做很多的重新优化。更严重的问题在于cursor_sharing=similar会导致同样的SQL（除了绑定变量的值不一样之外）在library cache里面拥有很多不同的执行计划，因为我们知道一个SQL下面的所有执行计划都是被一个latch保护的，所以cursor_sharing=similar会导致更严重的latch 争用。)

Exact只使具有相同的sql共享相同的游标。

[@more@]