生产故障：read by other session 产生的性能问题分析处理

最新推荐文章于 2025-07-21 16:20:54 发布

原创最新推荐文章于 2025-07-21 16:20:54 发布 · 785 阅读

20 ·

CC 4.0 BY-SA版权

多年从事IT数据库一线工程师行业，记录日常工作中数据库知识及一些生产故障案例，不废话。如有不对请指正，欢迎关注小编：

微信：xh870545795 CSDN：dba_notes

公众号：DB咖啡逗

一、背景

客户开发反馈，2025年4月14日上午10点52分左右，业务系统出现了连接数据库（oracle rac，版本12.2.0.1）响应延迟的情况，数据库日志无报错，随后恢复，监控如下所示：

同时发现业务向数据库请求数据之后，数据库响应请求提示响应慢92.505s,根据客户要求远程接入排查数据库是否存在异常。

二、分析处理

1.检查问题时段有无异常等待

select to_char(sample_time,'hh24:mi'),event, count(1)from dba_hist_active_sess_history awhere a.sample_time>=to_date('20250414 10:40:00','yyyymmdd hh24:mi:ss')and a.sample_time<=to_date('20250414 11:10:00','yyyymmdd hh24:mi:ss')and event is not nullgroup by to_char(sample_time,'hh24:mi'),eventhaving count(1)>2 order by 1;

查询结果如下：

发现异常时段read by other session 等待事件异常突出，对比上周5五同时段的等待事件，发现上周五正常无此等待事件。

这里我们先了解一下这个等待事件产生的原因。当我们试图访问buffer cache中的某个buffer(缓存)时，发现另一个session正在从磁盘读取该buffer。所以，我们需要等待另一个session完成从磁盘读取buffer的操作。在10.1之前的版本，该等待事件属于"buffer busy waits"，从10.1开始，该等待事件被划到 "read by other session"等待事件。多个process重复读取相同的block是产生该等待事件的原因。比如，许多session扫描相同索引或者在相同的表上执行了全表扫描。等待事件read by other session 通常与等待事件db file scattered read 和db file sequential read同时出现。

2.收集问题时段的awr和ash报告

（1）awr报告分析

收集10点到11点的awr报告，进行分析发现如下问题：

证实了我上一步所说的read by other session 等待事件异常突出，我们再看下top sql：

发现top sql里有三个sql是对同一张表做了更新，而且平均每次更新的时间很长，猜测是由此引发的该等待事件。我们继续看下ash报告。

（2）ash报告分析

ash报告我取的是问题时段10点48到10点58之间的进行分析如下：

read by other session 等待事件占比为47.0，我们可以通过p1,p2,p3的值找到热点对象如下：

SELECT relative_fno, owner, segment_name, segment_type FROM dba_extentsWHERE file_id = 14AND 2777448 BETWEEN block_id AND block_id + blocks - 1;

发现热点对象就是前面提到的被更新的那张表，我们继续往下看：

通过ash报告相关信息证实了我上面的猜想，产生read by other session 等待事件的原因主要就是对同一张表做更新操作，且更新语句的执行计划为全表扫描。我们也可以通过sql_id在数据库里面查询到执行计划如下：

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('2y6j6ma5fy684'));

查看对应语句的信息：

通过检查发现此表大小为12G左右，非分区表，在更新语句条件字段上没有索引，导致执行计划为全表扫描。多条语句同时更新并且对表全表扫描产生了read by other session 等待事件。

三、处理建议

1.以上更新语句的条件字段添加索引，减少全表扫描。

2.表大小为12G,考虑业务特征是否可以在线重定义为分区表。

注：后续客户根据建议添加了索引，问题解决，暂无出现延迟现象。

本次就分享到这里，一个小的故障分析处理步骤，如有不对，请指正，欢迎关注，共同学习。