数据库调优的三板斧[已结贴]

xgghxkhuang · 发表于 2012-6-25 20:28

我们因为公司合并，机构和数据量大量增加，报表系统需要调优跑批。

xgghxkhuang · 发表于 2012-6-25 20:31

和一般的报表系统不同的时我们系统是两层的，我们先将上游数据加工到数据中心，然后再从中心跑到报表中。

xgghxkhuang · 发表于 2012-6-25 20:33

我们先优化了到数据中心的批处理，先记录日志将慢的存储过程列出，逐个分析。

xgghxkhuang · 发表于 2012-6-25 20:37

发现有个大的存款表的数据加载，由于数据库和其他系统共用，所以不考虑并行。这里采用了bulk cillect的方式调整loop insert 判断五万条一提交，避免频繁提交，通过limit限制缓存条数。

xgghxkhuang · 发表于 2012-6-25 20:40

还有就是对有些过程的反复访问大表全表扫描的，尝试通过改写sql合并逻辑，方式有左联接，insert all，decode。 case when

xgghxkhuang · 发表于 2012-6-25 20:43

sql慢的其中发现有几个过程的统计信息和执行计划错误。于是在报表的程序中嵌入了数据统计信息分析接口，同时用hint调整了部分sql

xgghxkhuang · 发表于 2012-6-25 20:46

接下来是调整报表的批处理，首先发现厂商的泡批处理是硬解析的，同一张报表需要跑几百个网点，只有机构币种不同，联系厂商要求改成软解析，剩下一些解析时间

xgghxkhuang · 发表于 2012-6-25 20:48

接着通过dba的trace查找出慢的sql，发现索引建立的不合理调整索引降低索引的扫描代价。

xgghxkhuang · 发表于 2012-6-25 20:54

最后找到慢的报表，发现其中有好多对几张大表的聚合的sql，发现只用其中宽表的少数几个字段聚合计算金额，接下来就是出最后一招，物化视图将大表的数据按照用过的字段聚合好，由于是月报，使用了堆表存储过程中刷新，让应用访问聚合好的小表，同时对小表建立好索引。一个几百万的表聚合后只有几千条数据了。

xgghxkhuang · 发表于 2012-6-25 20:56

本来估计跑出来需要十多个小时的性能风险被化解了，几个小时就跑完了。

[精华] 数据库调优的三板斧[已结贴]