常见Oracle Wait Event详解.docx

常见Oracle Wait Event详解1、log file sync???? 当commit发生时，会产生log file sync.减少commit频率，加快redo的写速度来改善此等待。另外也需要考察IO子系统的配置是否存在问题，例如可以考虑将redo log file 与数据文件分开存放，并将redo log file放到raw device上面2、db file sequential read参考：/Doc/oracle_IO%286%29.htm???? 这个事件是是最常见的IO等待事件。它一般发生在读取单独数据块时，如读取索引数据块或者通过索引访问一个表数据块，另外在读取数据文件头数据块时也会发生db file sequential read等待事件。当发现这个等待事件成为系统等待事件中的主要事件，我们可以通过一下方法来处理??? ??? 1）Top SQL从statspack或者awr报告中的“SQL ordered by Reads”部分或者通过V$SQL视图找出系统中的Top SQL，对SQL进行调优以减少IO请求。???? 1.1）当SQL中存在Index Range Scan时，如果访问的索引的选择性不好就会导致需要访问过多的数据块，这时可以通过建立一个、或强制SQL使用一个已经存在的选择性更好的索引。这样使我们访问更少的数据块来获取到需要的数据??? 1.2）如果索引存在碎片，那每个索引数据块上的索引数据就更少，会导致我们需要访问更多的索引数据块。这时，我们需要考虑重建索引来释放碎片；判断一个所以是否需要重建，我们介绍一个简单的方法：对一个索引进行结构分析后，如果该索引占用超过了一个数据块，且满足以下条件之一：B-tree树的高度大于3；使用百分比低于75%；数据删除率大于15%，就需要考虑对索引重建：SQL analyze index t_test1_idx1 compute statistics;?Index analyzed.?SQL analyze index t_test1_idx1 validate structure;?Index analyzed.?SQL select btree_space, -- if 8192（块的大小）? 2???????? height, -- if 3? 3???????? pct_used, -- if 75? 4???????? del_lf_rows/(decode(lf_rows,0,1,lf_rows)) *100 as deleted_pct -- if 20%? 5? from index_stats;??? ???? 1.3）如果使用的索引的聚簇因子（Clustering Factor）很大，说明一条索引记录指向多个数据块，在返回结果时需要读取更多的数据块。通过重建表可以降低聚簇因子，因而可以在查找索引时减少表数据块的访问块数。参考：/rootq/archive/2008/10/24/1319090.htmlSELECT??????? A.INDEX_NAME,??????? B.NUM_ROWS,??????? B.BLOCKS,??????? A.CLUSTERING_FACTORFROM??????? USER_INDEXES A,??????? USER_TABLES BWHERE??????? A.INDEX_NAME = ???????? AND A.TABLE_NAME = B.TABLE_NAME??? 对索引进行分析后，我们可以从视图DBA_INDEXES中获取到索引的聚簇因子，字段名为Clustoring_Factor。如果一个索引是一张表主要被使用的索引（或者是该表的唯一索引），且它的聚簇因子过高导致IO请求过高的话，我们可以考虑采取以下措施来降低IO：（1)以索引字段的顺序重建表以降低聚簇因子，可以用以下语句重建表（当然，你还需要重建触发器、索引等对象，还可能需要重建、重新编译有关联对象）： CREATE new_table AS SELECT * FROM old_table ORDER BY A;（2)建立基于索引字段IOT（索引表）。create index t_test1_idx3 on t_test1(owner, status) compute statistics;??? 1.4）通过分区裁剪（partition pruning）技术来减少的SQL对数据块的访问。??? 2）处理非SQL导致的IO问题???? 如果从statspack或者AWR报告中找不到明显产生db file sequential read事件的SQL，则该等待事件可能是由于以下原因导致的：2.1）热点数据文件或磁盘SQL