定义：
这表示等待一个I/O读取请求完成。与“db file scattered read”不同，“db file sequential read”将数据读入连续的内存（而“scattered read”读取多个块并将其分散到SGA中的不同缓冲区）。顺序读取通常是单块读取，尽管也可能看到多个块的顺序读取（见P3）。此等待事件还可能出现在从数据文件头读取时（P2=1表示文件头读取）。
「参数：」
P1 = 文件号
P2 = 块号
P3 = 块数
「file#」：这是Oracle尝试读取的文件号。从Oracle8开始，它是绝对文件号（AFN）。
「block#」：这是Oracle开始读取块的文件中的起始块号。通常只读取一个块。
「blocks」：此参数指定Oracle尝试从文件号开始读取的块数。通常为“1”，但如果P3 > 1，则这是一个多块读取。早期Oracle版本在从排序（临时）段读取时可能会看到多块“db file sequential read”。
等待时间：
I/O通常作为单个I/O请求发出到操作系统——等待会一直持续到I/O请求完成。请注意，Oracle对操作系统的读取请求可能会从操作系统文件系统缓存中满足，因此等待时间可能非常短。
全系统范围的等待：
I/O是正常活动，所以您真正感兴趣的是不必要或缓慢的I/O活动。如果等待I/O的时间显著，那么我们可以确定Oracle必须访问哪些段。请参阅AWR（或STATSPACK）报告的“Tablespace IO”和“File IO”部分，以及ADDM和ASH输出，以获取服务最多I/O请求的表空间/文件的信息，并指示I/O子系统的速度。如果等待读取的时间显著，那么确定Oracle执行读取的段会很有帮助。通过查看V$FILESTAT，可以找到发生读取的文件。
请参阅AWR报告的“Top SQL by Disk Reads”部分，寻找引起高I/O的SQL线索。
查看哪些会话正在执行读取并追踪它们，以确定I/O是否是预期的，这也很有用。可以使用以下语句查看哪些会话值得追踪：
SELECT sid, total_waits, time_waited
FROM v$session_event
WHERE event='db file sequential read'
AND total_waits>0
ORDER BY 3,2;
还可以查看：
V$SQL中具有高磁盘读取的语句——显示在AWR报告的“Top SQL by Disk Reads”部分。
V$SESSTAT中具有高“physical reads”的会话。
减少等待/等待时间：
块读取是相当不可避免的，所以目标应该是尽量减少不必要的I/O。通过良好的应用程序设计和高效的执行计划可以最好地实现这一目标。执行计划的更改可以带来数量级的性能变化。在系统级别进行微调通常只能实现百分比的增益。以下几点可能有所帮助：
检查使用不选择性索引扫描的SQL
较大的缓冲区缓存可能会有所帮助——通过实际增加Parameter:DB_CACHE_SIZE（或Parameter:DB_BLOCK_BUFFERS如果仍在使用）来测试这一点。永远不要增加SGA大小，如果可能导致系统中的额外分页或交换。
一个不太明显的问题是数据在物理上的聚集程度如何。例如：假设您通过索引扫描从表中频繁获取某一列在两个值之间的行。如果每个索引块中有100行，则两种极端情况是：
每个表行在不同的物理块中（每个索引块需要读取100个块）
表行全部位于几个相邻的块中（每个索引块需要读取少数几个块）
预排序或重新组织数据可以帮助解决严重情况下的问题。
查看是否可以使用分区来减少需要查看的数据量。
将经常进行索引扫描的文件放在某种形式的缓存缓冲磁盘上会有所帮助。例如：闪存缓存或硬件磁盘缓存。对于非ASM数据库，将此类数据文件放在具有操作系统文件系统缓存的文件系统上。这可以使Oracle的一些读取请求从缓存而不是实际磁盘I/O中满足。
总结
希望本文能帮助你深入理解和优化 db file sequential read
等待事件，为你的数据库性能调优工作提供有价值的参考。如果你对本文内容有任何疑问或建议，欢迎在评论区留言。别忘了点赞、收藏，并分享给你的小伙伴们哦！
「欢迎关注我们的公众号，获取更多技术分享与经验交流。」
