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

lei

仓库系统里，基本原则就是拆分，数据结构上化整为零，然后就可以各种并行快速处理（加载转换都可以），这个思路与分布式计算也是类似的。
parallel确实很强大，但得IO够强大，楼主那个情况，不只是48core那么简单，估计存储IO也不弱。
在10g的仓库系统里，要小心误走NestLoop的执行计划，吃了很多苦头，无奈只能hint抑制。

ZALBB

kelsoncong 发表于 2012-6-25 11:33
哈哈，除了这三个，大师还有没有什么大招？

其实还有几招，
1  分区，并定时迁移走历史业务数据，用好11G新出的那几类分区，几乎无往不利。
2  除了采集表的统计信息，还要采集 system, fix_table, dict 等统计信息，

ZALBB

finalarrow 发表于 2012-6-25 11:35
学习了。

虽然不是DBA，但刚好也经历过类似的performance enhancement，我也加几点：

若能把UPDATE 改为 INSERT ，效果更佳，我曾优化过，UPDATE 21分钟，改为INSERT 1分钟。

ZALBB

magscott 发表于 2012-6-25 14:34
在oracle11g中，启用compress table,有可能导致悲剧，压缩表会导致一个bug出现，ora-600[2015],上一周遇到这 ...

哪个版本？

magscott

ZALBB 发表于 2012-6-26 15:01
哪个版本？

版本是11.2.0.2.0，杯具啊，欲哭无泪....

ZALBB

hwtong 发表于 2012-6-25 17:04
找性能问题,,根据客户反映或者AWR报告找到性能较差的sql
分析性能问题,调试SQL,检查执行计划,查看统计信息 ...

HINT 一般只用来调优，不适合放在SQL语句里。

ZALBB

再推荐，10046，跟踪整个语句的执行过程，哪里耗时调哪里。 这招最管用。

magscott

magscott 发表于 2012-6-26 15:03
版本是11.2.0.2.0，杯具啊，欲哭无泪....

好像说11.2.0.3.0，解决了这个bug问题...，如果不升级,db过个几分钟，pmon会自动kill instance，导致db stop

finalarrow

ZALBB 发表于 2012-6-26 15:00
若能把UPDATE 改为 INSERT ，效果更佳，我曾优化过，UPDATE 21分钟，改为INSERT 1分钟。

之前已经insert过的记录，因为业务的流程及逻辑所限，只能做update的。

一般来说，尽可能是做insert，避免update。性能确实是差很远的。

finalarrow

lei 发表于 2012-6-26 14:58
仓库系统里，基本原则就是拆分，数据结构上化整为零，然后就可以各种并行快速处理（加载转换都可以），这个 ...

对的。如果partition分区一开始没数据，然后新加了数据马上操作，很容易引起 Nest Loop的执行计划，这时就头大了，平时一分钟的SQL花十几个小时也跑不完。