一次 read by other session 的处理过程



一个哥们给我打电话，他说系统中一直出现等待事件 read by other session ，并且该等待都是同一个sql引起的，比较紧急，请我帮忙远程看看。

远程过去之后，用脚本把 等待事件给抓出来

从图中看到 read by other session 是在运行同一个SQL , sql_id 是  1svyhsn0g56qd

于是查看执行计划

该SQL走的是 ILMCU 这个列的索引，过滤条件有4个列，但是只走了一个列的索引。

先别管执行计划，先来看一下等待事件 read by other session 究竟是被哪些进程阻塞，这些进程又在跑什么SQL

最后发现， 还是同一个SQL。 然后仔细问了一下业务。原来该系统是一个 沙发厂的 ERP 系统。

前台的用户点击某个按钮，等了半天没响应，然后就一直点，一直点 就导致这个 SQL 一直重复的运行，

但是呢，这个SQL 跑不出结果，所以就产生大量的 read by other session

所以呢，最终优化这个SQL就可以解决该问题，跑的SQL 如下：

SELECT *  FROM PRODDTA.F4111 WHERE ((ILDCT = :1   AND ILFRTO = :2   AND ILMCU = :3   AND ILDOC = :4  )) ORDER BY ILUKID ASC

走的索引是 ILMCU 这个列的索引，首先看一下这个表一共有多少行

一共有250w行，那这个表其实不大啊，搞多了数据仓库，一个表没有几十亿数据那还真不算大。现在来看一下 ILMCU 这个列数据分布

同志们想一下 为啥我要用 full 这个hint? 因为现在 有 n 个进程 在跑 刚才的 SQL，并且就是 ILMCU 这个列的索引

 要是这个时候我不加 full hint , 万一又走了 ILMCU 这个列的 索引，那不是火上浇油吗

并且 这个表一共才 250w条数据，走全表也没啥的，而且我不仅仅要看这个列数据分布，还要看其余3个列，那必须走全表了

最终发现 ILMCU 这个列分布 太他妈不均衡了， 问了一下 那哥们，现在的业务是不是做的 SF10 ，他回答说是的 。

从250w里面去选142w ,走索引， 卧槽，那肯定死啦死啦的 ，肯定产生大量的 db file sequen read 等待 ，

说白了， 表统计信息有问题，没收集直方图，哎，懒得管统计信息了，帮他搞定再说

于是又连续查看剩下的过滤列的数据分布

然后看了一下他的的数据库版本，11gR2 ，跑在 IBM 小鸡鸡上面 ， 因为是 11g 可以 online 创建 索引， 如果是 10g 不敢 online 创建 (10g 是假的online )

create index idx_F4111_docdctilmcufrto on F4111(ILDOC,ILDCT,ILMCU,ILFRTO) online nologging;

索引创建完之后，前台的用户 立马就搞定了， 之前是 搞了一天 ，我晕

问题再 总结一下 ：

这个 ERP 系统没有dba维护，所以呢 表没收集统计信息，表也缺乏索引， 这个表呢是 系统一直都有的 ，并且是一个核心表 ，因为没 dba ，他们不敢乱建立索引

刚开始数据量小，没问题，后来数据量越来越大，问题就来了。我看了一下 他那边所有的业务全都跑得慢，今天这个是跑了一天，没法忍受了才找人帮忙的

我只能说老板太他妈抠门了，招个dba，去干1--2个月，然后找个借口把 dba开除了 不就得了吗哈哈，或者要不来我这里培训一下 哈哈。