[Oracle]性能优化调整(三)--调整重做机制

当我们优化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关键字

例如：

create table col_cust

as

select * from collect_cust

unrecoverable;

3.调整检查点

(1)检查点过多也会引起不必要的I/O操作

select name,value from v$sysstat where name like '%background checkpoint%'

结果如下：

background checkpoints started                40

background checkpoints completed         40

当启动点的数目和完成点的数目不一致(不包括目前正在执行的那个哦),就需要考虑调整一下

(2)调整参数FAST_START_MTTR_TARGET --检查点频率默认是:0

4.调整联机重做日志文件

注意两点，(1)把重做日志文件和数据库文件分开 (2)重做日志放在快速设备上，不要放在RAID卷上

5.调整存档操作

略...(本人还不大清楚怎样操作)