> 本文主要說明 log file sync 等待事件及相關內容

#### 1.說明是'log file sync'等待事件
當一個使用者會話提交，那個使用者產生的所有redo需要從記憶體重新整理到重做日誌檔案，使事務對資料庫的修改永久化。
 
在提交時，使用者會話會通知 LGWR 把日誌緩衝區中的資訊寫到重做日誌檔案（當前所有未被寫入磁碟的 redo 資訊，包括本次會話的 redo 資訊）。當 LGWR 發現寫操作完成後，它會通知使用者會話。當等待LGWR通知確認所有redo 已經安全的儲存到磁碟的過程時，使用者會話會等待'log file sync'。

使用者會話顯示等待'log file sync'，是使用者會話通知LGWR和LGWR通知使用者的寫操作完成之間的時間。

注意在11.2及以上版本，LGWR會在預設的post/wait模式和polling模式之間自動切換。在polling模式下，寫操作的進展會維護在一個記憶體結構中，等待'log file sync'的會話可以不時檢查這個記憶體結構看是否自己所發起的事務對應的redo已經寫入磁碟。這時，等待時間會從使用者會話通知LGWR開始到會話自己發現對應的redo已經寫入磁碟結束。

#### 2.初步分析，需要哪些資訊

- 'log file sync'等待在可接受範圍的類似時間的 AWR 報告，作為用於比較的效能基線
- 'log file sync'等待很嚴重期間的 AWR 報告
- LGWR 日誌檔案（在12.2版本以上還需收集LGnn日誌檔案）

**引起該等待事件最常見的原因：**
- I/O效能問題
- 過多的commit
- redo log 太小，切換頻繁

**比較 user commit/rollback 同 user calls 比值的平均值**
如果平均每 5.76 次 user calls 就會有一次 commit, 大約高出建議值 5 倍。基於經驗，我們期望 user calls/user commit 至少是 25。當然，這取決於應用程式設計。

**間歇性物理IO緩慢對 'log file sync' 等待事件的影響**
GWR傾向於做很多小的IO操作，而不是大塊的IO操作。大部分的磁碟配置並不能在這種場景下很好的工作，可能會發生間歇性物理IO緩慢.
如果你發現系統的'log file sync'很高，但是'log file parallel write'是處於正常的範圍，那麼這可能是由於間歇性物理IO緩慢導致的。可以檢查AWR的部分，也可以使用一些像OSWatcher一樣的工具(參照 Document 301137.1)來確定是否系統中存在間歇性物理IO緩慢。如果可以確定存在間歇性物理IO緩慢, 那麼你需要與磁碟提供商一起來解決這個問題。

出現問題，一定要檢查 LGWR trace檔案，儘管'log file parallel write'的平均等待時間可能在一個合理的區間範圍內，在峰值時刻寫操作時間還是可能會很長進而影響’log file sync’的等待時間。從10.2.0.4 開始如果寫操作超過 500 毫秒我們會在 LGWR 的 trace 中寫警告資訊。這個閥值很高所以就算沒有警告也不代表沒有問題。警告資訊如下：
``` 
*** 2011-10-26 10:14:41.718 
Warning: log write elapsed time 21130ms, size 1KB 
(set event 10468 level 4 to disable this warning)

*** 2011-10-26 10:14:42.929 
Warning: log write elapsed time 4916ms, size 1KB 
(set event 10468 level 4 to disable this warning)

```
注意：上面的峰值如果時間間隔的很遠,可能不會對'log file parallel wait'有大的影響。 但是，如果有 100 個會話等待'log file parallel wait'完成，'log file sync'總等待可能就會很高，因為等待時間將被乘以會話的個數 100。因此，值得探討日誌寫 IO 高峰的原因。

#### 3.Adaptive Log File Sync
11.2 中引入了 Adaptive Log File sync，由引數 _use_adaptive_log_file_sync 控制，在 11.2.0.1 和 11.2.0.2 預設設定為 false。從 11.2.0.3 開始預設是 true。 當啟用時，Oracle 可以在兩種方法之間切換：
- Post/wait，傳統釋出寫重做日誌完成的方法.LGWR顯式釋出所有等待提交完成的程式。優點是，當重做被重新整理到磁碟時，會話幾乎應該立即發現。
- Polling，一種新的方法，其中前臺程式會檢查 LGWR 是否已寫完成。前臺處理睡眠和輪詢以檢視提交是否完成。這種新方法的優點是使LGWR不必通知許多等待提交完成的程式，從而釋放LGWR的高CPU使用率。

最初，LGWR使用post/wait，並根據內部演算法評估輪詢是否更好。在高系統負載下，輪詢可能會執行得更好，因為post/wait實現通常不能很好地擴充套件。如果系統負載較低，則post/wait效能良好，並且提供比輪詢更好的響應時間。Oracle依靠內部統計資訊來確定應該使用哪種方法。因為在post/wait和輪詢之間切換會產生開銷，所以有安全防護措施以確保切換不會太頻繁。

所有開關都記錄在LGWR的跟蹤檔案中，帶有時間戳和字串“日誌檔案同步切換到…”：

Switch to polling:
```
*** 2012-10-02 08:15:47.049
kcrfw_update_adaptive_sync_mode: post->poll long#=316 sync#=1719 sync=247657 
poll=12382 rw=6191 rw+=13890 ack=0 min_sleep=10023

*** 2012-10-02 08:15:47.050
Log file sync switching to polling
Current scheduling delay is 234 usec
```

Switch to post/wait:
```
***2012-10-02 08:16:23.325
kcrfw_update_adaptive_sync_mode: poll->post current_sched_delay=0 
switch_sched_delay=234 current_sync_count_delta=2275 
switch_sync_count_delta=1719

*** 2012-10-02 08:16:23.325
Log file sync switching to post/wait
Current approximate redo synch write rate is 758 per sec
```

輪詢統計資訊儲存在v$sysstat中：
``` sql
SQL> select name,value from v$sysstat where name in ('redo synch poll writes','redo synch polls');

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
redo synch poll writes                                                    0
redo synch polls                                                          0
```
在上面的示例中，我們看到輪詢沒有發生.

該功能在一些版本也出現過一些問題，後續最佳化，相對好點，如果有影響，請及時檢視，並關閉。如果需要禁用自適應日誌檔案同步，可以透過在spfile中設定_use_adaptive_log_file_sync=false並重新啟動資料庫或在記憶體中動態設定來實現。

**Redo Synch Time Overhead**

統計值'redo synch time overhead'在11.2.0.4和12c被引入，記錄了理想的log file sync時間以及真正的log file sync時間的差值。
如果這個差值很小，說明很大的log file sync可能是由於離群（就是偏離平均等待時間很大的log file parallel write等待）的log file parallel write等待導致的。

#### 4.解決辦法

一些建議：
- 與系統管理員一起檢查重做日誌所在的檔案系統以及本地卷的位置，以提高 IO 效能。
- 不要把重做日誌放在需要額外計算的較老的或者複雜的RAID上，比如 RAID-5或者RAID-6或者只有很少cache部件的儲存上
- 不要把重做日誌放在上一代或者較老的Solid State Disk (SSD)磁碟上
雖然通常情況下，SSD 寫入效能好於平均水平，他們可能會遇到寫峰值,從而導致大量的嚴重'log file sync'等待並引發資料庫效能不穩定或者hung住(關於這一點您需要詳盡的測試，因為我們也碰到一些即使SSD的寫效能不穩定但資料庫效能仍然可以接受的系統)
(Engineered Systems (Exadata, SuperCluster 和 Oracle Database Appliance) 除外，因為在這些系統上已經為使用SSD來存放重做日誌而做了額外的最佳化)
- 監控其他可能需要寫到相同路徑的程式，確保該磁碟具有足夠的頻寬，足以應付所要求的容量。如果不能滿足,增加硬碟或者更快的磁碟裝置或者把這些檔案分散到不同的磁碟裝置。
- 確保 LOG_BUFFER 不要太大，一個非常大的 log_buffer 的不利影響就是重新整理需要更長的等待時間。當緩衝區滿了的時候，它必須將所有資料寫入到重做日誌檔案。LGWR 將一直等待,直到最後的 I/O 完成。

- 擴容redo log ，增加日誌組
- 如果有很多短事務，看是否可能把這些事務組合在一起，從而減少 commit 操作。 因為每一個 commit 都必須收到相關 REDO 已寫到磁碟上的確認，額外的 commit 會顯著的增加開銷。雖然 Oracle 可以將某些 commit 組合在一起，透過事務的批處理來減少commit的總體數量還是可以帶來非常有益的效果。
- 看看是否有操作可以使用 COMMIT NOWAIT 選項 （務必在使用前應明白語義）。
- 看看是否有操作可以安全地使用 NOLOGGING/ UNRECOVERABLE 選項完成。

#### 參考
- https://cloud.tencent.com/developer/article/1605049
- 故障排除："log file sync"等待 (Doc ID 1626301.1)
- Adaptive Log File Sync Optimization (Doc ID 1541136.1)

【WAIT】 log file sync等待事件說明

相關文章