[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. 调整存档操作

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