一次 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开除了 不就得了吗哈哈,或者要不来我这里培训一下 哈哈。


 



你可能感兴趣的:(SQL,TUNING)