Oracle性能調優:oraclelogbuffer內部機制以及常見等待事件
重做產生于PGA,再由各個session的服務器進程將重做記錄拷貝到SGA 的log buffer中,再由LGWR進程刷新到redo log文件中
涉及到的三個latch:
Redo copy latch
Redo allocation latch
Redo writing latch
Redo copy latch
redo copy latch的數量可以有多個,可以通過_log_simultaneous_copies參數來設定,缺省值是兩倍CPU的個數,
此latch保護日志緩存中的信息,主要用于從PGA拷貝重做到log buffer中,但是不允許對重做記錄一邊進行修改,
一邊將重做記錄寫入磁盤。所以LGWR工作的時候,必須等待持有redo copy latch 的前臺進程將要刷新的重做記錄拷貝完畢
這里也就是說,LGWR從redo log buffer寫到文件的時候,是無法寫正在copy的redo log buffer,但是可以寫不持有
Redo copy latch的log buffer。
Redo allocation latch
前臺進程和LGWR都將持有該latch
oracle把向log buffer中寫緩存這樣一個操作分做兩個步驟:
1. 是先在log buffer中分配一塊空間
2. 是向這塊空間中實際的寫入重做信息
當前臺進行分配空間的時候,必須先持有該latch,但是該階段該latch只有一個,所以前臺進程這個時候會相互阻塞。
當LGWR進行刷新緩存時,持有該latch,當確定刷新的范圍后,那么就會寫到磁盤,寫磁盤前會釋放該latch
Redo writing latch
當日志緩存沒空間分配時,前臺進程必須通知LGWR刷新日志緩存,只有第一個得到此latch的進程通知LGWR,
用來阻止其他進程通知LGWR,通知后,馬上釋放該latch,不會一直占用。LGWR得到通知,持有該latch,
寫入磁盤文件前釋放該latch。
重做產生的流程:
1.先在PGA中生成重做記錄,并計算出重做記錄大小
2.由服務器進程申請redo copy latch如果成功的話繼續
3.再去申請redo allocation,成功分配空間后
4.釋放redo allocation
5.開始把PGA中的重做記錄寫往log buffer
6.記錄寫完后,釋放redo copy latch
_log_io_size:如果使用的log buffer大小等于或者大于該值,那么就觸發LGWR寫磁盤,缺省大小為log buffer的1/3,上限值為1M
redo buffer等待事件:
LOG BUFFER SPACE:
redo copy的速度快于LGWR,造成free log buffer總是不夠用
原因:
LOG BUFFER太小,總沒有空間copy
LOG BUFFER太大,但是錄入的太頻繁
提高LGWR寫的效率,以及磁盤的IO性能
log file parallel write
此等待事件是LGWR將log buffer寫到在線日志文件,重用log buffer。
解決方法:
減少日志的生成(NOLOGGING)
減少日志組成員數
避免在備份模式下做大量的事務
盡量用最小的輔助日志模式(Supplemental Logging),如在LOGMINER下分析日志.
日志組成員分布在不同的物理磁盤上
不要將在線日志存放在RAID5上
盡量使用裸設備
Log file sync
事物提交時,一個進程創建一個重做記錄,LGWR從log buffer寫到磁盤,當再次發出commit,前面的LGWR還沒有完成,會造成log file sync等待
原因:
過度頻繁的提交
CPU使用過度
bug
如果log file sync接近log file parallel write,那么沖突可能是日志IO問題,如果遠大于,則IO不是主要問題
Log file switch(checkpoint incomplete)
當日志切換的時候,要覆蓋一個檢查點未完成的的日志造成的等待
解決辦法:
IO有嚴重問題,增加DBWR的效率,提高磁盤IO性能
增大日志文件
增加日志組
Log file switch (archiving needed)
如果是歸檔模式存在此等待,那就是歸檔的速度慢,可以調整歸檔日志所在磁盤的性能,調整log_archive_max_processes。
log file sequential read
當redo進行歸檔時,會順序讀取redo日志,會造成此等待