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等待。