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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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