一次 read by other session 的处理过程
2017-05-16 12:39 tlnshuju 阅读(290) 评论(0) 编辑 收藏 举报一个哥们给我打电话。他说系统中一直出现等待事件 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开除了 不就得了吗哈哈。或者要不来我这里培训一下 哈哈。