« 我的新家 我的北京五年 | Blog首页 | 偶遇孟静 »
成功优化案例:解决ERP系统更新性能问题
作者：eygle |【转载时请务必以超链接形式标明文章原始出处和作者信息及本声明】链接：http://www.eygle.com/archives/2008/04/tuning_erp_update_sql.html
上个周五，北京阴雨绵绵的那天，接到用户的服务请求协助，建行的数据中心出了点问题。
跨越大半个城市，从东到西，赶到用户现场。
了解了一下用户情况，是一段用于月结的UPDATE SQL出现了性能问题，本来40分钟左右的执行时间，现在突然延长到了4个小时左右。使得原本能够按时完成的任务现在看起来遥遥无期（因为有很多批处理要执行）。
而建行月底的财报要靠这个SQL，所以问题看起来很紧急，后果可能很严重。
仔细检查用户的SQL、执行计划以及系统的Statspack报告及当前等待事件，发现系统大多数的等待消耗在
db file sequential read 等待事件之上，而检查这个事件发现读取在不同的索引文件之间来回跳转。
此时系统资源消耗很低，128G内存，64颗CPU，IO负载同样极低。
执行计划中，SQL在一个7亿记录和2亿记录的表之间进行HASH JOIN SEMI，执行计划并没有问题，问题在于I/O无法充分利用，系统资源无法充分利用。
通过进一步判断，强烈建议用户重建一个15G的索引，第二天早上收到用户的报告，系统一切恢复了正常。
-The End-
By eygle on 2008-04-03 09:43 | Comments (8) | Posted to Case | Edit |Pageviews:
留言 (8)
HASH JOIN SEMI
应该走index FFS or FTS了，那还db file sequential read，猜测是他们内存太大了，INDEX BLOCK都CACHE到MEMORY中去了。
说不定下次还会发生。
Posted by: yumianfeilong at April 3, 2008 10:53 AM
请问eygle：
如果判断Index需要重建的？有分析index吗？
还有象那种7亿多记录的表，为什么您不建议他们使用分区表？
这样性能不是又有提升。
Posted by: xiaolong78 at April 3, 2008 11:45 AM
我听了好多课觉得还是很有收获的，如果你认为卫星直播这种效果不好（我觉得主要是传输问题，至于没有交流其实可以通过论坛来讨论的）可以考虑做成视频 或者详细些的文档，对于你们的免费讲课活动在此表示感谢。
Posted by: dodge at April 5, 2008 2:10 PM
to xiaolong78;
这些表已经是分区表，否则更难达到这样的效率的。
Posted by: eygle at April 6, 2008 1:02 AM
学习中。支持。
Posted by: 有为青年 at April 6, 2008 3:22 PM
已经是分区表了。为何不分区或者分批处理后在聚合呢？直接这样处理！！幸亏机器巨强呀！要不然。。。
Posted by: afly at April 6, 2008 6:19 PM
请问“重建一个15G的索引”的目的何在？或者我应该问数据库这样做了什么动作？
我前几天遇到类似的事件，执行计划没错，但SQL就是在一张表上停住不动，在DEV和QAS环境下执行都没问题，万般不得其解，后尝试将哪张表的所有索引update stattistics才解决问题
eygle在这里的重建索引又起什么作用的？
Posted by: Ken at April 7, 2008 2:45 PM
7亿条数据，15G的索引，这个索引应该不是个分区索引，而是个全局索引或普通索引。又是数据中心的数据，每月应该会批量加载数据。是否是这批量加载数据把索引搞的不好用了？
Posted by: siparadise at April 9, 2008 6:58 PM
