今天的ADDM报告提示重做日志缓冲区不够大，我的数据库是11gR2 for linux 64bit，内存自动管理，log_buffer已经9M，即使log_buffer不够大，也应该会自动调整，可是在数据库查看log_buffer的时候，并没有自动调整，还是9M。

查找结果 2: 重做日志缓冲区不够大
受影响的是 .03 个活动会话, 占总活动的 5.17%。
------------------------------
等待重做日志缓冲区空间消耗了大量数据库时间。
   建议案 1: 数据库配置
   估计的收益为 .03 个活动会话, 占总活动的 5.17%。
   -------------------------------
   操作
      通过将 "log_buffer" 参数的值设置为 32 M, 增加重做日志缓冲区的大小。
   原理
      分析期间, 参数 "log_buffer" 的值为 "9773056"。
   建议案 2: 主机配置
   估计的收益为 .03 个活动会话, 占总活动的 5.17%。
   -------------------------------
   操作
      研究改善对联机重做日志文件的 I/O 性能的可能性。
   原理
      对联机重做日志文件执行写入的平均大小为 109 K,
        每次写入的平均时间为 19 毫秒。
   导致查找结果的故障现象:
   ------------
      等待类 "配置" 消耗了大量数据库时间。
      受影响的是 .04 个活动会话, 占总活动的 5.42%。

LOG_BUFFER很多资料都写超过3M没有意义，因为3秒、超过1/3满、达到1MB、DBWN进程和提交都会触发LGWR工作，生产系统可以说LOGWR是一直工作的，也有人说成REDO是连续写的，向老杨请教这个问题，9i及之前，是有LOG_BUFFER超过3M没有意义的这种说法，但是10g开始LOG_BUFFER的值就在变化，在10g开启SGA自动管理和11g开启内存自动管理的情况下，LOG_BUFFER很少是3M这个值，比如我笔记本上的测试数据库，SGA_MAX_SIZE和SGA_TARGET都是300M，LOG_BUFFER的值将近6M，而且很少有资料对这做详细的解释，ORACLE文档也对此没有详细的说明。

SQL> show parameter sga_

NAME             TYPE              VALUE
---------------- ----------------- ---------
sga_max_size     big integer       300M
sga_target       big integer       300M
SQL> show parameter log_buffer

NAME             TYPE              VALUE
---------------- ----------------- ---------
log_buffer       integer           6094848

我们的测试环境SGA是4.5G，LOG_BUFFER是9M多，应该是够的，为什么会说日志缓冲区不够大呢，向测试人员咨询，原来此问题出现在测试环境，测试人员在向数据库加载图片，一张图片大小是2MB，加载上万张图片，而测试环境的REDO文件和数据文件是放在一起的，写数据文件占用的大量的磁盘I/O，影响REDO的写入速度，而测试环境的本地磁盘是7200转的SATA盘，读写效率很低，目前不能将REDO放到其他的快盘上，在测试人员的强烈要求下，将LOG_BUFFER的值修改为35M，同时将SGA增大到7G左右，这是我从事ORACLE工作以来，调整过也是见过最大的LOG_BUFFER，之前见过一个客户的LOG_BUFFER为24M，还很惊讶，没想到自己竟然亲自动手，搞了个更大的LOG_BUFFER出来，汗。

SQL> show parameter sga_

NAME             TYPE              VALUE
---------------- ----------------- ---------
sga_max_size     big integer       7216M
sga_target       big integer       7216M
SQL> show parameter log_buffer

NAME             TYPE              VALUE
---------------- ----------------- ---------
log_buffer       integer           36700160

在这几天的测试中，目前还未出现同类问题。

本文固定链接: https://www.dbdream.com.cn/2011/12/io%e6%80%a7%e8%83%bd%e5%af%bc%e8%87%b4log_buffer%e4%b8%8d%e8%b6%b3/ | 信春哥，系统稳，闭眼上线不回滚！