這些年Oracle發展的太快，我從12C之后就比較少參與運維工作，頂多幫著客戶看看AWR報告，所以多Oracle 12C以后的很多細節實際上了解不多。搞了二十多年Oracle，從5.1用到11.2，Oracle 10G出來的時候，我就說這應該是我學習的最后一個版本的Oracle了。沒想到沒摟住，11G又搞了10年。12C后因為不怎么做一線運維了，所以就沒怎么關注了。

前幾天群里朋友在討論PG WAL寫入存在性能問題的時候。群里有個朋友就問，難道PG這么土，不支持多個WALWRITER并發寫嗎？我當時想都沒想就說，Oracle也不支持啊，早期Oracle支持過LGWR SLAVER，不過因為BUG太多，沒什么人用，到12C以后，好像就沒有SLAVER這碼子事兒了。當時那個朋友就蒙圈了，Oracle咋能不支持多個LGWR并發寫呢？事后我問了問同事，他們說好像你記錯了，12C之后Oracle所有的SLAVER都被統一改成WORKER了。在12C里LGWR worker是自動開啟的。

昨天正好有點空，我找了一些關于12C LGWR worker的資料看了看。在公司的測試環境上也找了一套19.15的環境檢查了一下。發現還真如同事所說，12C開始，Oracle已經自動開啟LGWR并發寫了。在12C里增加了LGnn進程，用于實際寫入REDO數據，LGWR完全不管寫Redo Log文件的事情，只負責發布一些和REDO落盤的消息了。

目前我看的關于LGWR worker的資料不多，從一些資料和我對LGWR的理解，LGWR worker應該是和Oracle Redo Strand有關的。Oracle的LGWR worker都是分配到GROUP的，GROUP的數量如果是和Redo public Strand相關，那么每個group就之間就不需要通過鎖機制來同步寫入工作。LGWR 也不需要在多個worker之間做協同，而僅僅需要做和消息公告相關的共組了，這種機制應該是最為高效的。如果多個worker之間寫REDO文件還需要閂鎖來做串行化，那么效率肯定是不會好的。

Redo Strand從Oracle 11開始就已經被用來加速REDO性能了，Strand的目的是為了提高并發寫入Redo Log buffer和Redo Log文件時候的性能，減少因為串行化閂鎖等待導致的REDO性能問題。Oracle會根據CPU_COUNT的值，自動的調整Redo srand的數量。

Oracle會根據CPU_COUNT/16來設定Strand的數量，在LOG BUFFER中會按照Strand數量劃分為N個子池，寫入REDO數據的時候，可以并發的寫入不同的STRAND，這樣可以減少高并發LOG BUFFER寫入的性能。為了確保這一機制起作用，在Redo Log文件中，也是按照Strand的方式分配Redo Log文件，這種模式可以讓Redo Log文件的寫入也可以高速并發。Redo Strand為12C的LGWR worker稱為默認開啟的功能打下了一個良好的基礎。

我這個環境的CPU_COUNT是16，而每個實例的Redo Strand最小值是2，因此啟動實例的時候也啟動了2個LGWR worker，這說明數據庫實例有兩個LGWR worker group，當系統空閑，沒有什么需要寫入的REDO數據的時候，LGnn都在等待空閑等待事件LGWR worker group idle，而lgwr進程在等待rdbms ipc message。

通過strace看lgwr，也只是在做一些信號量方面的操作。我們再來看看空閑時的LGnn。

也是在相同的信號量上休眠。

可以看出LGWR的等待事件發生了變化，而LGnn的等待事件也和以前的LGWR十分類似。從等待事件上看，當一個worker完成工作后，會處于Ordering等待，等待獲取另外的寫任務。在具體實現算法上，還并沒有和我想象的一樣不需要調度。我們再來TRACE一下LGWR。

可以看出LGWR還是十分頻繁的在操作那個信號量，這很可能是LGWR在積極參與日志寫的調度協調。

從worker的行為上也看到了和LGWR之間的互動。這說明Oracle并發日志寫還是需要多進程之間的同步行為，不是完全自主的無阻塞的。因此在某些場景下，可能會導致當WORKER數量過多時，引發Log file parallel write的等待時間過長，從而引起LOG FILE SYNC的增加，影響數據庫的性能。

當年Oracle的REDO STRAND成為默認開啟的時候，也出現過類似的問題，因為STRANDS數量時和CPU_COUNT相關的。十多年前在Oracle 11g上就有人發現了當CPU數量很多的時候，log file sync會莫名其妙的變壞。

當時的建議時通過_log_parallelism_max參數來減少Strand的數量，解決過多的Strand帶來的性能問題。對于LGWR worker機制，Oracle也提供了一個類似的參數來進行控制，這個參數就是“_max_log_write_parallelism”。

在Oracle 12C或者以后版本中，也經常會出現因為LGWR worker導致的性能問題。Oracle可以通過“_use_single_log_writer”參數來進行調整。默認情況下這個參數的值時ADAPTIVE，這意味著Oracle會自己根據工作負載來選擇工作模式。如果遇到這方面的性能問題的時候，可以將這個參數設置為TRUE，強制使用單個LGWR，也就是恢復以前的工作模式。如果你發現你的數據庫從11G升級到12C之后，log file sync變壞了，從而導致了一些性能問題，你可以考慮調整這個參數。

數據庫的應用場景十分復雜，我們享受某些應用場景受益于一個新技術的時候，難免會引發一些新的問題，某些場景可能和新技術的適應性不夠好。另外加上一些新技術剛剛開始使用時，對某些特殊場景的算法不夠優化，也會引發一些問題。我想，隨著今后Oracle數據庫版本的迭代，LGWR worker的機制也會越來越成熟。

實際上我看到一些國產數據庫現在也在考慮使用多個WAL WRITER提升高并發WAL寫入的性能，從而更為充分的利用SSD等現代硬件。不過WAL寫入對于延時十分敏感，算法寫不好，就容易引發更為嚴重的閂鎖串行問題。Oracle的Redo Strand與LGWR worker相結合的機制應該是目前最值得借鑒的方法了。如果不針對WAL BUFFER做Strand分區，那么多個WAL WRITER的并發控制的成本會更高。