oracle實驗記錄 (oracle 詳細分析redo（3）)

與redo 的相關等待事件

SQL> show user
USER 為 "SYS"
SQL> select name from v$event_name where name like 'log%';

NAME
----------------------------------------------------------------
log file sequential read
log file single write
log file parallel write
log buffer space
log file switch (checkpoint incomplete)
log file switch (private strand flush incomplete)
log file switch (archiving needed)
log file switch completion
log file sync
log switch/archive
log file switch (clearing log file)

NAME
----------------------------------------------------------------
log write(odd)
log write(even)

已選擇13行。

具體 說明下 與redo有關常見的 event 產生原因，及其簡單處理方法:

log file sequential read：

當程式等待從REDO檔案中讀入塊時會產生該等待事件。
ARCH程式在讀取REDO檔案時會遭遇此等待事件。
引數說明：
事件號：174

事件名：log file sequential read

引數一：REDO日誌組中重做日誌檔案的相對序列號。

引數二：開始讀入的塊號

引數三：塊數

等待時間：完成請求讀取的IO所佔用的實際時間。

 

log file single write：

這是日誌檔案寫的 等待 (不是從log buffer 寫入log file)代表寫log file header時等待,一般是日誌檔案頭 更新member檔案或日誌sequence#增加時會寫日誌檔案頭

*log file parallel write:

這是一個主要事件 lgwr將log buffer寫出到logfile而產生的 等待時間
session commit or rollback，LGWR會等待該事件的完成，使用者會話則等待log file sync event

SQL> select event,p1,p1text,p2,p2text,p3,p3text from v$session where event='log
file parallel write';

未選定行
實驗環境 當前沒有這個event

查下歷史session
V$SESSION_WAIT_HISTORY

The V$SESSION_WAIT_HISTORY view displays the last ten wait events for each active session.

這個檢視會記錄 最近最後10次發生的 events
SQL> col event format a30
SQL> col p1text format a10
SQL> col p2text format a10
SQL> col p3text format a10
SQL> select event,p1,p1text,p2,p2text,p3,p3text from v$session_wait_history wher
e event='log file parallel write';

EVENT                                  P1 P1TEXT             P2 P2TEXT
------------------------------ ---------- ---------- ---------- ----------
        P3 P3TEXT
---------- ----------
log file parallel write                 1 files               3 blocks
         1 requests

log file parallel write                 1 files               2 blocks
         1 requests

log file parallel write                 1 files               2 blocks
         1 requests

 

 

從p1text,p2text，p3text可以看出來
引數一：寫入的日誌檔案號

引數二：寫入的塊數

引數三：IO請求的號碼

9i前 要連線 v$event_name看才可以 ，沒有p1text
SQL> select parameter1 from v$event_name where  name='log file parallel write';

PARAMETER1
----------------------------------------------------------------
files

SQL> select event,time_waited,average_wait from v$system_event  where event='log
 file parallel write';

EVENT                          TIME_WAITED AVERAGE_WAIT
------------------------------ ----------- ------------
log file parallel write                239          .25

AVERAGE_WAIT NUMBER Average amount of time waited for the event (in hundredths of a second)   單位是100分 之一秒

若AVERAGE_WAIT >10MS (單位毫秒 1000分之一秒 則表示I/o太慢 )

關於調整：
可以減少redo(nologging ,cats ，append操作)
可以加大log buffer，但相對的_log_io_size應該修改 控制1/3寫入 應該相對改小點，否則log buffer大了 1/3寫一次 寫的redo record太多
但如果redo allocation latch,redo writing latch 爭用（lgwr寫時候要 佔用這兩個latch）多不要減少_log_io_size這會造成 lgwr更加頻繁的寫 獲取這些latch 造成latch爭用
根本解決方法 還是將redo file放到更快的磁碟上

log buffer space
主要原因就是 server process生成redo record快過lgwr寫出redo record的 產生的 等待，新的redo record 從pga寫到log buffer中沒空間了,就是i/o過慢，另外log buffer過小也是
但如果log buffer過大 ，每次LGWR寫的 redo record過多,會造成使用者等待log file sync 事件，可以通過_log_io_size改進
調整建議方法 與log file parallel write event一樣

  1* select name,value,class from v$sysstat s where statistic#=(select statistic
# from v$statname t where name='redo buffer allocation retries')
SQL> /

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
     CLASS
----------
redo buffer allocation retries                                            0
         2

SQL> col name format a40
SQL> /

NAME                                          VALUE      CLASS
---------------------------------------- ---------- ----------
redo buffer allocation retries                    0          2

以上 查詢可以看到 session procss或 system級 必須等待 空間次數（等待lgwr flush  log buffer）等待log buffer space次數.

redo buffer allocation retries ：表示再次嘗試從log buffer中分空間的次數（最好為0），process第一次沒請求成功 會觸發LGWR 然後等待完成或其它PROCESS 已經觸發而 這個程式等待lgwr完成，完成後再次嘗試從log buffer中分配空間
用 redo buffer allocation retries和redo entries可以計算出從PGA copy change vector到SGA LOG BUFFER 時必須等待的重做記錄的數量所佔的比例
最好為0 或<1%如果>1%且不斷邊大 說明從PGA copy change vector到SGA LOG BUFFER時必須等待log buffer空的日誌塊，可以考慮加大log buffer or  提高lgwr寫效率

 

log file switch (checkpoint incomplete)
如果發生switch log file會產生一個 檢查點，將dirty block寫入disk ，記錄scn等,如果檢查點過慢 就會出現這個 等待事件
（手動switch 不會出現這個事件）

SQL> alter system switch logfile;

系統已更改。

SQL> select group#,status from v$log;

    GROUP# STATUS
---------- ----------------
         1 ACTIVE~~~~~~~~~~~檢查點 沒完成
         2 ACTIVE~~~~~~~~~~~檢查點  沒完成
         3 CURRENT

SQL> select event,p1,p1text,p2,p2text,p3,p3text from v$session where event='log
file switch (checkpoint incomplete)';

未選定行

log file switch (archiving needed):
如果是archive log mode 如果日誌切換過快，或arch程式 歸檔過慢 都會造成 這個等待事件，表示下一個日誌檔案還未歸檔，此時又發生switch

log file switch completion
當一個redo file 滿了後 需要切換(switch)， 要開啟另一個online redo log file ，寫完上一個 檔案準備好下一個日誌檔案這之間的等待就是此事件

 

log file sync
使用者commit or rollback 提交了事務觸發lgwr寫入log file， 那麼使用者會等待這個事件，如果伴隨出現 log parallel write(也很高) 就是i/o過慢
如果log file sync很高 log parallel write很低 那麼證明i/o沒問題 log buffer很快的重新整理到log file中,那麼log file sync 表示使用者太多的commit or rollback

SQL> select name,value from v$sysstat where name in ('user commits','user rollba
cks');

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
user commits                                                            687
user rollbacks                                                            0
看看是否是過多了

 

 

 

 

log file switch (clearing log file):
alter system clear logfile時（clear會重建redo file member） 會出現且 lgwr正需要切換到被clear的redo file，，等待時間為1S

 

 

 

 

 

log switch/archive：手動執行歸檔時會發生
Used as part of the ALTER SYSTEM ARCHIVE LOG CHANGE scn statement. The session waits for the current log from all open threads to be archived.

Wait Time: Wait for up to 10 seconds

Parameter Description
thread# The thread number of the thread that is currently archiving its current log

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12020513/viewspace-617287/，如需轉載，請註明出處，否則將追究法律責任。