這些年Oracle發(fā)展的太快，我從12C之后就比較少參與運(yùn)維工作，頂多幫著客戶看看AWR報(bào)告，所以多Oracle 12C以后的很多細(xì)節(jié)實(shí)際上了解不多。搞了二十多年Oracle，從5.1用到11.2，Oracle 10G出來(lái)的時(shí)候，我就說(shuō)這應(yīng)該是我學(xué)習(xí)的最后一個(gè)版本的Oracle了。沒(méi)想到?jīng)]摟住，11G又搞了10年。12C后因?yàn)椴辉趺醋鲆痪€運(yùn)維了，所以就沒(méi)怎么關(guān)注了。

前幾天群里朋友在討論P(yáng)G WAL寫(xiě)入存在性能問(wèn)題的時(shí)候。群里有個(gè)朋友就問(wèn)，難道PG這么土，不支持多個(gè)WALWRITER并發(fā)寫(xiě)嗎？我當(dāng)時(shí)想都沒(méi)想就說(shuō)，Oracle也不支持啊，早期Oracle支持過(guò)LGWR SLAVER，不過(guò)因?yàn)锽UG太多，沒(méi)什么人用，到12C以后，好像就沒(méi)有SLAVER這碼子事兒了。當(dāng)時(shí)那個(gè)朋友就蒙圈了，Oracle咋能不支持多個(gè)LGWR并發(fā)寫(xiě)呢？事后我問(wèn)了問(wèn)同事，他們說(shuō)好像你記錯(cuò)了，12C之后Oracle所有的SLAVER都被統(tǒng)一改成WORKER了。在12C里L(fēng)GWR worker是自動(dòng)開(kāi)啟的。

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

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

Redo Strand從Oracle 11開(kāi)始就已經(jīng)被用來(lái)加速REDO性能了，Strand的目的是為了提高并發(fā)寫(xiě)入Redo Log buffer和Redo Log文件時(shí)候的性能，減少因?yàn)榇谢V鎖等待導(dǎo)致的REDO性能問(wèn)題。Oracle會(huì)根據(jù)CPU_COUNT的值，自動(dòng)的調(diào)整Redo srand的數(shù)量。

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

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

通過(guò)strace看lgwr，也只是在做一些信號(hào)量方面的操作。我們?cè)賮?lái)看看空閑時(shí)的LGnn。

也是在相同的信號(hào)量上休眠。

可以看出LGWR的等待事件發(fā)生了變化，而LGnn的等待事件也和以前的LGWR十分類似。從等待事件上看，當(dāng)一個(gè)worker完成工作后，會(huì)處于Ordering等待，等待獲取另外的寫(xiě)任務(wù)。在具體實(shí)現(xiàn)算法上，還并沒(méi)有和我想象的一樣不需要調(diào)度。我們?cè)賮?lái)TRACE一下LGWR。

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

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

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

當(dāng)時(shí)的建議時(shí)通過(guò)_log_parallelism_max參數(shù)來(lái)減少Strand的數(shù)量，解決過(guò)多的Strand帶來(lái)的性能問(wèn)題。對(duì)于LGWR worker機(jī)制，Oracle也提供了一個(gè)類似的參數(shù)來(lái)進(jìn)行控制，這個(gè)參數(shù)就是“_max_log_write_parallelism”。

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

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

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