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

vcdog

有幸得见三把斧头，谢谢楼主，都是经验之谈

风影子

看过了，确实简单又有效，而且平时都有用过，但没想到在这个场景下效果是如此的好。

lei

finalarrow 发表于 2012-6-26 15:16
对的。如果partition分区一开始没数据，然后新加了数据马上操作，很容易引起 Nest Loop的执行计划，这时就 ...

是的，仓库系统程序动态建表很普遍，除非插入数据后，做分析，然后再跑后续处理，但是这样也容易影响并行性能，目前还没找到好的解决办法。

finalarrow

lei 发表于 2012-6-28 15:49
是的，仓库系统程序动态建表很普遍，除非插入数据后，做分析，然后再跑后续处理，但是这样也容易影响并行 ...

“但是这样也容易影响并行性能”？ ——不是非常明白，这种情况下，要么锁定分析计划，要么加hint，要么马上对单个partition进行分析。

难道说，partition 装载新数据时，也是采用parallel并行的方式吗？ 但这好像不影响吧，除非有多个新加数据来源才不好控制。

lei

finalarrow 发表于 2012-6-28 16:03
“但是这样也容易影响并行性能”？ ——不是非常明白，这种情况下，要么锁定分析计划，要么加hint，要么马 ...

1，如果对单分区分析，分析期间ETL调度是没法继续调用后续的依赖该表的任务的，这影响了整体的并发效率，而hint不总是有效。
2，装载的时候的确是用parallel的，存在较多并发加载到同一分区的情况。

幕南风

nice job

jieyancai

对于大数据量常用的招数：
1.分区表操作：分区交换，并行操作，本地分区索引
2.表压缩操作：插入后再做压缩，提升查询性能，节约空间。

finalarrow

lei 发表于 2012-6-28 23:19
1，如果对单分区分析，分析期间ETL调度是没法继续调用后续的依赖该表的任务的，这影响了整体的并发效率， ...

嗯，那就是大家业务场景不相同了。那估计考虑不同的方案，没有最好的，只有最适合的。

vage

好帖。
lorikyo 的 加索引，加hint,收集统计信息 ， 言简意赅。

众大神对压缩表的讨论让我涨了见识。
看来11G还真是搞出不少新特性，要加快学习了。
我也总结一下系统调优的三板斧：

1、发现问题
   通常有人说慢，然后查看AWR、确定大概方向。如果是SQL问题，按照lorikyo的三板斧，调优SQL。如果不是SQL问题，可以进一步查看ASH中等待事件。

2、分析问题
   以等待事件为入手点，在测试库中模拟问题。可以使用10046，也可以使用DTrace+GDB，确定等待事件的原因。

3、解决问题
   找到原因，通常都可以有解决方案。

   说个以前碰到的例子，不过不是调优，但和我说的三板爷比较粘近：

第一步：发现问题：
   有客户反应，从某天开始，每天11点半左右，会有短时间连接不到数据库。查看数据库资料，发现多项指标在问题时间段有一分钟左右的突增，如下图：

图片链接是http://space.itpub.net/321157/viewspace-734158

如图所示，很多指标先降后增。

第二步：分析问题
各项资料指标下降，可能在降的时候，数据库很多操作被什么原因阻塞住了，当阻塞没有时，被阻塞的操作突然执行成功，导致很多指标冲高。
接下来的工作，就是查看等待事件了。根据等待事件，就可以判断出来当时的阻塞是什么原因。
由于是9i，没有ASH可看，到第二天11点多、问题重现时查看等待事件，结果，没有发现啥可疑的等待事件。

既然没有等待事件，就说明在问题出现时刻，多项资料指标下降的原因不是Oracle。
如果根本原因不是Oracle，很有可能就是网络了。
我们把目光转向使用同一交换机的一批MySQL上，经过MySQL DBA的定位，果然，在11点多同一时刻，MySQL有通过网络大量传送数据。

原因找到了，MySQL向外传送大量数据，占用了大量带宽，导致用户无法连接到Oracle。

第三步：解决问题
  将MySQL迁移到其他交换机。问题解决。

gszoracle

数据仓库1：分布IO，2：用大块，3：根据业务排序数据提高聚合度，4：建合适的索引，适时采用位图索引，5：及时采集统计数据，6：开并发7：还有•••••