如何診斷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