<b>文檔内容</b>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#PURPOSE">用途</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#TRBLSHOOT">排錯步驟</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section21">什麼是'log file sync'等待事件？</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section22">使用者應該搜集那些資訊，來初步分析'log file sync'等待事件？</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section23">什麼原因造成了很高的’log file sync’等待？</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section24">影響 LGWR 的 IO 性能問題</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section25">比較'log file sync'和'log file parallel write'的平均等待時間。</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section26">建議</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section27">檢查 LGWR trace</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section28">建議</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section29">檢查線上重做日志是否足夠大</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section210">建議</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section211">應用程式送出過多</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section212">比較 user commit/rollback 同 user calls 比值的平均值</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section213">建議</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section214">其他可能相關的等待事件</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section215">Adaptive Log File Sync</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section216">已知問題</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section217">其他診斷程式來幫助分析'log file sync'等待？</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section218">Data Guard 和'log file sync'</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#aref_section219">其他問題故障排除</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#REF">參考</a>
Oracle Database - Enterprise Edition - 版本 8.0.6.0 到 11.2.0.3 [發行版 8.0.6 到 11.2]
Oracle Database - Personal Edition - 版本 8.0.6.0 到 11.2.0.3 [發行版 8.0.6 到 11.2]
Oracle Database - Standard Edition - 版本 8.0.6.0 到 11.2.0.3 [發行版 8.0.6 到 11.2]
本文檔所含資訊适用于所有平台
本文旨在幫助診斷存在大量'log file sync'等待事件的問題。
<a></a>
當一個使用者會話送出，會話的重做資訊需要從記憶體重新整理到重做日志檔案，使其永久化。
在送出時，使用者會話會通知 LGWR
把日志緩沖區中的資訊寫到重做日志檔案（目前所有未被寫入磁盤的 redo 資訊，包括本次會話的 redo 資訊）。當 LGWR
完成寫操作後，它會通知使用者會話。當等待 LGWR 通知确認所有 redo 已經安全的儲存到磁盤的過程時，使用者會話會等待'log file
sync'。
使用者會話顯示等待'log file sync'，是使用者會話通知 LGWR 和 LGWR 通知使用者的寫操作完成之間的時間。
需要注意的是，如果已有一個正在進行的同步，其他需要送出的會話（為了儲存日志資訊）也需等待 LGWR，進而也将等待'log file sync'？
初步分析等待'log file sync'，下面的資訊是有幫助的：
沒有'log file sync'等待的類似時間的 AWR 報告，作為用于比較的性能基線
'log file sync'等待發生期間的 AWR 報告
注：2 個報告應在 10-30 分鐘之間。
LGWR 日志檔案
當'log file parallel wait'高的時候，LGWR 日志檔案将會顯示警告資訊
‘log file sync’可以在使用者會話通知 LGWR 寫日志，和 LGWR 寫完日志後通知使用者會話，及使用者會話被喚醒間的任何一個點發生。
更多詳情，請參照文檔:
其中的最常見的原因：
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#LGWRIO">影響 LGWR 的 I/O 性能問題</a>
<a href="https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=530248493895606&id=1626301.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=19ht3zc5g7_285#COMMITS">過多的應用程式 commit</a>
這些原因以及如何解決它們詳情概述如下：
我們在這裡回答的主要問題是“是否 LGWR 寫入磁盤慢？”,下面的步驟可以幫助确定是否是這個導緻的。
等待事件'log file parallel write'表示 LGWR 正在等待寫 redo 操作。該事件的持續時間就是等待 IO 操作部分的時間。關于'log file parallel write'的更多資訊，請參閱:
結合事件“log file sync”看同步操作消耗在 IO 的時間，由此推斷，有多少處理時間消耗在 CPU 上。
上面的例子顯示了'log file sync' 和 'log file parallel write' 都有很高的等待時間
如
果'log file sync'的時間消耗在'log file parallel write'上的比例高，那麼大部分的等待時間是由于 IO（等待
redo 寫入）。應該檢查 LGWR 在 IO 方面的性能。作為一個經驗法則，'log file parallel write'平均時間超過
20 毫秒, 意味着 IO 子系統有問題。
建議
與系統管理者一起檢查重做日志所在的檔案系統的位置，以提高 IO 性能。
不要把重做日志放在 RAID 5
不要把重做日志放在 Solid State Disk (SSD)
雖然通常情況下，SSD 寫入性能好于平均水準，他們可能會遇到寫峰值,進而導緻大量的增加'log file sync'等待
監控其他可能需要寫到相同路徑的程序，確定該磁盤具有足夠的帶寬，足以應付所要求的容量。如果不能滿足,移動這些程序或 redo。
確定 LOG_BUFFER 不要太大，一個非常大的 log_buffer 的不利影響就是重新整理需要更長的等待時間。當緩沖區滿了的時候，它必須将所有資料寫入到重做日志檔案。LGWR 将一直等待,直到最後的 I/O 完成。
盡管'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
注意：上面的峰值如果時間間隔的很遠,可能不會對'log file parallel wait'有大的影響。 但是，如果有 100
個會話等待'log file parallel wait'完成，'log file sync'總等待可能就會很高，因為等待時間将被乘以會話的個數
100。是以，值得探讨日志寫 IO 高峰的原因。
請參閱：
與系統管理者一起檢查其他正在發生的可能會導緻 LGWR 寫磁盤峰值的操作
當 LGWR 程序慢的時候，對其進行 Truss 操作會幫助确定時間消耗在什麼地方
注意：這些警告資訊對于預防潛在問題的發生很有幫助。就算平均等待時間沒問題，通過找到 I/O 性能峰值點，DBA 可以知道 LGWR 會間歇性的遇到性能問題，進而在它引發更大問題前将其解決。
每次重做日志切換到下一個日志時，會執行'log file sync'操作，以確定下一個日志開始之前資訊都寫完。 标準建議是日志切換最多
15 至 20 分鐘一次。 如果切換比這更頻繁，那麼将發生更多的'log file sync'操作，意味着更多的會話等待。
檢查 alert.log 日志檔案切換的時間
Thu Jun 02 14:57:01 2011
Thread 1 advanced to log sequence 2501 (LGWR switch)
Current log# 5 seq# 2501 mem# 0: /opt/oracle/oradata/orcl/redo05a.log
Current log# 5 seq# 2501 mem# 1: /opt/oracle/logs/orcl/redo05b.log
Thu Nov 03 14:59:12 2011
Thread 1 advanced to log sequence 2502 (LGWR switch)
Current log# 6 seq# 2502 mem# 0: /opt/oracle/oradata/orcl/redo06a.log
Current log# 6 seq# 2502 mem# 1: /opt/oracle/logs/orcl/redo06b.log
Thu Nov 03 15:03:01 2011
Thread 1 advanced to log sequence 2503 (LGWR switch)
Current log# 4 seq# 2503 mem# 0: /opt/oracle/oradata/orcl/redo04a.log
Current log# 4 seq# 2503 mem# 1: /opt/oracle/logs/orcl/redo04b.log
在上面的例子中，我們看到每 2 到 4 分鐘進行日志切換，這比建議值的5倍還高。
您也可以檢查 AWR 報告日志切換的平均時間
在上面的例子中基于 AWR 中的資訊，每小時有 29.98 次重做日志切換：每 2 分鐘切換一次。這個比每 15-20 分鐘切換一次的建議值要高,并将影響前台程序需要等待'log file sync'完成的時間，因為發起同步操作的開銷比必要的多。
增加redo logs的大小
在這種情況下，要回答的問題是“是否應用程式 commit 過于頻繁？ ”。
如果是，那麼過多的 commit 活動可能會導緻性能問題，因為把 redo 從日志緩沖區重新整理到重做日志可能會導緻等待'log file sync'。
果’log file sync’的平均等待時間比’log file parallel write’高很多，這意味着大部分時間等待不是由于等待
redo 的寫入，因而問題的原因不是 IO 慢導緻。 剩餘時間是 CPU 活動，而且是過多的 commit 導緻的最常見的競争。
此外，如果'log file sync'的平均等待時間低，但等待次數高，那麼應用程式可能 commit 過于頻繁。
在 AWR 或 Statspack 報告中，如果每次 commit/rollback 的平均 user calls（"user calls/(user commits+user rollbacks)"） 小于 30， 表明 commit 過于頻繁
在上面的例子中，我們看到，平均每 5.76 次 user calls 就會有一次 commit, 大約高出建議值 5 倍。基于經驗，我們期望 user calls/user commit 至少是 25。當然，這取決于應用程式。
如果有很多短事務，看是否可能把這些事務組合在一起，進而減少 commit 操作。 因為每一個 commit 都必須收到相關 REDO
已寫到磁盤上的确認，額外的 commit 會顯著的增加開銷。雖然 Oracle 可以将某些 commit
組合在一起，通過事務的批處理來減少commit的總體數量還是可以帶來非常有益的效果。
看看是否有操作可以使用 COMMIT NOWAIT 選項 （務必在使用前應明白語義）。
看看是否有操作可以安全地使用 NOLOGGING/ UNRECOVERABLE 選項完成。
檢查 AWR 報告，看是否有跟 LGWR 相關的,顯示占用了顯著數量時間的其他事件,因為這可能會給出導緻這個問題的一個線索。前台和背景事件都應該進行檢查。
例如下面的 AWR 顯示某些其他前台和背景等待事件等待高，意味着傳輸重做日志到遠端位置的問題，這可能會導緻 fore gorund 程序等待"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，傳統釋出寫重做日志完成的方法
Polling，一種新的方法，其中前台程序會檢查 LGWR 是否已寫完成。
更多關于這個特性的資訊，請參閱:
下列檔案可以幫助特定環境下的已知問題：
下面的腳本着眼于與'log file sync'等待有關的重要參數，'log file sync'等待直方圖資料和相關資訊。
當使用 Data Guard SYNC 和 commit WAIT 預設配置時，可能需要更多的時間。在 Data Guard
環境中，雖然上述調整步驟仍然适用，網絡寫和 RFS/redo 寫入備用重做日志的時間也需要加以考慮。下面的白皮書解釋了'Log File
Sync'如何适用于 Data Guard：
在主資料庫和備用資料庫的設定資訊可以通過從以下文檔的腳本來收集：
對于排除其他性能問題的指導, 請參閱:
![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)