当我们优化ORACLE性能,检查了Shared Pool和Buffer Cache命中率之后,意识到需要使这些结构的变得更大才能改进它们，但服务器中没有足够的内存来支持这一改进。同时又发现Redo Log Buffer的Retry Ratio又很低，表明Redo Log Buffer可能被设置得太大，在我们没有购买内存的情况下，调小Redo Log Buffer可能会是不错的选择哦! 不过调整之前一定要慎重,需要经过性能和安全性之间的反复权衡!
重做机制的原理大致是这样的,User Server Process --> 设立数据库检查点(Database Checkpoint) --> 将用户事务中所需要的信息(使用DML/DDL语句)记录下来 --> 复制到Redo Log Buffer中 --> 日志写入程序(LGWR)把Redo Log Buffer信息写到Online Redo Log上 --> 如果当前的Online Redo Log被全部写完了，该Redo Log就变成offline状态,切换另外一个Redo Log,并使其状态online(所以我们可以知道每个数据库必须至少有2个Redo Log文件，注意Redo Log是物理文件) --> Offline Redo Log的文件通过Archive (ARCO)后台进程机制,把该日志的内容复制到存档的重做日志!
如果发现系统的瓶颈是在重做日志机制的性能上面，我们就需要改进它的性能。
1.测量Redo Log Buffer性能
Redo Log Buffer Retry Ratio(重试率) 用户Server Process因为访问Redo Log Buffer而等候的概率，一般我们希望<1%
select retries.VALUE / entries.VALUE "Redo Log Buffer Retry Ratio" from v$sysstat retries,v$sysstat entries where retries.NAME='redo buffer allocation retries' and entries.NAME = 'redo entries'
2.改进Redo Log Buffer性能
(1)增大参数Log_Buffer
(2)减少重做生成
UNRECOVERABLE关键字
NOLOGGING关键字
例如：
3.调整检查点
(1)检查点过多也会引起不必要的I/O操作
select name,value from v$sysstat where name like '篶kground checkpoint%'
结果如下：
background checkpoints started 40 background checkpoints completed 40
当启动点的数目和完成点的数目不一致(不包括目前正在执行的那个哦),就需要考虑调整一下
(2)调整参数FAST_START_MTTR_TARGET --检查点频率默认是:0
4.调整联机重做日志文件
注意两点，(1)把重做日志文件和数据库文件分开 (2)重做日志放在快速设备上，不要放在RAID卷上
5.调整存档操作
5.调整存档操作
略...(本人还不大清楚怎样操作)
