深入淺出等待事件和效能診斷04

下面再摘要幾個關於log的等待事件

Log file switch日誌檔案切換，資料庫進行日誌切換時，LGWR需要關閉當前日誌組，切換至下一日誌組，切換中資料庫的所有dml操作都會停止直至切換完成。

Log file switch又包含兩個子事件：

1） log file switch（archiving needed）即是日誌切換時，需要覆蓋先前日誌時，發現日誌歸檔尚未完成，出現log file switch（archiving needed），該等待可能表示I/O問題，歸檔程式寫出緩慢，也有可能是日誌組設定不合理

可以考慮增大日誌組檔案和增加日誌組；增加歸檔程式log_archive_max_processes，移動歸檔檔案到快速磁碟

2） log file switch（checkpoint incomplete）檢查點尚未完成，如果此時資料庫沒有完成

寫出這個redo log所記錄的所有dirty block，該等待事件出現。

Dbwr寫出速度太慢或I /O存在問題，可以考慮增加db_writer_processes引數，不過該引數一般不需要增加，db_writer_process一般設定和cpu數量相等，也可以增加日誌組或日誌大小。

Log file sync日誌檔案同步：

當一個事物提交或回滾時，lgwr需要將session的該redo log buffer寫入重做日誌中，lgwr完成任務以後會通知使用者程式，Log file sync必須等待這一過程完成。

如果該等待過多，有可能是lgwr寫出效率低，或者系統提交過於頻繁。針對該問題，可以透過log file parallel write等待事件或user commit user rollback等統計資訊觀察。

而避免redo log sync等待可以透過提高LGWR效能，儘量使用快速磁碟；使用批次提交；適當使用nologging/unrecoverable等選項。如果系統產生redo過多，每次寫得較少，lgwr被過度頻繁啟用，可能導致redo相關的latch競爭。

Log file single write

該事件僅與日誌檔案頭塊相關，通常發生新增日誌組成員和log switch增進序列號。頭塊寫單個進行，因為頭塊的部分資訊是檔案號，每個檔案不同。更新日誌檔案頭在後臺完成，很少出現等待。

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

EVENT TOTAL_WAITS TIME_WAITED

---------------------------------------------------------------- ----------- -----------

log file single write 21 12

SQL> alter system switch logfile;

系統已更改。

SQL> alter system switch logfile;

系統已更改。

SQL> alter system switch logfile;

系統已更改。

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

EVENT TOTAL_WAITS TIME_WAITED

---------------------------------------------------------------- ----------- -----------

log file single write 27 14

在進行switch logfile時需要增進序列號，需要進行日誌檔案塊頭寫log file single write，可能會出現此等待事件。

Log file parallel write

從log buffer寫redo記錄到日誌檔案，主要是常規寫操作log file sync，如果log group存在多個組成員，當flush log buffer時，寫操作並行的，很可能會出現log file parallel write等待。Log file parallel和log file sync可以用來衡量log file的寫入成本，也稱為同步成本率。

Log buffer space日誌緩衝空間

當資料庫產生日誌速度比LGWR的寫出速度快，或者log switch太慢，就會發生log buffer space等待。等待出現時，通常表明redo log buffer過小，為解決這個問題考慮增大日誌檔案大小或者增加日誌緩衝區大小。Log buffer space等待事件出現時，資料庫將處於停頓，由於日誌快取無法分配也無法記錄資料庫的變更。

Log buffer space也有可能是磁碟I/O問題，LGWR寫出太慢，導致redo log buffer中空間不足，可以考慮使用快速磁碟，因為日誌檔案通常只寫，分離存放可以獲得效能提升，儘量使用raid 10而不是raid 5磁碟儲存日誌檔案。

Enqueue（佇列等待）

Enqueue是一種共享資源的鎖定機制，該鎖定機制保護共享資源，以避免因併發操作順壞資料，enqueue採用排隊機制，即fifo先進先出控制資源使用。

Enqueue是一組鎖定事件集合，如果資料庫中等待事件顯著還需要進一步追蹤哪一類別的鎖定引發資料庫等待。例如常見的有ST，HW，TX，YM等，在oracle 8I前字典管理表空間典型的是對於uet$和fet$資料字典表爭用。

Latch free 閂鎖釋放

Latch free通常被稱為閂鎖釋放，說明有程式正等待某個latch釋放，也就是waiting latch free。

Latch低階序列機制，保護sga中共享記憶體結構，可以想象成記憶體鎖，保護防止共享記憶體結構被多個使用者同時訪問。Latch通常是作業系統利用記憶體中某個位置，透過設定變數為0或非0來表示latch是否已經被取得，大多數作業系統是利用test and set方式完成latch持有和檢查的。在oracle10g後，latch free被具體劃分為多個latch競爭，cache buffer chain、cache buffer lru chain、shared pool等latch（關於cache buffer的latch多是由熱點塊引起，shared pool更多是硬解析造成。）

1 latch分類

Willing-to-wait:指如果請求latch不能立即得到，請求程式將等待一段時間後再次發出請求，程式一直重複此過程直到得到latch

Immediate：如果請求不能立即得到，請求程式不再等待，而是繼續執行下去

Oracle的latch機制是競爭

對於willing-to-wait的latch，如果一個程式第一次嘗試沒有獲得latch，那麼該latch會等待並且再次嘗試，如果系統存在多個cpu，那麼此程式將圍繞該latch開始spin，經過隱含引數_spin_count此爭奪不能獲得latch，然後該程式轉入睡眠，持續一段指定長度時間再次醒來重複先前過程直到獲得該latch。

對於immediate型別的latch通常是因為存在多個可用latch，例如常見的redo copy latch，當process想獲取redo copy latch時，首先要求其中一個latch，如果可以命中則持有該latch，不能獲取則會轉向另一個redo copy latch，只有所有的redo copy latch都無法獲取時，才會sleep與wait。

然後immediate另外一種原因是每個latch都有level概念，當一個process需要取得一組latches時，為避免死鎖，取得latch有一定順序，即process新請求latch的level，應該大於process目前所握有的latch的level。如果process要求的新latch的level小於目前所持有的latch的level，oracle要求process釋放目前所持有的latch，再依序取得這些latch。為了節省時間，oracle允許以no_wait方式要求較低的latch，如果成功取得，即可以避免deadlock又可以節省時間。

Redo copy latch

程式修改資料產生redo，redo首先儲存在pga中，然後redo從pga寫入sga的redo log buffer中，不過由於涉及到記憶體訪問需要獲取該記憶體的redo copy latch，獲得該latch以後才能把redo寫到log buffer中，隱含引數_log_simultaneous_copies為2倍cpu數量定位redo copy latch數量。

Redo allocation latch

Redo copy latch獲取後，需要把pga中的redo寫入redo log buffer中去，此時又需要獲取redo allocation latch分配redo空間，獲取到空間時redo allocation latch釋放，然後把pga中的redo寫入redo log buffer中，寫入完成後釋放redo copy latch。

如果系統是高階伺服器，超過16cpu，而根據v$latch檢視發現redo allocation latch競爭激烈

在oracle 9IR2可以透過設定調整引數_log_parallelism來減少latch競爭，log_parallelism預設為1 ，在oracle10g後_log_parallelism為隱含引數，另外又加入隱含引數_log_parallelism_dynamic預設為true，_log_parallelism_max為redo的最大並行度，如果_log_parallelism_max設定為不同於_log_parallelism引數，oracle會動態選擇並行度，從這點也可以看出oracle的變化

SQL> select ksppinm, ksppdesc, ksppstvl

2 from x$ksppi a, x$ksppcv b

3 where a.indx = b.indx

4 and a.ksppinm = '_log_parallelism'

5 ;

KSPPINM KSPPDESC KSPPSTVL

------------------------------ ------------------------------ ------------------------------

_log_parallelism Number of log buffer strands 1

完成redo copy以後，如果是commit引發的把redo從pga寫入redo log buffer進而還會引發lgwr將redo log buffer寫入聯機日誌組。（而eygle接下來又提到了一段話：為了避免LGWR被不必要post，程式需要先獲取redo writing latch檢查lgwr是否被啟用或者已經被post，如果是，redo writing latch將被釋放。對於redo writing latch是如何檢查lgwr是否被啟用或post）

其實關於oracle的等待事件還有很多，如果純粹記憶肯定很吃力，如果從oracle原理和體系上逐步分析我們倒是可以從原理出發清晰的認識oracle。

[@more@]