LOG FILE SYNC概述（第一篇）

曾經有將近半年的時間，我都在跟log file sync打交道，每次查看系統壓測期間的TOP 5等待事件，log file sync都穩穩的排在第一的位置，而且平均響應時間已經達到了10ms，隨著一步步的優化，系統壓測的TPS從剛開始時候的4000到6000到8000，TPS提升的過程也是對log file sync等待事件優化的過程。本章主要介紹log file sync相關的原理和優化技巧，希望本章的內容能或多或少的幫助到你。

  log file sync的產生背景

在事務提交時，Lgwr需要把事務產生的日志刷新到磁盤以實現持久化，做到ACID的D的要求，前臺進程從發出提交指令到接受到Lgwr進程日志寫完成的通知，這整個過程都會等待log file sync等待事件。前臺進程在等待log file sync的過程中是被阻斷的，不能做其它事，當Lgwr刷新日志到在線日志后會通知前臺進程日志寫完成，前臺進程接受到通知后，繼續做其它事。日志一旦被刷新到磁盤標志著事務持久化的結束，通過日志來實現事務的持久化已經成為各個數據庫的通用準則，之所以用日志來實現事務的持久化，速度快是最重要的一個原因，我們可以想象一個事務對一個具有3個索引表上插入10個記錄，如果是通過刷新數據臟塊來持久化，需要刷新多少個數據塊，由于堆表的特性，10個記錄可以認為是聚集在1個數據塊上，但是10個記錄針對索引，非常可能的索引塊數能有二三十個，因為索引是有序的，不像堆表可以對記錄不加區分的聚集在一起，當然使用了ASSM管理后，插入記錄的時候，會根據進程的pid做hash去選擇插入的數據塊，因此一定程度上，對于10條記錄，如果是多個進程所插入，也非常有可能是在不同的數據塊中，不過我們這里說的是一個事務，當然指的就是一個進程了。按照我們的推算的話，我們僅僅是插入了10條記錄，但是涉及到的臟塊可能有30個左右，每次事務提交都需要刷新離散的30個數據塊，這個性能實在是太低了，而日志在磁盤是有序的，因此刷新效率上要高出很多，日志還為數據庫實現其他功能提供了基礎，例如提供實例突然down機后的實例恢復，為實現日志挖掘提供了基礎，為備庫的恢復提供了基礎等等。

log file sync是Oracle數據庫中最普遍的等待事件之一，一般log file sync的等待時間都非常短 1-8ms，這個時間取決于你數據庫的硬件配置、主機的負載情況等等，一般情況下把日志盤放在高端存儲上，log file sync的時間應該能維持在1-5ms之間，如果使用的是pc，有raid卡的話，log file sync的時間應該能維持在3-15ms，但是這些數據并不絕對，還要依據你數據庫的配置和負載情況來定，例如我曾經遭遇過在把日志放在本地盤，raid卡的cache有512m，log file sync接近30ms的情況，后面經過分析是由于日志寫入量和臟數據塊的寫入量太大，導致raid卡的cache有被擊穿的問題，而且當時并沒有關閉raid卡的讀cache，保留的默認的7:3的讀寫比例，一般如果使用的不是raid 5等需要做校驗的raid設置例如raid 1或raid10，都可以把raid卡的cache策略全部用于寫cache。但是對于存儲就不能這么搞了，不能夠把讀cache全部關掉，只用作寫cache，因為相對于raid卡的cache來說，本身的cache大小都比較小，所以就顯得特別寶貴，但是存儲的cache一般都比較大，例如一個中斷存儲的機頭cache也能夠8G或者16G，他們一定程度上既可以用作寫cache，又是對于主機內存的一個延續。

log file sync等待事件的P1，P2，P3參數的含義：

·  P1 ： buffer# ，log buffer中buffer的編號

·  P2，P3 未使用

產生log file sync的場景，常見有以下幾種：

·  commit操作

·  rollback操作

·  DDL操作（DDL操作實施前都會首先進行一次commit）

·  DDL操作導致的數據字典修改所產生的log file sync

·  某些能遞歸修改數據字典的操作：比如查詢SEQ的next值，可能會導致修改數據字典。一個典型的情況是，SEQ的cache屬性設置為nocache，那么會導致每次調用SEQ都要修改數據字典，產生遞歸的log file sync。

一個正常的系統里，絕大多數的log file sync等待都應該是commit操作造成的log file sync等待，某些異常的系統，比如頻繁的rollback、seq的cache設置為nocache的系統，也可能會造成比較多的log file sync等待。