首页 > 代码库 > 一次 read by other session 的处理过程

一次 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 系统。

前台的用户点击某个button。等了半天没响应,然后就一直点,一直点 就导致这个 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开除了 不就得了吗哈哈。或者要不来我这里培训一下 哈哈。


 

??

一次 read by other session 的处理过程