read by other session的优化记录

【背景】以下是一个ERP数据库的AWR报告，初看数据库挺繁忙的，DB Time/Elapsed的比值接近20，再深入往下看发现数据库的read by other session事件明显，以下是经过一系列的分析解决了read by other session等待事件的问题；

Top 5等待事件

【问题分析一】read by other session产生的原因：发生在一个数据块正在被读进buffer，而其它session此时也要请求这个数据块的时候。这个事件10G以前被归类在buffer busy wait的其他类目中。（说明有多个会话同时在对一个表进行读操作）

查找AWR报告中跟I/O有关的SQL语句

【问题分析二】以上的分析可以给出一个大概的范围，需要继续结合ASH报告或者直接查看当前的session等待情况

1、查找相应的SQL_ID

select distinct sql_id

From v$session

Where event in('read by other session', 'db file sequential read');

2、查看相应的SQL语句和执行计划

select * from table(dbms_xplan.display_awr('SQL_ID'));

【问题分析三】当前ERP系统是SAP，SAP系统对于系统的性能监控和诊断提供了一系列强大的TC，通过运行SM66，刚好可以看到同时有很多并行的SESSION在运行

【问题原因】经过一系列的分析和判断，终于找到问题的根源，由于后台配置了一个有问题的JOB。

该JOB每30分钟执行一次

Catch82E1(07-23-14-57-11)[4]

但是历史记录显示，每次JOB运行的时间到超过10个小时，这个场景我们可以想象一下：

8点00分，运行job，然后这个job会进行select 表A的操作，且一直在循坏操作；

8点30分，这个job又启动了，也运行select表A的操作，且一直在循坏操作；

9点00分，再次启动job，进行select表A的操作，且一直在循坏操作；

这个场景下来肯定就会出现：一个数据块正在被读进buffer，而其它session此时也要请求这个数据块的时候。所以read by other session的等待事件就产生了。

【解决方法】找到问题的原因后，把当前JOB的情况发给业务部门进行调整，调整后每次运行在10分钟以内，相应的read by other session的等待事件也就没有了。

【总结】刚开始系统数据量小的时候，一些操作不加条件、没有索引运行起来都不会影响系统的，但是随着数据量的增加如果没有对系统进行定期检查的话，那么系统就是会越来越慢；

这也是很多系统运行到一定程度就感觉硬件撑不住的原因，其实是由于粗狂式的系统管理，导致系统的资源过度浪费导致的。

想想一本字典目录就是那么几页，如果没有用好这个目录的话，就像进行海量的数据查询不用索引操作；

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

本文作者：JOHN，某上市公司DBA，业余时间专注于数据库的技术管理，从管理的角度去运用技术。

技术博客：猎人笔记数据库技术群：367875324 （请备注数据库类型）

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++