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

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

想起来后怕，要是这几招不起作用要影响报表报送了。

or_wei · 发表于 2012-6-25 23:10

本帖最后由 or_wei 于 2012-6-25 23:11 编辑

kelsoncong 发表于 2012-6-25 16:27
具体是什么bug，什么情况下会发生？压缩表我在生产环境下用过不少啊，还是比较稳定的

好像是update compressed data

george16 · 发表于 2012-6-26 02:35

拜读2次，收益良多啊。

yangb71881 · 发表于 2012-6-26 10:24

1.创建合理的索引是至关重要的...
2.保证统计信息的准确性...
3.围绕的想得的数据，对sql语句进行拆分...
4.对系统相关性能的调整及对相关sql语句的优化...

suredandan · 发表于 2012-6-26 10:29

olap可以尝试使用:物化视图,bit map等..

thain · 发表于 2012-6-26 10:33

本帖最后由 thain 于 2012-6-26 10:34 编辑

分区、索引、并发、统计信息的收集
分析执行计划(分析前注意统计信息的收集)，改写SQL
避免使用游标,用truncate代替delete，中间表、临时表一定要nolog
可以的话开启parallel dml以支持并发写入

孤独飞 · 发表于 2012-6-26 10:49

如果某一session比较慢，一般会直接看此session的等待事件，找出问题的根本原因，然后解决。
如果系统在某段时间比较慢，会收集那段时间的AWR报告，分析Top 5 events，逻辑读、物理读和时间模型，找出影响系统慢的主要问题，然后进行分析优化。
做优化N年，发现主要是两个问题：
1）SQL本身的执行计划出了问题：SQL过于复杂，缺少索引，或者是统计信息不准确，总之是SQL没有达到最优执行计划。
注：最优执行计划的确定，如果sql简单，直接人工分析确定，若是复杂，可以借助oracle 的sql advisor
2）数据存取逻辑设计不合理，如楼主举的例子。

finalarrow · 发表于 2012-6-26 13:56

kelsoncong 发表于 2012-6-25 11:29
继续，

经过上面几板斧下来，性能已经得到很大的提升，而且不用担心历史数据的影响了，时间也缩短到了3个 ...

类似的系统，我有一次将月结从三四个小时优化后只有十一分钟，卡卡...

kelsoncong · 发表于 2012-6-26 14:02

finalarrow 发表于 2012-6-26 13:56
类似的系统，我有一次将月结从三四个小时优化后只有十一分钟，卡卡...

哈哈,介绍一下呢,用了哪些招

finalarrow · 发表于 2012-6-26 14:22

1. 先从架构上去调整，把一些在OLTP上不必要运算改在OLAP中进行，避免OLTP在交易高峰日的处理风险
2. 采用 Partition & truncate (注意空白Partition表分析)
3. 有些逻辑能合并的就合并，不适合合并的就拆分；另外，业务处理根据实际情况上调整一下顺序(我本人就是其中开发人员之一)
4. 采用temp table(temp table本身在处理完就自动清除的)
5. 如果有update动作，当数据量非常大时，采用分批 update 并批量提交，尽早释放资源
6. 因为是数据仓库，可以适当运用bitmap index
7. 利用分析函数
8. Append + parallel(这一点效果不大，因为机器本身配置不高)
9. 前端ETL导出要尽可能采用增量方式
10. 采用预编译的更新或删除来处理动态SQL
11. 把SQL loader 改为exe/imp，减少前端导出的时间

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

浏览过的版块