前言
不知不覺(jué)，技術(shù)人生系列·我和數(shù)據(jù)中心的故事來(lái)到了第四期。小y又和大家見(jiàn)面了！
當(dāng)您看到業(yè)務(wù)系統(tǒng)壓測(cè)呈現(xiàn)以下波浪形的tps曲線時(shí)，你會(huì)怎么下手？
小y(中亦科技)今天要和大家分享的就是這樣一個(gè)業(yè)務(wù)系統(tǒng)壓測(cè)性能問(wèn)題的分析和解決過(guò)程。這個(gè)問(wèn)題困擾了客戶相當(dāng)長(zhǎng)一段時(shí)間，幸運(yùn)的是，小y通過(guò)遠(yuǎn)程在10分鐘定位到了問(wèn)題的原因并幫助客戶最終解決了問(wèn)題。需要說(shuō)明的是，在這個(gè)CASE中，只調(diào)整數(shù)據(jù)庫(kù)參數(shù)是不夠的，還需要做其他分析和調(diào)整才可以解決問(wèn)題。為了保持原汁原味，同時(shí)增加文章的趣味性，小y除了會(huì)繼續(xù)堅(jiān)持以往分析報(bào)告的寫法外，會(huì)嘗試開始引入一些問(wèn)題處理的心理歷程，希望朋友們可以了解到小y的真實(shí)工作狀態(tài)。我們能學(xué)到什么Oracle數(shù)據(jù)庫(kù)在11.2.0.3及以上的版本上必須要調(diào)整的一個(gè)重要的性能相關(guān)的參數(shù)！
如何在診斷失敗后堅(jiān)持或快速調(diào)整問(wèn)題甄別方向的技巧！
如何在處理跨團(tuán)隊(duì)/部門的綜合型問(wèn)題中掌握主動(dòng)權(quán)的一些經(jīng)驗(yàn)！
溫馨提示
如果您的高并發(fā)、事務(wù)型的OLTP核心業(yè)務(wù)系統(tǒng)中中經(jīng)常會(huì)出現(xiàn)一些性能的抖動(dòng)。比如交易響應(yīng)時(shí)間突然急劇上升,同時(shí)伴隨著ap服務(wù)器端口數(shù)/進(jìn)程活動(dòng)數(shù)/jdbc連接數(shù)升高、數(shù)據(jù)庫(kù)每秒DB TIME升高等現(xiàn)象，并且Oracle版本在11.2.0.3或以上，那么很可能和該文章提到的一個(gè)重要參數(shù)有關(guān)系哦！如果調(diào)整參數(shù)后還無(wú)法解決，可以聯(lián)系小y診斷哦(mian fei de)。Part 1
問(wèn)題來(lái)了
小y,有空嗎？幫忙看個(gè)awr。
我一會(huì)跟你電話說(shuō)一下情況。
今年他們新上的一個(gè)關(guān)鍵業(yè)務(wù)系統(tǒng)，在做上線前的壓力測(cè)試時(shí)，應(yīng)用的并發(fā)無(wú)法達(dá)到上線前的并發(fā)指標(biāo)和響應(yīng)時(shí)間指標(biāo)要求。壓測(cè)時(shí)TPS的曲線如下所示：發(fā)來(lái)QQ消息的是國(guó)內(nèi)一個(gè)大型航空公司的DBA，一般的問(wèn)題他都可以自己解決，這次看上去他遇到麻煩了。可以看到，壓測(cè)時(shí)的TPS呈現(xiàn)波浪形，極不穩(wěn)定。
客戶自己做了很多分析，資源層面，CPU、內(nèi)存使用率、IO均正常，不過(guò)客戶自己也發(fā)現(xiàn)了，壓測(cè)時(shí)后端Oracle數(shù)據(jù)庫(kù)中出現(xiàn)了大量的異常等待，主要是gc類型的等待，客戶懷疑是不是私網(wǎng)交換機(jī)有問(wèn)題。但可惜的是，網(wǎng)絡(luò)團(tuán)隊(duì)卻未檢查出異常。
這個(gè)問(wèn)題，他們也請(qǐng)現(xiàn)有的Oracle服務(wù)商進(jìn)行了分析，但問(wèn)題遲遲沒(méi)有解決。這樣一來(lái)，離業(yè)務(wù)系統(tǒng)要求上線的時(shí)間越來(lái)越近了，客戶的壓力也越來(lái)越大！
小y最近一直在跟這個(gè)客戶，從心里真心希望能有機(jī)會(huì)為他們提供服務(wù)，所以這樣的機(jī)會(huì)來(lái)了，小y自然是打起了十二分精神，準(zhǔn)備開始戰(zhàn)斗。
環(huán)境介紹：
操作系統(tǒng)Redhat 64 bit，64C 128G
數(shù)據(jù)庫(kù) Oracle 11.2.0.3 ,2節(jié)點(diǎn)RAC
Part 2
分析過(guò)程
我們用DB Time除以Elapsed，可以看到每秒DB TIME達(dá)到75！這是極度不正常的。
說(shuō)明數(shù)據(jù)庫(kù)正在經(jīng)歷嚴(yán)重的等待，需要查看數(shù)據(jù)庫(kù)top等待事件繼續(xù)分析。
事件分析
Oracle top 5等待里，gc buffer busy acquire排在第一位，占了51.2%，平均每次等待時(shí)間達(dá)到驚人的277毫秒！這里的gc buffer busy acquire表示在進(jìn)程A之前已經(jīng)有進(jìn)程B先行向節(jié)點(diǎn)2請(qǐng)求同樣的一個(gè)數(shù)據(jù)塊，并且還沒(méi)有完成，因此處在等待上。
排在第二位的是log file sync,占了18.58%，平均每次達(dá)到293毫秒。這里的log file sync表示當(dāng)進(jìn)程發(fā)出commit時(shí)，需要等lgwr后臺(tái)進(jìn)行將log buffer中的改變向量持久化到磁盤中的redo log中所發(fā)生的等待。
排在第三位的是DB CPU，在一個(gè)小時(shí)的采樣里，總的等待時(shí)間是24648秒，也就是說(shuō)大概占了7顆CPU時(shí)間，該服務(wù)器配置了64顆CPU，因此平均CPU使用率只用到了10%。這里小y順便提一下，通常情況下，我們期望DB CPU的比例越高越好，這樣就意味著SQL在執(zhí)行的過(guò)程中，幾乎不用發(fā)生等待，SQL的響應(yīng)時(shí)間也就越快。但不代表就沒(méi)問(wèn)題，比如高邏輯讀的SQL，如果要操作的數(shù)據(jù)都在內(nèi)存中，也會(huì)導(dǎo)致DB CPU過(guò)高，此時(shí)就需要對(duì)高邏輯讀的SQL進(jìn)行優(yōu)化了，從而降低 DB CPU。
排在第四位的是direct path read,平均等待時(shí)間也到了153毫秒。這里的direct path read表示進(jìn)程直接將數(shù)據(jù)塊讀入PGA內(nèi)存而不是讀進(jìn)buffer cache共享內(nèi)存。這種情況下，IO的吞吐顯然會(huì)更大，每個(gè)進(jìn)程都各自讀各自的哪怕是相同的數(shù)據(jù)。如果不同的進(jìn)程同時(shí)讀取的是相同的數(shù)據(jù)，并且讀進(jìn)共享內(nèi)存，那么只需要一個(gè)進(jìn)程負(fù)責(zé)讀取，其他進(jìn)程直接操作內(nèi)存中的數(shù)據(jù)即可，此時(shí)IO吞吐會(huì)小很多。
排在第五位的是buffer busy wait,平均等待時(shí)間到了驚人的499毫秒。這里的buffer busy wait表示當(dāng)兩個(gè)或者兩個(gè)以上的進(jìn)程需要同時(shí)對(duì)一個(gè)數(shù)據(jù)塊進(jìn)行寫/寫、寫/讀操作時(shí)發(fā)生沖突，即熱塊沖突。
看到這里，小Y已經(jīng)基本知道答案了！
不過(guò)從嚴(yán)謹(jǐn)?shù)慕嵌?，還是要把RAC 2節(jié)點(diǎn)的等待事件也稍微過(guò)一下。
2）節(jié)點(diǎn)2等待事件如下所示：和節(jié)點(diǎn)1相比，沒(méi)有buffer busy wait,多了gc current block busy。
總體來(lái)說(shuō)，兩個(gè)節(jié)點(diǎn)的等待事件差別不大！
看到這里，也許有人會(huì)說(shuō):
gc等待那么高，是不是把另外一個(gè)RAC節(jié)點(diǎn)臨時(shí)關(guān)掉，問(wèn)題就解決了呢？
首先答案是NO！其次，這樣的做法是生產(chǎn)出現(xiàn)緊急gc性能問(wèn)題時(shí)可以臨時(shí)采用的，但是對(duì)于這樣一個(gè)case,客戶顯然是不接受的。
小y從技術(shù)層面來(lái)回答下這個(gè)問(wèn)題。
首先，如下圖所示
兩個(gè)節(jié)點(diǎn)的私網(wǎng)不過(guò)是每秒3M，而RAC兩臺(tái)服務(wù)器為私網(wǎng)配置的是千兆交換機(jī)。
其次，RAC兩個(gè)節(jié)點(diǎn)的CPU和內(nèi)存均處于低位，也就沒(méi)有出現(xiàn)因?yàn)橘Y源問(wèn)題導(dǎo)致一個(gè)節(jié)點(diǎn)運(yùn)行緩慢，繼而導(dǎo)致無(wú)法快速響應(yīng)另外一個(gè)節(jié)點(diǎn)的gc請(qǐng)求的情況。
如果是該類問(wèn)題，我們通常還可以看到gc*congested*類型的等待（擁堵）。
其中bbw即buffer busy wait,
gc即表示gc buffer busy acquire等gc等待。
也許有人會(huì)說(shuō)：
gc等待那么高，還有buffer busy wait等待,如果SQL效率足夠高，那么訪問(wèn)的數(shù)據(jù)塊就少了，那么進(jìn)程發(fā)生gc請(qǐng)求的個(gè)數(shù)就很少，同時(shí)由于讀/寫造成的熱塊沖突自然也就沒(méi)了。
答案是NO！
見(jiàn)下圖，可以看到該應(yīng)用還是寫的相當(dāng)不錯(cuò)的，大部分SQL都控制在100個(gè)邏輯讀以下，只有3個(gè)SQL的邏輯讀在幾千到幾萬(wàn)，這樣的SQL效率和邏輯讀數(shù)量不足以導(dǎo)致如此高的gc/bbw等待！另外，落到SQL效率不高這個(gè)點(diǎn)上，是沒(méi)有辦法解釋log file sync/direct path read也處于平均單次長(zhǎng)時(shí)間等待的！錯(cuò)誤的方向是不能解決根本問(wèn)題的！也就是說(shuō)，即使你再花精力優(yōu)化掉這幾個(gè)邏輯讀稍微高一些的SQL，壓測(cè)的問(wèn)題還是會(huì)依然存在，因?yàn)檫@不是根本原因，優(yōu)化SQL對(duì)于這個(gè)CASE而言是錦上添花而非雪中送炭！
也許有人會(huì)說(shuō)，會(huì)不會(huì)有這樣一種可能：
先是direct path read導(dǎo)致IO帶寬被占滿
說(shuō)明：多個(gè)進(jìn)程把數(shù)據(jù)塊讀進(jìn)PGA私有內(nèi)存而不是buffer cache共享內(nèi)存，以多塊讀16計(jì)算，每個(gè)BLOCK 8K，每個(gè)進(jìn)程可以讀取30M左右，15個(gè)以上的進(jìn)程同時(shí)多塊讀就可以把hba卡帶寬占滿，設(shè)置10949 event可禁止該特性。
由于IO帶寬被占滿，影響了lgwr寫日志的響應(yīng)時(shí)間，繼而導(dǎo)致log file sync等待長(zhǎng)。
而log file sync又是gc和buffer busy wait的一個(gè)環(huán)節(jié)，從而將gc和buffer busy等待時(shí)間拉高，因此出現(xiàn)了AWR報(bào)告的等待？
首先，可以做出該假設(shè)的朋友，可以發(fā)小y發(fā)一份簡(jiǎn)歷，說(shuō)明你對(duì)數(shù)據(jù)庫(kù)有非常深入的理解，并且有非常豐富的TroubleShooting經(jīng)驗(yàn)，而且也已經(jīng)不在割裂的分析問(wèn)題的層面上了！
歡迎你加入中亦科技DBA團(tuán)隊(duì)！來(lái)了就是兄弟，我們一起并肩戰(zhàn)斗，一起挑戰(zhàn)各種疑難問(wèn)題，一起分享收益！
簡(jiǎn)歷請(qǐng)發(fā)至51994106@qq.com
那么Log file sync和gc有什么關(guān)系呢？
引用一張RAC SG的圖，其中原理如下圖所示
從上圖可以看到：
gc類的請(qǐng)求，在第二步中包含了lgwr進(jìn)程寫日志的過(guò)程，
即log file sync是gc請(qǐng)求的一個(gè)子步驟，嚴(yán)格來(lái)說(shuō)，該步驟叫g(shù)c log flush sync.
但答案依然是NO！
從下圖load profile中可以看到，每秒的物理讀是498個(gè)BLOCK，每個(gè)BLOCK是8K，也就是說(shuō)每秒的IO才4M左右。IOPS和IO帶寬都非常低，顯然不是該問(wèn)題！小y這兩分鐘里如同上述的分析一樣，飛速的進(jìn)行著各種假設(shè)和排除、問(wèn)題串聯(lián)。
很快小y就鎖定了問(wèn)題的分析方向——那就是要把分析焦點(diǎn)放在log file sync等待上！
原因很簡(jiǎn)單，通過(guò)分析top 5等待，不難看到，他們之間是有關(guān)聯(lián)關(guān)系的：
log file sync是gc和buffer busy wait的一個(gè)環(huán)節(jié)！（見(jiàn)2.3.3中的圖）
如果log file sync等待解決了，自然gc*等待和buffer busy wait等待也就下去了！
問(wèn)題也就得到解決了！
從上文，我們已經(jīng)知道，“l(fā)og file sync”等待事件表示：
當(dāng)進(jìn)程發(fā)出commit時(shí)，需要等lgwr后臺(tái)進(jìn)行將log buffer中的改變向量持久化到磁盤中的redo log的過(guò)程中所發(fā)生的等待。因此，最常見(jiàn)的是lgwr寫日志寫的慢，或者是因?yàn)閏ommit太頻繁所導(dǎo)致！
接下來(lái)小y依次檢查了這兩個(gè)方面。
ORACLE當(dāng)中，如果lgwr寫日志寫的慢，會(huì)體現(xiàn)到log file parallel write單次響應(yīng)時(shí)間慢上。
節(jié)點(diǎn)1
節(jié)點(diǎn)2可以看到，兩個(gè)節(jié)點(diǎn)無(wú)論是log file parallel write還是gc log flush sync都只在5個(gè)毫秒以下，其中l(wèi)og file parallel write更是只有1毫秒和3毫秒。排除該問(wèn)題！
接下來(lái)檢查commit次數(shù)！
如下圖所示,每秒的transactions（commits/rollbacks）只有48個(gè)！
小y服務(wù)過(guò)的一些大型銀行的高并發(fā)的核心系統(tǒng)中，包括每秒事務(wù)數(shù)在10000以上的，log file sync也都控制在10個(gè)毫秒以內(nèi)。所以每秒transactions只有48個(gè)是非常小的指標(biāo)，不至于引起這么嚴(yán)重的等待！
分析到了這里,小y已經(jīng)已經(jīng)找到本次壓測(cè)的根本原因了，只需要調(diào)整驗(yàn)證即可。
建議朋友們，讀到這里也可以先停一下，看看自己是否找到了問(wèn)題原因。
也就是客戶AWR報(bào)告發(fā)過(guò)來(lái)后的兩分鐘，小y告訴他
“我知道原因了，你把lgwr進(jìn)程的trace發(fā)我最后確認(rèn)一下，我們就開始調(diào)整”其實(shí)并不奇怪，這樣的case小y在幾年前做大量系統(tǒng)升級(jí)到11g時(shí)就遇到過(guò)N次!客戶很驚訝，他甚至還來(lái)不及電話小y，小y怎么可以這樣…
這應(yīng)該是一個(gè)上線前的標(biāo)配，雖然現(xiàn)象不一樣，但本質(zhì)上是一個(gè)問(wèn)題。
這也就是小y標(biāo)題中要重點(diǎn)提示大家的一個(gè)重要的數(shù)據(jù)庫(kù)參數(shù)。
如果Log file sync等待事件很長(zhǎng)，但是lgwr寫日志的時(shí)間很快，并且commit次數(shù)也不大的話，那就是在發(fā)起commit的進(jìn)程和lgwr之間的通訊環(huán)節(jié)上出了問(wèn)題。
關(guān)鍵知識(shí)點(diǎn):
ORACLE從11G開始，為lgwr寫日志引入了polling機(jī)制，而在以前只有post/wait機(jī)制。
同時(shí)引入了一個(gè)隱含參數(shù)，"_use_adaptive_log_file_sync"，即在兩個(gè)機(jī)制之間自適應(yīng)的切換。在11.2.0.3以下，該參數(shù)的默認(rèn)值為false,即只啟用post/wait機(jī)制。
從11.2.0.3開始，該參數(shù)的默認(rèn)值為true,即Oracle會(huì)在post/wait機(jī)制和polling機(jī)制自適應(yīng)。
Post/wait進(jìn)制下，lgwr進(jìn)程在寫完log buffer中的改變向量后，立刻通知待commit的進(jìn)程，因此log file sync等待時(shí)間短，但lgwr相對(duì)來(lái)說(shuō)，負(fù)擔(dān)要重一些。畢竟12C以下lgwr進(jìn)程只有1個(gè)，當(dāng)同時(shí)commit的進(jìn)程比較多的時(shí)候，通知待commit的進(jìn)程也是一種負(fù)擔(dān)。
Polling模式下，待commit的進(jìn)程，通知lgwr進(jìn)程進(jìn)行寫入操作后，會(huì)進(jìn)入sleep環(huán)節(jié)，并在timeout后去看是否log buffer中的內(nèi)容被寫入了磁盤，lgwr進(jìn)程不再單獨(dú)通知待commit的進(jìn)程寫已經(jīng)完成。Polling機(jī)制下，解放了一部分lgwr的工作，但是會(huì)帶來(lái)待commit的進(jìn)程長(zhǎng)時(shí)間處于log file sync等待下。對(duì)于交易型的系統(tǒng)而言，該機(jī)制是極度不適用的！
在post/wait和polling機(jī)制之間的切換，ORACLE會(huì)記錄到lgwr進(jìn)程的trace當(dāng)中，如下所示。
當(dāng)切換到polling模式下時(shí)，很容易引起log file sync等待而影響交易的響應(yīng)時(shí)間！
Log file sync switching to polling
……
Log file sync switching to post/wait
在Oracle 11.2.0.3以下，建議關(guān)閉自適應(yīng)log file sync,務(wù)必讓lgwr進(jìn)程運(yùn)行在post/wait機(jī)制下，以確保數(shù)據(jù)庫(kù)性能不會(huì)出現(xiàn)大的抖動(dòng)！關(guān)閉的命令如下，可在線修改！因此，小y在這里提示各位
alter system set "_use_adaptive_log_file_sync"=false sid='*';
沒(méi)錯(cuò)，小y的第一次調(diào)整措施就是調(diào)整該參數(shù)為false。在線調(diào)整參數(shù)后，為了安全起見(jiàn)，客戶把兩個(gè)節(jié)點(diǎn)數(shù)據(jù)庫(kù)都重啟了一遍。
并且重新做了壓力測(cè)試,重新收集后的AWR報(bào)告如下所示！
看到節(jié)點(diǎn)1的這個(gè)AWR報(bào)告，gc等待和log file sync等待依然存在，并且看上去單次等待的時(shí)間更長(zhǎng)了！
難道小y的分析出了問(wèn)題? 或者說(shuō)，小y這次遇到了好幾個(gè)摻雜在一起的問(wèn)題？冷靜了一下，RAC的問(wèn)題，切記只看單個(gè)節(jié)點(diǎn)，因此，小y讓客戶出了節(jié)點(diǎn)2的AWR報(bào)告，調(diào)整后節(jié)點(diǎn)2的awr報(bào)告如下圖所示：
可以看到：
雖然等待還在，但節(jié)點(diǎn)2的log file sync等待沒(méi)有了！這說(shuō)明這次調(diào)整還是起到效果了的！
并且細(xì)心的朋友，可能已經(jīng)發(fā)現(xiàn)了，節(jié)點(diǎn)1的第一位的等待gc buffer busy acquire完全沒(méi)有了（說(shuō)明節(jié)點(diǎn)2 log file sync快了），從gc buffer busy acquire變成了gc buffer busy release。這不正好說(shuō)明調(diào)整還是起到作用了么？到這里，先不要著急，這里因?yàn)楣?jié)點(diǎn)1依然存在log file sync,所以節(jié)點(diǎn)2的gc buffer busy acquire還依然存在！那么接下來(lái)，小y就要集中精力再解決掉節(jié)點(diǎn)1的log file sync就好了！總結(jié)一下，這里調(diào)整log file sync自適應(yīng)后，問(wèn)題還是沒(méi)有得到解決，那么回到傳統(tǒng)思路上，最可能的問(wèn)題那就還是lgwr進(jìn)程寫日志慢了！雖然awr報(bào)告中l(wèi)og file parallel write指標(biāo)只有幾個(gè)毫秒，但是awr報(bào)告畢竟是一個(gè)工具，提供的只是參考值，因此我們還是要抱著懷疑一切的態(tài)度，再來(lái)塞查一次！
這一次，我們來(lái)實(shí)時(shí)觀察lgwr進(jìn)程寫日志的情況。發(fā)出SQL語(yǔ)句，結(jié)果如下圖所示：
可以看到：
RAC兩個(gè)節(jié)點(diǎn)中，只有1個(gè)節(jié)點(diǎn)出現(xiàn)log file parallel write的等待，剛好和前面的所有分析相互吻合！
在state是waiting的情況下，log file parallel等待的seq#都是35693，但是seconds_in_wait達(dá)到了21秒。簡(jiǎn)單來(lái)說(shuō)，就是lgwr進(jìn)程寫一個(gè)IO需要21秒！
至此，我們可以肯定，IO子系統(tǒng)有問(wèn)題，需要重點(diǎn)排查IO路徑下的光纖線、SAN交換機(jī)、存儲(chǔ)的報(bào)錯(cuò)和性能情況。
節(jié)點(diǎn)1上出現(xiàn)明顯的IO ERROR，并且在持續(xù)增加！
繼續(xù)檢查節(jié)點(diǎn)2，發(fā)現(xiàn)節(jié)點(diǎn)2上沒(méi)有任何IO ERROR！
回顧前面的分析，節(jié)點(diǎn)2在調(diào)整數(shù)據(jù)庫(kù)自適應(yīng)log file sync為false后，并且沒(méi)有出現(xiàn)IO ERROR，因此已經(jīng)沒(méi)有l(wèi)og file sync。
至此，分析結(jié)束！所有問(wèn)題都得到了完美的解釋！
找到原因了，還拿到了說(shuō)服力極強(qiáng)的證據(jù)，客戶終于松了一口氣，不怕存儲(chǔ)團(tuán)隊(duì)不認(rèn)賬了！
Part 3
問(wèn)題原因和總結(jié)和風(fēng)險(xiǎn)提示
該航空客戶業(yè)務(wù)上線時(shí)壓測(cè)無(wú)法達(dá)到并發(fā)和響應(yīng)時(shí)間指標(biāo)的原因在于同時(shí)遇到了兩個(gè)混在一起的問(wèn)題：
1）Oracle 11.2.0.3上log file sync默認(rèn)打開自適應(yīng)，當(dāng)切換到polling模式后，導(dǎo)致log file sync等待時(shí)間變長(zhǎng)，而log file sync是gc和buffer busy wait的一個(gè)環(huán)節(jié)，因此導(dǎo)致大量的等待
小y將"_use_adaptive_log_file_sync"調(diào)整為false后，就解決了一部分的log file sync等待的問(wèn)題
2）由于節(jié)點(diǎn)1的光纖線存在質(zhì)量問(wèn)題，會(huì)導(dǎo)致IO錯(cuò)誤，繼而導(dǎo)致IO重發(fā)，影響了lgwr寫日志的性能。
在調(diào)整數(shù)據(jù)庫(kù)參數(shù)默認(rèn)值并且更換光纖線后，問(wèn)題得到圓滿解決。
壓測(cè)的TPS曲線從原來(lái)的波浪形
變成了如下的良好曲線1）對(duì)Oracle等待事件不要割裂的來(lái)分析
小y在本case中通過(guò)梳理等待事件的共同點(diǎn)為log file sync,從而找到了突破口
2）了解不同版本數(shù)據(jù)庫(kù)的特性和行為
小y平時(shí)在不斷了解11g的新特性，并且通過(guò)大量的故障處理深入理解了這些特性，因此，當(dāng)log file sync出現(xiàn)的時(shí)候，可以很快定位到新特性引起
3）不要完全相信AWR報(bào)告，他只是個(gè)工具，要懷疑一切去驗(yàn)證。
在這個(gè)case中，awr報(bào)告的指標(biāo)并不能真實(shí)反映lgwr寫性能的情況，要懷疑一切
4）一個(gè)Oracle服務(wù)人員，如果只懂?dāng)?shù)據(jù)庫(kù)，就會(huì)出現(xiàn)你懷疑這懷疑那，但是其他人根本不認(rèn)賬的情況，因此必須掌握更多的包括操作系統(tǒng)、存儲(chǔ)、網(wǎng)絡(luò)、中間件的技能。當(dāng)然了，找一家綜合服務(wù)能力強(qiáng)的服務(wù)商也是不錯(cuò)的選擇。
在這個(gè)case中，小y通過(guò)多路徑的命令，找到了直接證據(jù)，最終獲得了其他團(tuán)隊(duì)的大力度排查也是這次問(wèn)題最終解決的關(guān)鍵。
風(fēng)險(xiǎn)提示
ORACLE從11G開始，為lgwr寫日志引入了polling機(jī)制，而在以前只有post/wait機(jī)制。
同時(shí)引入了一個(gè)隱含參數(shù)，"_use_adaptive_log_file_sync"，即在兩個(gè)機(jī)制之間自適應(yīng)的切換。在11.2.0.3以下，該參數(shù)的默認(rèn)值為false,即只啟用post/wait機(jī)制。
從11.2.0.3開始，該參數(shù)的默認(rèn)值為true,即Oracle會(huì)在post/wait機(jī)制和polling機(jī)制自適應(yīng)。
Post/wait進(jìn)制下，lgwr進(jìn)程在寫完log buffer中的改變向量后，立刻通知待commit的進(jìn)程，因此log file sync等待時(shí)間短，但lgwr相對(duì)來(lái)說(shuō)，負(fù)擔(dān)要重一些。畢竟12C以下lgwr進(jìn)程只有1個(gè)，當(dāng)同時(shí)commit的進(jìn)程比較多的時(shí)候，通知待commit的進(jìn)程也是一種負(fù)擔(dān)。
Polling模式下，待commit的進(jìn)程，通知lgwr進(jìn)程進(jìn)行寫入操作后，會(huì)進(jìn)入sleep環(huán)節(jié)，并在timeout后去看是否log buffer中的內(nèi)容被寫入了磁盤，lgwr進(jìn)程不再單獨(dú)通知待commit的進(jìn)程寫已經(jīng)完成。Polling機(jī)制下，解放了一部分lgwr的工作，但是會(huì)帶來(lái)待commit的進(jìn)程長(zhǎng)時(shí)間處于log file sync等待下。對(duì)于交易型的系統(tǒng)而言，該機(jī)制是極度不適用的！
進(jìn)制之間的切換回記錄到lgwr進(jìn)程的trace當(dāng)中，如下所示。
當(dāng)切換到polling模式下時(shí)，很容易引起log file sync等待而影響交易的響應(yīng)時(shí)間！
Log file sync switching to polling
……
Log file sync switching to post/wait
因此，小y在這里提示各位。
在Oracle 11.2.0.3以下，建議關(guān)閉自適應(yīng)log file sync,務(wù)必讓lgwr進(jìn)程運(yùn)行在post/wait機(jī)制下，以確保數(shù)據(jù)庫(kù)不會(huì)出現(xiàn)嚴(yán)重的性能抖動(dòng)！關(guān)閉的命令如下，可在線修改！
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。
重慶分公司
重慶分公司
