db file sequential read等待事件

这个等待事件通常是由i/o等待造成的。

首先我们可以通过v$session_wait视图找到该等待。其中，

p1：oracle要读取的数据文件的文件号。

p2：oracle从这个文件中开始读取的block号。

p3：oracle从这个文件开始读取的block号后读取的block数量。

解决方案一：在v$sqlarea中找到物理读多的语句进行优化。

                        select sql_text,disk_reads

                         from  (select sql_text,disk_reads from v$sqlarea order by disk_reads desc)

                        where rownum<21;

                        优化这些语句以减少i/o

                        如果有index range scans但缺走了不该走的索引，就会造成访问更多的block，这时应该强迫使用一个可访问的索引。

                        如果索引的碎片较多(index_stats可以查看)，那么每个block存储的索引数据就比较少，这就需要访问的block就多，这是可以重建索引，减少碎片。（详情请见另一片关于索引管理的文章）

                       atler index index name rebuild.

                       如果被使用的索引存在一个很大的cluster factor,那么对于每个索引块要获取相应的记录时就需要访问更多的block。这是可以执行一下语句：

                      create table tablename as select * from orienttablename order by 索引列;

方案二：从v$filestat视图中找到访问比较频繁的数据文件，把它放到能实现负载平衡的raid磁盘上。

利用

select * from v$segment_statistics where statistic_name='physical reads' order by value desc;

方案三：可以增大db_block_buffers或者把常用对象放到keep_buffer_pool.

示例：

找到发生等待的对象：

由此我们发现实在nc_steel_info这张表上发生了等待，发生等待的分区是p_2007.

现在我们可以通过上述方法优化。也可以找到访问nc_steel_info表的语句优化。 有几种方法找到

bad sql

(1) 根据v$session中的sid找

 SELECT  /*+ ORDERED */

 2          sql_text

 3     FROM v$sqltext a

 4    WHERE (a.hash_value, a.address) IN (

 5             SELECT DECODE (sql_hash_value,

 6                            0, prev_hash_value,

 7                            sql_hash_value

 8                           ),

 9                    DECODE (sql_hash_value, 0,

prev_sql_addr,

sql_address)

 10               FROM v$session b

 11              WHERE b.sid=234)

 12 ORDER BY a.piece ASC;

(2) 如上所术直接找到物理i/o多的sql进行优化。

(3) 可以从v$sql_plan中找到全表扫描的sql进行优化。