如何诊断Oracle Redo Log引发的性能问题
一、Rodo Log性能调整目标：
在能够影响Oracle性 能的诸多因素中，Redo Log相关的因素从某种程度上可以说是最为重要同时也是最值得关注的。因为在一个OLTP系统中Oracle通过各种技术以及优良的设计，尽量做到将大部 分操作在内存中完成，以便最大程度的提升性能。因此在Oracle的诸多后台进程以及用户进程的大部分操作都是内存操作，而且这些操作会通过延迟写入技术 尽可能的将磁盘I/O操作滞后。但是在这些操作中却有某些例外，其中最明显的就是针对Redo Log的操作。
在Oracle中针对Redo Log的操作主要由LGWR进程完成，这个进程可以说是Oracle所有后台进程中最繁忙的进程，而且这个进程可能要频繁的进行I/O操作，这是因为Oracle出于数据安全的考虑必须保证联机在线重做日志可 靠的写入日志文件，以便在发生崩溃时能够有效恢复数据，而真正的数据可能会等一些时间延迟写入数据文件。这种特点在Oracle的各个后台进程中显得有些 独树一帜。另外LGWR全局唯一，即一个实例只能有一个活动的LGWR进程，由于要进行频繁的I/O操作可想而知是很容易造成LGWR进程竞争的。由于 LGWR在Oracle实例结构设计中的特殊地位，一旦出现LGWR性能瓶颈，那么对整个系统的性能影响将会是极为严重的，同时对数据安全也是一个潜在的 威胁。
因此作为Oracle日常的数据库管 理，我们要给与这部分相当的关注，尽早发现问题，尽早作出调整。调整的目标就是要做到Log_Buffer大小适中（不要过大，也不能太小），要满足用户 进程的使用需要，每当系统负载有一个明显的增加时，就应该考虑调整它的大小。比如因为业务拓展当前系统固定用户数量从1万人猛增到3万人，那么就应该对 Log_Buffer大小给与关注。另外就是要做到日志文件的大小适中，日志组的日志文件数量合适，不能影响LGWR写日志文件的性能，不能造成日志文件 间的写入竞争，不能在日志切换归档发生时引发磁盘竞争等等。
二、监控与问题排查：
在进行Redo Log问题监控时，主要关注两个方面：日志缓冲区空间使用的等待情况和日志缓冲区数据槽的分配情况。通过这两方面的监控并配合一些问题排查手段，通常可以发现大量问题。
（1）日志缓冲区空间使用的等待情况：
可以通过查询v$session_wait来监控日志缓冲区空间使用的等待情况，通过如下SQL语句进行查询：
select sid,event,seconds_in_wait,state
from v$session_wait
where event=‘log buffer space%‘;
以上的查询中可以通过观察seconds_in_wait的数值来分析问题，这个数值可以显示如下问题：日志切换缓慢引发的等待、LGWR写入缓慢引发的等待、日志文件写入引起的磁盘竞争引发的等待。
这些等待的发生可能是由于如下问题引起的：
1、日志文件写入时存在磁盘竞争：
这种情况多见于日志切换发生时，由于日志文件组的规划不当，或者存放日志文件的磁盘写入速度缓慢，或者是因为磁盘RADI类型不当都会引发这个问题，如果怀疑村在这些情况，可以通过如下语句进行监控：
select event,total_waits,time_waited,average_wait
from v$system_event
where event like ‘log file switch completion%‘;
可以通过观察total_waits，time_waited，average_wait数值来分析问题，如果这些值过高（注意何谓“过高”，不同系统考量标准不一样，要具体分析），那么说明存在以上问题。此时可以通过如下措施解决：
● 将同一日志文件组的各个成员分配到不同的磁盘上，进而减少日志写入以及日志切换和日志归档时引发的竞争；
● 将日志文件尽可能存放在快速的磁盘上；
● 要合理选择RADI类型对磁盘进行条带化，通常不要选择RADI5来作为日志文件磁盘的RADI类型，通常推荐使用RADI10；
● 可以增加REDO LOG文件大小，来延缓日志切换，下面是一个增加日志文件大小的方法；
假如原来有3个小的redo log file，下面是UNIX环境下的一个例子：
第一步：往数据库添加三个大的redo logfile
SVRMGRL>ALTER DATABASE ADD LOGFILE GROUP 4
(‘/opt/oradata/app/redo04.log‘,
‘/ora_bak/oradata2/redolog/redo04.log‘) size 16M reuse;
SVRMGRL>ALTER DATABASE ADD LOGFILE GROUP 5
(‘/opt/oradata/app/redo05.log‘,
‘/ora_bak/oradata2/redolog/redo05.log‘) size 16M reuse;
SVRMGRL>ALTER DATABASE ADD LOGFILE GROUP 6
(‘/opt/oradata/app/redo06.log‘,
‘/ora_bak/oradata2/redolog/redo06.log‘) size 16M reuse;
第二步： 手工地做log switch，使新建的redo logfile起作用
SVRMGRL>alter system switch logfile;
此操作可以执行一到几次，使旧的redo logfile成invalid状态。
第三步：删除原来旧的redo logfile
SVRMGRL>alter database drop logfile group 1;
SVRMGRL>alter database drop logfile group 2;
SVRMGRL>alter database drop logfile group 3;
2、检查点发生时DBWR进程没有完成数据写入引发等待：
当日志文件完成一个循环周期后再一次来到原来某个日志文件准备进行重新使用时，发现该日文件对应的数据还没有写入相应的数据文件中，此时LGWR必须等待DBWR完成写入，从而引发等待。
如果怀疑存在这个问题可以通过如下查询来进行监控：
select event,total_waits,time_waited,average_wait
from v$system_event
where event like ‘log file switch (check%‘;
通过total_waits，time_waited，average_wait这些数值的大小来判断分析问题，如果还不能确定，那么可以查看 一下Oracle的alert.log文件看一下相关时间内是否存在“checkpoint not complete”。如果存在那么证明日志文件的操作性能被DBWR进程所拖累。此时可以通过如下措施解决：
● 检查存放数据文件的磁盘是否存在I/O瓶颈（如：是否存在读写竞争、是否存在物理损坏、是否存在RADI类型不符等）；
● 合理规划调整日志文件组日志文件的数量和大小；
● 合理设置FAST_START_MTTR_TARGET参数，以便设置一个合适的数值来控制检查点的发生；
● 可以考虑增加DBWR进程的数量，Oracle最多可以有10个DBWR进程；
● 如果条件允许，可以开启异步I/O；
3、由于日志归档引发的等待：
当归档发生时，归档日志进程不能快速的进行日志归档，从而导致了LGWR的等待。如果怀由此问题可以通过如下语句来监控：
select event,total_waits,time_waited,average_wait
from v$system_event
where event like ‘log file switch (arch%‘;
同样通过total_waits，time_waited，average_wait这些数值来进行问题分析，如果出现由于归档日志写入缓慢引发的性能问题，可以采用如下办法：
● 确定存放归档日志的磁盘空间没有被写满，如果出现这种情况，那么要对归档日志进行有限度的删除，或者将这些归档日志移走如存放到磁带库上，或者分配更大的存储空间；
● 增加日志文件组，从而为归档多留出一些时间；
● 增加多个归档进程，Oracle最多允许10个归档进程存在，在归档发生时如果LGWR进程发现归档进程ARCH出现不足时，会自动产生新的归档进程，因 此如果系统负载有明显增加预先分配足够的归档进程可以提高性能，可以使用alter system命令通过更改LOG_ARCHIVE_MAX_PROCESSES参数来改变归档进程数目；
（2）日志缓冲区数据槽的分配情况引发的等待：
可以通过如下的语句来监控日志缓冲区数据槽的分配情况的百分比：
select r.value "retries",e.value "entries",r.value/e.value*100 "percentage"
from v$sysstat t,v$sysstat e
where r.name=‘redo buffer allocation retries‘
and e.name=‘redo entries‘;
这个百分比值不能高于1%，如果这个数值频繁增长，那么一定出现了Log_Buffer内存空间不足，从而使得新产生的redo log entries不能写入Log_Buffer中从而造成等待，这个等待是由于LGWR性能不佳写日志文件过慢造成的，通常来说LGWR写入速度都是非常快 速的可以保证新产生的redo log entries内存空间使用的需要，即使在高负载情况下也不会出现太大问题，因而上面的问题通常发生机率较小，但是如果一旦发生，那么很有可能是由于日志 文件磁盘I/O规划出现问题，或者日志文件磁盘出现物理损坏，因此在出现这种情况引发的性能问题时，主要应该进行日志文件磁盘I/O规划以及日志文件磁盘 是否出现物理损伤方面的排查，同时也可能综合应用如Oracle的alert.log等相关文件进行综合分析。
From:
http://www.blogjava.net/qileilove/archive/2012/05/11/377874.html