從log file sync問題的根因分析談起：我們為什么需要了解國產數據庫的一些原理性知識
前幾天我發文說希望國產數據庫廠商能夠多發布一些自己產品的INTERNAL的資料出來。有些朋友不大理解，數據庫廠商只要多發一些故障處理的方案出來不比發INTERNAL資料更香嗎，比如XX數據庫就很不錯，文檔里有大幾十種常見故障的分析處置詳細方案。實際上數據庫故障是個十分復雜的系統性問題，很難用多少種來涵蓋，有些時候，某個組件在不同的情況下也會有多種多樣的故障場景。如果像網友所說的那種國產數據庫，把客戶側常見的故障整理得很好，但是對自己的內部原理藏得很深，那么如果遇到了文檔沒有涵蓋的問題，不還是抓瞎嗎？
今天我用Log file sync問題的分析讓大家更加直觀地了解到理解數據庫的某些原理，對于故障 排查是如何的重要。Log File Sync是一個十分常見的問題，不過要分析起來也不那么容易。因為想要涵蓋復雜的場景十分困難。幸運的是OCP培訓教材里有好幾張對于理解Log File Sync問題十分有效的示意圖，下面是第一張。
圖片
上面一張圖列出了單機數據庫等待Log File Sync時的Oracle內部處理流程。從圖中可以很清楚地看出，Log File Sync等待與Log File parallel write等待關系很大。事務提交時，在等待LGWR將該事務相關的所有REDO矢量寫盤時，就會產生這個等待。我們可以很清晰地了解到，如果log file parallel write的等待時間比較長時，log File sync肯定也會比較長。如果log file parallel write/log file sync>0.7，那么問題的根因大概率會落在這個問題上。
這就是Log File sync等待最常見的問題根因-日志文件寫入比較慢。日志文件寫入比較慢可能是因為底層IO比較慢，也有可能是當時產生的日志量過大了。如果是LGWR寫入過慢，那么查看LGWR的TRACE文件（如果是12.2以后的版本，還需要看lgxx日志）可能會得到一些蛛絲馬跡。
圖片
如果頻繁出現日志寫延時超過500毫秒的告警，那么很可能就是LGWR寫得太慢了。如果存在偶發性的告警，則可以忽略。
如果log file parallel write的等待時間很正常，而且與log file sync的比例很低，那么說明問題出在其他方面。比如Log buffer太小（和每秒redo量的比值可以看出是否過小），或者是因為adaptive redo log的設置問題（這個問題在 11.2中存在問題），自適應切換POST /WAIT,POLLING兩種IPC機制，可能會導致log file sync變壞。P/W是傳統的模式，適合于REDO并發生成量并不是很大，每次LGWR寫的總量并不多的情況，POLLING在大并發下性能更加。Oracle會根據負載自動切換模式，從而獲得更好的性能。不過有時候切換過于頻繁了，很多時間都消耗在切換模式上了，反而會引發性能問題。這時候就需要關閉這種動態切換機制了。
圖片
從第一張圖中，我們已經把很常見的log File sync性能問題分析清楚了，不過還不足夠，有時候上面的問題都不存在，但是Log File sync延時還是很大。對了，這是在RAC環境中。如果我們不了解第二章圖，那么我們對Log file sync問題的認知是存在瑕疵的。因為在RAC環境中，還存在一個RAC集群中的commit SCN廣播問題，Log File sync的時間當然也還包含這些延時。因此LMS后臺進程的卡頓，集群網絡通訊的延時，以及GCS方面的等待，都可能會影響log file sync。去年一個銀行的朋友和我探討是否要把他們核心系統的RAC拆成HA，因為從他們的分析發現，RAC帶來的核心交易延時的增加已經超過了10%。
圖片
除此之外，在分析Log File sync問題的時候，還需要關注redo write broadcast ack count/redo write broadcast ack time這組指標。它們的值和RAC環境中Log File sync等待延時是密切相關的。
當然，Log File sync等待過大，還和很多BUG有關，這些BUG在MOS上都可以很方便地查到。這就是在使用Oracle數據庫時做根因分析相對比較容易的主要原因。
我今天所表述的知識在Oracle官方文檔、OCP培訓教材和MOS上都可以輕松找到。而通過對這些INTERNAL知識的學習，我們可以十分準確地將某個問題可能的根因都分析得清清楚楚，哪怕遇到了一些十分詭異和古怪的事情的時候，也能夠輕松地應對。
對于運維數據庫這樣的復雜IT系統時，最大的恐懼來自于未知。對于原理的一無所知，是運維中最為可怕的事情。所以我還是希望國產數據庫原廠大佬們，哪怕你們再忙，也抽出點空來，多寫一寫Internal的東西，并且把它們公開發布出來。如果你們確實沒有空，也沒關系，可以把一些技術資料交給一些社區和第三方的專家，讓他們幫你們寫文章傳播知識，我想還是有不少這樣的熱心群眾愿意干這種事情的。
