建站
咨詢
售后
建站咨詢
新聞中心
這些年Oracle發(fā)展的太快，我從12C之后就比較少參與運維工作，頂多幫著客戶看看AWR報告，所以多Oracle 12C以后的很多細(xì)節(jié)實際上了解不多。搞了二十多年Oracle，從5.1用到11.2，Oracle 10G出來的時候，我就說這應(yīng)該是我學(xué)習(xí)的最后一個版本的Oracle了。沒想到?jīng)]摟住，11G又搞了10年。12C后因為不怎么做一線運維了，所以就沒怎么關(guān)注了。
創(chuàng)新互聯(lián)是一家集成都網(wǎng)站制作、成都網(wǎng)站建設(shè)、網(wǎng)站頁面設(shè)計、網(wǎng)站優(yōu)化SEO優(yōu)化為一體的專業(yè)網(wǎng)站設(shè)計公司，已為成都等多地近百家企業(yè)提供網(wǎng)站建設(shè)服務(wù)。追求良好的瀏覽體驗,以探求精品塑造與理念升華,設(shè)計最適合用戶的網(wǎng)站頁面。 合作只是第一步，服務(wù)才是根本,我們始終堅持講誠信，負(fù)責(zé)任的原則，為您進(jìn)行細(xì)心、貼心、認(rèn)真的服務(wù),與眾多客戶在蓬勃發(fā)展的市場環(huán)境中,互促共生。
前幾天群里朋友在討論PG WAL寫入存在性能問題的時候。群里有個朋友就問，難道PG這么土，不支持多個WALWRITER并發(fā)寫嗎？我當(dāng)時想都沒想就說，Oracle也不支持啊，早期Oracle支持過LGWR SLAVER，不過因為BUG太多，沒什么人用，到12C以后，好像就沒有SLAVER這碼子事兒了。當(dāng)時那個朋友就蒙圈了，Oracle咋能不支持多個LGWR并發(fā)寫呢？事后我問了問同事，他們說好像你記錯了，12C之后Oracle所有的SLAVER都被統(tǒng)一改成WORKER了。在12C里L(fēng)GWR worker是自動開啟的。
昨天正好有點空，我找了一些關(guān)于12C LGWR worker的資料看了看。在公司的測試環(huán)境上也找了一套19.15的環(huán)境檢查了一下。發(fā)現(xiàn)還真如同事所說，12C開始，Oracle已經(jīng)自動開啟LGWR并發(fā)寫了。在12C里增加了LGnn進(jìn)程，用于實際寫入REDO數(shù)據(jù)，LGWR完全不管寫Redo Log文件的事情，只負(fù)責(zé)發(fā)布一些和REDO落盤的消息了。
目前我看的關(guān)于LGWR worker的資料不多，從一些資料和我對LGWR的理解，LGWR worker應(yīng)該是和Oracle Redo Strand有關(guān)的。Oracle的LGWR worker都是分配到GROUP的，GROUP的數(shù)量如果是和Redo public Strand相關(guān)，那么每個group就之間就不需要通過鎖機制來同步寫入工作。LGWR 也不需要在多個worker之間做協(xié)同，而僅僅需要做和消息公告相關(guān)的共組了，這種機制應(yīng)該是最為高效的。如果多個worker之間寫REDO文件還需要閂鎖來做串行化，那么效率肯定是不會好的。
Redo Strand從Oracle 11開始就已經(jīng)被用來加速REDO性能了，Strand的目的是為了提高并發(fā)寫入Redo Log buffer和Redo Log文件時候的性能，減少因為串行化閂鎖等待導(dǎo)致的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稱為默認(rèn)開啟的功能打下了一個良好的基礎(chǔ)。
我這個環(huán)境的CPU_COUNT是16，而每個實例的Redo Strand最小值是2，因此啟動實例的時候也啟動了2個LGWR worker，這說明數(shù)據(jù)庫實例有兩個LGWR worker group，當(dāng)系統(tǒng)空閑，沒有什么需要寫入的REDO數(shù)據(jù)的時候，LGnn都在等待空閑等待事件LGWR worker group idle，而lgwr進(jìn)程在等待rdbms ipc message。
通過strace看lgwr，也只是在做一些信號量方面的操作。我們再來看看空閑時的LGnn。
也是在相同的信號量上休眠。
可以看出LGWR的等待事件發(fā)生了變化，而LGnn的等待事件也和以前的LGWR十分類似。從等待事件上看，當(dāng)一個worker完成工作后，會處于Ordering等待，等待獲取另外的寫任務(wù)。在具體實現(xiàn)算法上，還并沒有和我想象的一樣不需要調(diào)度。我們再來TRACE一下LGWR。
可以看出LGWR還是十分頻繁的在操作那個信號量，這很可能是LGWR在積極參與日志寫的調(diào)度協(xié)調(diào)。
從worker的行為上也看到了和LGWR之間的互動。這說明Oracle并發(fā)日志寫還是需要多進(jìn)程之間的同步行為，不是完全自主的無阻塞的。因此在某些場景下，可能會導(dǎo)致當(dāng)WORKER數(shù)量過多時，引發(fā)Log file parallel write的等待時間過長，從而引起LOG FILE SYNC的增加，影響數(shù)據(jù)庫的性能。
當(dāng)年Oracle的REDO STRAND成為默認(rèn)開啟的時候，也出現(xiàn)過類似的問題，因為STRANDS數(shù)量時和CPU_COUNT相關(guān)的。十多年前在Oracle 11g上就有人發(fā)現(xiàn)了當(dāng)CPU數(shù)量很多的時候，log file sync會莫名其妙的變壞。
當(dāng)時的建議時通過_log_parallelism_max參數(shù)來減少Strand的數(shù)量，解決過多的Strand帶來的性能問題。對于LGWR worker機制，Oracle也提供了一個類似的參數(shù)來進(jìn)行控制，這個參數(shù)就是“_max_log_write_parallelism”。
在Oracle 12C或者以后版本中，也經(jīng)常會出現(xiàn)因為LGWR worker導(dǎo)致的性能問題。Oracle可以通過“_use_single_log_writer”參數(shù)來進(jìn)行調(diào)整。默認(rèn)情況下這個參數(shù)的值時ADAPTIVE，這意味著Oracle會自己根據(jù)工作負(fù)載來選擇工作模式。如果遇到這方面的性能問題的時候，可以將這個參數(shù)設(shè)置為TRUE，強制使用單個LGWR，也就是恢復(fù)以前的工作模式。如果你發(fā)現(xiàn)你的數(shù)據(jù)庫從11G升級到12C之后，log file sync變壞了，從而導(dǎo)致了一些性能問題，你可以考慮調(diào)整這個參數(shù)。
數(shù)據(jù)庫的應(yīng)用場景十分復(fù)雜，我們享受某些應(yīng)用場景受益于一個新技術(shù)的時候，難免會引發(fā)一些新的問題，某些場景可能和新技術(shù)的適應(yīng)性不夠好。另外加上一些新技術(shù)剛剛開始使用時，對某些特殊場景的算法不夠優(yōu)化，也會引發(fā)一些問題。我想，隨著今后Oracle數(shù)據(jù)庫版本的迭代，LGWR worker的機制也會越來越成熟。
實際上我看到一些國產(chǎn)數(shù)據(jù)庫現(xiàn)在也在考慮使用多個WAL WRITER提升高并發(fā)WAL寫入的性能，從而更為充分的利用SSD等現(xiàn)代硬件。不過WAL寫入對于延時十分敏感，算法寫不好，就容易引發(fā)更為嚴(yán)重的閂鎖串行問題。Oracle的Redo Strand與LGWR worker相結(jié)合的機制應(yīng)該是目前最值得借鑒的方法了。如果不針對WAL BUFFER做Strand分區(qū)，那么多個WAL WRITER的并發(fā)控制的成本會更高。
分享題目：我們一起聊聊Oracle的LgwrWorker
當(dāng)前鏈接：http://www.5511xx.com/article/dpscegs.html
