等待事件db file sequential read

等待事件说明

这个等待事件表示对一个IO 读请求完成的等待。这个调用不同于 "db file scattered read" ，顺序读将数据读取到连续内存中，而分散读将读取多个数据块，并将他们分散到 SGA 中的不同缓冲区中。顺序读通常是单块读，有时候也可以看到多个块的顺序读。

这个IO 是一个正常的活动，所以我们需要注意的是不必要或缓慢的 IO 活动。如果等待 IO 的时间很长，那么我们可以确定 Oracle 需要访问磁盘的那个段的速率。具体需要参考 AWR 报告中的“ Tablespace IO ”和“ File IO ”，以及 ADDR 和 ASH 的输出，以获得哪些表空间 / 文件正在服务最多的 IO 请求的信息，并获得 IO 子系统的速度指示。如果等待读的时间很长，那么需要判断 Oracle 正在哪个段上执行读操作。发生读操作的文件可以通过查看 v$filestat 找到。还需要参考 AWR 中“ SQL ordered by Reads ”，了解 SQL 导致高 IO 的线索。还可以查看哪些会话正在执行读操作，并跟踪它们以查看是否需要 IO 。这个语句可以用来查看哪些会话需要跟踪

SQL> SELECT sid, total_waits, time_waited

FROM v$session_event

WHERE event='db file sequential read'

and total_waits>0

ORDER BY 3,2;  

解决方法

数据块的读取是不可避免的，所以我们的目标应该是最小化不必要的IO 。这个可以通过改良应用程序和执行计划来实现。对执行计划的更改可能会导致性能的显著变化。系统级别的调整只能获得百分比的增益，可以参考以下几点：

- 检查 SQL ，使用非选择性 index scan

- 可以增大 buffer cache ，通过实际增加参数“ DB_CACHE_SIZE ”，不要增加 SGA 的大小，这可能会导致系统出现额外的分页和交换

- 影响 IO 速率的一个不太明显的问题，就是在数据块存放的好坏程度。假设你经常通过索引扫描一个表，这个表要扫描的列在两个值之间。如果每个索引块中有 100 行，那么两个极端就是：

1）  每个表行位于不同的物理块中（每个索引块需要读取100 个块）

2）  表中的所有行都在几个相邻的数据块中（每个索引块需要读取几个块）

这种情况下，预先排序或重新组织数据可以帮助在严重的情况下解决这个问题。

- 看看是否可以使用分区来减少需要查看的数据量

- 对于非基于 ASM 的数据库，将这些数据文件放在带有 O/S 文件系统缓存的文件系统上，这可以让一些 Oracle 读请求从缓存读（逻辑 IO ）而不是从真正的磁盘 IO 读（物理 IO ）。

---- end ----