开发的同事最近在优化一段每小时都会运行的程序，希望这段程序可以更快速的完成操作。优化后找到我，要求我帮忙看下当前数据库是否有瓶颈，于是做了statspack，发现当前数据库由于是测试库，所有参数均未有过任何优化调整。

Cache Sizes (end)
~~~~~~~~~~~~~~~~~
               Buffer Cache:        32M      Std Block Size:          8K
           Shared Pool Size:       112M          Log Buffer:        512K

8G内存的服务器上，SGA仅仅分配了不到200M，这是明显不合理的。

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time                                                          578    59.24
log file sync                                      40,094         201    20.62
log file parallel write                            40,821         184    18.87
control file parallel write                           372           6      .58
db file sequential read                           122,328           6      .57
          -------------------------------------------------------------
         
我们可以清晰的看到2个等待事件：log file sync、log file parallel write

log file sync及log file parallel write 的等待次数都超过4W次，等待时间已经接近总运行时间的40%
由此分析，如果我们可以解决这2个等待事件，对数据库性能必定有所提升。

产生这些log等待根本原因为：
log buffer 尾指针已经追上了头指针写入速度，导致整个log buffer 都为脏读redolog，均需要由LGWR进程写入redolog

分析可能是由如下几种情况导致：
1. 由于logbuffer设置过小
2. 磁盘io速度太慢，导致写入速度过慢
3. 提交过于频繁，由于每次commit都需要LGWR进程写入redolog中，所以需要LGWR频繁完成写入操作，导致等待。

查看top SQL 我们可以发现，这段程序多为update操作，这也可能是为什么会产生大量log等待的原因。

大概了解了情况以后，首先增加了SGA大小，将Log Buffer为15M。

重新执行程序，发现执行时间仅仅提升了5%左右，且等待事件依旧为log的等待，且等待时间并没有明显的下降。
至此已经排除了 log buffer设置过小导致的等待，那么磁盘io经过测试也没有问题，那么最有可能的就是过于频繁的commit导致的。

让我们看看redo的写入情况
我们使用(redo blocks written/redo writes )*512 得出每次LGWR写入redolog的大小为：（41333/24828)*512=852byte
每次写入仅852byte，写入次数已经将近2.5w次。每秒钟写入redo次数为：redo writes/Elapsed time= 24828/322 =77次/s

这似乎不太正常，每秒钟竟然有77次的redo写入，频率太高了，我猜测，就是由于commit太过频繁导致的log等待。

随后我咨询了开发的同事，正如我所料，果然每次update都会提交，我建议他修改提交频率，后再次运行程序，我在做一次statspack。

这次的statspack变的明朗了许多：
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time                                                          298    98.06
latch free                                         12,456           3      .89
log file parallel write                               123           1      .49
control file parallel write                            79           1      .48
db file sequential read                                36           0      .05
          -------------------------------------------------------------
         
CPU time已经达到了98%以上，日志等待事件虽然仍在其中，但是等待时间少的已经可以忽略。

我们在看一下redo的写入情况
每次LGWR写入redolog的大小：(20001/123)*512=83256byte
每秒钟写入redo次数为:(123/238)=0.5 次/s

最后询问了开发组的同事，程序运行时间已经缩短了20%

至此本次优化可以说圆满结束了。