一次BOSS订单集计分发的问题解决

昨天刚上班的时候，CRM的同事就过来问为什么现在订单集计分发很慢，之前是1分钟几十单，现在是几分钟几单，让我这里查下怎么回事。

 

打开OEM监控界面，application比较高，一直都是红色的，持续了很长时间，同时还伴随着network的数值，如下：

 

查看了下造成网络的原因，发现类型是：ARCH WAIT ON ATTACH，并且在三个节点上都有，猜测是归档出了点问题，到RAC的三个节点上查询，本地的归档都没什么问题，再查询对应的data guard和stream归档，最后发现data guard的目的地归档不过去了，tnsping不通，最后登陆操作系统也爬不上去，联系运维人员进行排查，最后发现，data guard内存报错，宕机了，但是对于主RAC来说，还是在不断的试图往这个目的地进行归档传送，从而造成网络上的拥堵，最后在RAC端直接修改参数，停止向data guard传送日志，几分钟之后网络问题终于消失了！

 

最后查询造成会话堵塞的情况，发现，这个时间点，有个订单分发的job在执行，同时，boss里面物流仓储的相关人员又在进行订单的集计分发，而操作的都基本上是同样的表，一开始以为是并发会话导致锁表，停掉job之后，几分钟内是恢复了，但是之后又再次出现大片的血红色，看来问题并没有真正得到解决，仔细观察，发现这个时间段，会持续的出现锁表现象，并且有会话堵塞，问了CRM的同事，订单集计分发涉及到的表，最后也就是会话堵塞的那三张表，但是语句都很简单啊，单独执行的时候都很快，为什么会造成堵塞呢，当时有点摸不到方向了。。。

仔细查看造成会话堵塞的会话语句，发现，造成堵塞的并不是那些更新语句(订单集计分发)，而是一条查询相关库存的sql语句，很长，很复杂，嵌套了多个复杂的视图，拉出来执行居然要10几秒钟的时间，最后询问相关人员，订单集计分发的过程会不会涉及到查询相关库存，最后得到了证实，由此推测，可能是仓储那边的同事，在进行订单集计分发的时候，发现很慢（实时查询库存导致会话堵塞），然后连续点了多次，从而造成锁表现象，之后立马让开发人员进行调整，临时换成逻辑简单的语句，上线发现刺眼的血红色终于消失了，看来问题就在这里了，本来以为到此，问题应该已经得到解决了，其实不然，这个复杂的查询语句，还不能拿下来，有其他功能涉及到会进行调用，只能对这个复杂的查询语句进行优化了，但是由于嵌套的视图很多，也很复杂，优化效果不是很明显，正在一筹莫展的时候，突然想起来，之前会话堵塞的时候，发现有条sql语句是查询相关sequence的，之后把这个复杂查询涉及到的sequence都拉出来，仔细检查一遍，发现，很多sequence都没有cache，难道是这个造成的，抱着试试看的态度，一一进行修改，最后上线后发现，终于一片绿色了！

由此看来，有些问题，在你看来，应该不会是造成性能问题的语句，反而会产生很大的负面影响，以后还得多仔细，认真才行！

 

354.jpg

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25618347/viewspace-713428/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25618347/viewspace-713428/