eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« 我的新家 我的北京五年 | Blog首页 | 偶遇孟静 »

成功优化案例:解决ERP系统更新性能问题

上个周五,北京阴雨绵绵的那天,接到用户的服务请求协助,建行的数据中心出了点问题。

跨越大半个城市,从东到西,赶到用户现场。
了解了一下用户情况,是一段用于月结的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-


历史上的今天...
    >> 2013-04-03文章:
    >> 2007-04-03文章:
    >> 2006-04-03文章:
           泰山之巅
    >> 2005-04-03文章:
    >> 2004-04-03文章:

无觅

By eygle on 2008-04-03 09:43 | Comments (11) | Case | 1864 |

11 Comments

HASH JOIN SEMI

应该走index FFS or FTS了,那还db file sequential read,猜测是他们内存太大了,INDEX BLOCK都CACHE到MEMORY中去了。

说不定下次还会发生。

请问eygle:
如果判断Index需要重建的?有分析index吗?

还有象那种7亿多记录的表,为什么您不建议他们使用分区表?
这样性能不是又有提升。

我听了好多课觉得还是很有收获的,如果你认为卫星直播这种效果不好(我觉得主要是传输问题,至于没有交流其实可以通过论坛来讨论的)可以考虑做成视频 或者详细些的文档,对于你们的免费讲课活动在此表示感谢。

to xiaolong78;

这些表已经是分区表,否则更难达到这样的效率的。

学习中。支持。

已经是分区表了。为何不分区或者分批处理后在聚合呢?直接这样处理!!幸亏机器巨强呀!要不然。。。

请问“重建一个15G的索引”的目的何在?或者我应该问数据库这样做了什么动作?

我前几天遇到类似的事件,执行计划没错,但SQL就是在一张表上停住不动,在DEV和QAS环境下执行都没问题,万般不得其解,后尝试将哪张表的所有索引update stattistics才解决问题

eygle在这里的重建索引又起什么作用的?

7亿条数据,15G的索引,这个索引应该不是个分区索引,而是个全局索引或普通索引。又是数据中心的数据,每月应该会批量加载数据。是否是这批量加载数据把索引搞的不好用了?

介就是你的成功案例```


能否讲详细一点呀?

请问
1、“通过进一步判断,强烈建议用户重建一个15G的索引,第二天早上收到用户的报告,系统一切恢复了正常。”,重建后,该过程用了多长时间?

2、重建索引后的执行计划和重建之前是否一样?是否还是 HASH JOIN SEMI?

3、15G的索引重建后大小为多大了?

真正的要解释这些内容,真是需要深入研究才是啊


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com