转载自：https://blog.csdn.net/qq_34556414/article/details/80526243
等待事件: "db file sequential read" Reference Note (文档 ID 34559.1)
这种等待事件是一种IO读请求相关的等待。与”db file scattered read“不同，因为”sequential read“是将数据读到连续的内存(注意：这里指的是读到相连的内存，不是说读取的是连续的数据块。同时一次”scattered read“可以读多个块，将他们分散到SGA的不同buffer)。这一事件通常显示与单个数据块相关的读取操作(如索引读取)。如果这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题，可能没有正确的使用驱动表;或者可能说明不加选择地进行索引。
一次”sequential read“通常是单块读，尽管可能看到对于多个块的”sequential read“(见后面的描述)。这种等待也可能在数据文件头读取中看到(P2=1表明是读取文件头)。
ORACLE进程需要访问block不能从SGA中获取的时候，因此oracle进程会等待block从I/O读取到SGA；
一个顺序读是一个单块读,单块I/O一般来自索引读的结果；
db file sequential read等待事件有3个参数：
P1: The absolute file number 文件号
P2: The block being read first block＃
P3: The number of blocks (should be 1) block数量
db file sequential read等待时间是由于执行对索引，回滚（undo）段，和表（当借助rowid来访问），控制文件和数据文件头的单块读操作SQL语句（用户和递归）引起的。对于这些对象的物理I/O请求是很正常的，因此db file sequential read等待的存在不是一定意味库或应用出错了。如果会话在这事件上花了好长事件，它可能也不是一个糟糕的事情。相反，如果会话花了大量时间在equeue或latch free上，那么一定是有问题。
db file sequential read是个非常常见的 I/O 相关的等待事件，通常显示与单个数据块相关的读取操作， 在大多数的情况下， 读取一个索引块或者通过索引读取一个数据块时，都会记录这个等待。
这个等待事件有 3 个参数 P1、 P2、 P3，其中 P1 代表 Oracle 要读取的文件的绝对文件号， P2 代表 Oracle 从这个文件中开始读取的起始数据块块号， P3 代表读取的 BLOCK数量，通常这个值为 1，表明是单个 BLOCK 被读取。
select name,parameter1,parameter2,parameter3 from v$event_name where name='db file sequential read';
NAME PARAMETER1 PARAMETER2 PARAMETER3
----------------------- ---------------- ---------- ----------
db file sequential read file# block# blocks在 Oracle 10g 中，这个等待事件被归入 User I/O 一类：
select name,wait_class from v$event_name where name='db file sequential read';
NAME WAIT_CLASS
---------------------------------------- ----------------------------------------------------------------
db file sequential read User I/O图 9-16 简要说明了单块读取的操作方式。
如果这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题，没有正确地使用驱动表；或者可能索引的使用存在问题，并非索引总是最好的选择。 在大多数情况下，通过索引可以更为快速地获取记录，所以对于一个编码规范、调整良好的数据库，这个等待事件很大通常是正常的。 有时候这个等待过高和存储分布不连续、连续数据块中部分被缓存有关，特别对于 DML 频繁的数据表，数据以及存储空间的不连续可能导致过量的单块读，定期的数据整理和空间回收有时候是必须的。
需要注意在很多情况下，使用索引并不是最佳的选择，比如读取较大表中大量的数据，全表扫描可能会明显快于索引扫描，所以在开发中就应该注意，对于这样的查询应该进行避免使用索引扫描。
从 Oracle 9iR2 开 始 ， Oracle 引 入 了 段级统计信息收集的新特性，可以通过查询V$SEGMENT_STATISTICS视图，找出物理读取显著的索引段或者是表段， 研究其数据结构，看能否通过重建或者重新规划分区、存储参数等手段降低其 I/O访问。
Oracle 9iR2 中，收集的统计信息共有 11 类
SYS@fgdb> select * from v$segstat_name;
STATISTIC# NAME SAM
---------- ---------------------------------------- ---
0 logical reads YES
1 buffer busy waits NO
2 gc buffer busy NO
3 db block changes YES
4 physical reads NO
5 physical writes NO
6 physical read requests NO
7 physical write requests NO
8 physical reads direct NO
9 physical writes direct NO
11 optimized physical reads NO
12 optimized physical writes NO
13 gc cr blocks received NO
14 gc current blocks received NO
15 ITL waits NO
16 row lock waits NO
18 space used NO
19 space allocated NO
21 segment scans NO
19 rows selected.在 Oracle 11gR2 中，这类统计信息增加为21个（10g中可能是15个）：
SYS@fgdb> select * from v$segstat_name;
STATISTIC# NAME SAM
---------- ---------------------------------------- ---
0 logical reads YES
1 buffer busy waits NO
2 gc buffer busy NO
3 db block changes YES
4 physical reads NO
5 physical writes NO
6 physical read requests NO
7 physical write requests NO
8 physical reads direct NO
9 physical writes direct NO
11 optimized physical reads NO
12 optimized physical writes NO
13 gc cr blocks received NO
14 gc current blocks received NO
15 ITL waits NO
16 row lock waits NO
18 space used NO
19 space allocated NO
21 segment scans NO
19 rows selected.
对于 CBO 模式下的数据库，应当及时收集统计信息，使 SQL 可以选择正确的执行计划，避免因为统计信息陈旧而导致的执行错误等。
问题：AWR报告中的系统的等待事件中的db file sequential read是否合理？
根据awr报告中的以下重要参数进行解读，以11G的awr报告为例子：
说明：db file sequential read是指sga中找不到相应的数据，所以跟buffer hit有很大的关系，当buffer hit命中率太低了，相应的db file sequential read就会高，一般buffer hit保持着95%以上；
查看这个报告的db file sequential read的总时间和平均时间；
Foreground Wait Events也会统计db file sequential read所花费的时间和平均时间
根据SQL User I/O等待时间，查看是否有调优的空间；
db file sequential read的优化方法：
从读取开始，增加SGA中buffer cache的大小，避免每次都从硬盘中去读数；
优化sql语句，减少不必要的块读取；
