Resolving Issues Where Application Queries are Waiting Too Frequently for 'db file sequential read'

本文详细介绍了如何诊断和解决数据库中'dbfilesequentialread'操作频繁等待的问题,包括识别问题、采集相关报告、分析查询性能、优化SQL语句等步骤,以提高数据库整体性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

昨天有篇“db file sequential read”的介绍,还有一篇类似的:Resolving Issues Where Application Queries are Waiting Too Frequently for 'db file sequential read' Operations (文档 ID 1475825.1)


诊断“db file sequential read”的步骤

简述

低效的SQL会引起不同节点间非常多的块读。


问题确认

花费在本地数据库的active时间非常明显。

仅一些session,查询或job变慢(不是整个数据库)。

“db file sequential read”等待是整个DB time中占比最大的组件。

“db file sequential read”等待操作不慢(IO的平均时间没超过标准IO性能(例如少于20毫秒))。


等待“db file sequential read”操作太频繁的应用查询

等待“db file sequential read”事件指的是一个session正在等待一次从磁盘读到内存的单块读以满足查询的要求。

假设完成一次IO操作的平均时间是正常的(例如单次IO花费时间少于20毫秒),那么相比于单次IO操作的时间,花费在“db file sequential read”的总时间必须降到与IO次数相匹配。

如果“db file sequential read”等待次数太多,单条SQL又极消耗资源,那么这些查询的确可能需要调优以选择一种更能接受的执行路径,减少资源消耗。

为了确定哪些查询等待“db file sequential read”最多,需要采集与AWR报告相同时间段的ASH报告。在报告中,查找等待次数最多的查询。可以与AWR报告关联起来,根据CPU,IO和SQL统计节中的buffer gets的标准测量,判断查询的总体性能。

一旦有问题的语句已经确认,可以参考Document 223117.1 Troubleshooting I/O-related waits的“Reduce the I/O requirements of the database by tuning SQL”节中的方法,使用其中的方法提高这些语句的性能。

如果相比于太多这种等待事件,IO确实存在问题,那么可以参考下面的细节:

Document 1476092.1 Troubleshooting IO Performance Problems Impacting Scattered Reads

Document 262687.1 How to use the Sql Tuning Advisor

Document 1195363.1 Database Performance and SQL


衡量正确性

一旦已经尝试如上方法,对比最新的AWR与标准AWR(AWR是基线)。查找这种等待事件总体时间减少的百分比。如果仍有问题,需要重新分析这些问题,根据他们具体的现象定位具体的问题。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值