最近几天的批量确认的Tuning的经历（一）

前几天开始测试批量确认的性能，作了几次测试。第一次是在800万的数量上做测试，确认3万多人大概耗时15分钟，比较满意。第二次在9700万的基础上作批量确认测试，60万人居然花了11个多小时，我faint。随后通过观察数据库的状态（我的程序主要是在存储过程处理业务逻辑，swing+oracle），根据top sql和top session中，发现对于大表A20的update占有相当大的比重，v$session_wait中，比较大的是db file sequential read，证明数据库的读取等待是核心，通过P1参数确定了热点的数据文件。另外还有一个严重的等待是log switch compeletion，说明数据库的日志切换的等待也很厉害。

第一次解决办法：

1.将redo log的数量增加，并且增大redo log的大小从50M到100M；将redo log文件从普通磁盘上转移到了磁盘阵列上。

2.修改db_file_multiblock_read_count参数，从默认的16修改为128，这样提高了每次IO的读取的block的数量，可以明显的从监控图中看到db file sequenctial read所占用的读取时间明显下降，以前大概是5分钟计算后有一次3分钟的db file sequencetial read的等待，现在变为1分钟，而且波谷明显变窄，不在触底。

3.修改SQL语句，将每个人update一次a20改为若干数据量的更新，减少了update的次数，但这样的效果似乎并不明显。

预计的解决办法：

通过这一次的调整，时间并没有减少多少，反到有些增长，从11小时提高到了13小时，faint。因为在a20上并没有作分区，打算通过使用分区、放在裸设备上再进行一次测试。