資訊專欄INFORMATION COLUMN
大家好！最近遇到一起數(shù)據(jù)庫hang的故障，將其處理思路分享下。
環(huán)境：
操作系統(tǒng)：AIX
數(shù)據(jù)庫版本：12.2
是否RAC：是
分析過程請容我一一道來：
某日，同事反饋數(shù)據(jù)庫節(jié)點2有很多cursor:pin S wait on X異常等待事件，與此同時librarycache lock也伴隨出現(xiàn)，不過librarycache lock不是一直都存在，查詢異常等待事件偶爾出現(xiàn)。這個時候會話開始出現(xiàn)積壓，應(yīng)用反饋應(yīng)用異常。
登錄數(shù)據(jù)庫主機發(fā)現(xiàn)節(jié)點1正常、節(jié)點2一堆的cursor:pin S wait onX，甚至于登錄到數(shù)據(jù)庫都很慢，趕緊做了hanganalyze，做完快照之后，開始kill異常等待事件相關(guān)的會話進(jìn)程，但是數(shù)據(jù)庫依舊一大堆cursor等待事件。此時內(nèi)存接近于耗盡，數(shù)據(jù)庫已處于hang的狀態(tài)，為了盡快恢復(fù)業(yè)務(wù)，當(dāng)即對節(jié)點2實例進(jìn)行了重啟，重啟后恢復(fù)正常。
后面同事反映這庫節(jié)點2之前相同時段出現(xiàn)過很多cursor:pin S wait on X異常等待的情況，過會自動恢復(fù)正常了，沒有和今天這樣數(shù)據(jù)庫hang，當(dāng)時查到是由于SQL頻次突增導(dǎo)致。
1、接下來開始對故障進(jìn)行分析，我們首先查看hanganalyze日志如下：
發(fā)現(xiàn)都是在等待rowcache lock。
2、繼續(xù)查看堵塞鏈
Chain1:
從上圖我們可以看到Chain1，堵塞源是節(jié)點2，SID：1215的會話，此時它堵塞了195個會話，其正在等待cacheid:0X10的ROWCACHE。
Chain2:
接下來分析Chain2，堵塞源是節(jié)點2，SID：2419的會話，此時它堵塞了3個會話，其正在等待cacheid:0X10的ROWCACHE。
Chain3:
繼續(xù)分析Chain3，堵塞源是節(jié)點2，SID：6642的會話，此時它堵塞了11個會話，其正在等待cacheid:0X10的ROWCACHE。
Chain4:
以上總結(jié)：
從以上的堵塞Chain我們可以看到堵塞源都在等待cacheid:0X10的ROWCACHE。其正在運行的SQL均為查詢數(shù)據(jù)庫基表或試圖的SQL。并且我們竟然發(fā)現(xiàn)在故障時段數(shù)據(jù)庫的自動收集統(tǒng)計信息的JOB在運行，這JOB我們在上線之前就把其調(diào)用窗口調(diào)整到晚上10點開始，早上6點結(jié)束。至于為啥白天會調(diào)起，我們后面在另起一篇多帶帶聊聊這事。
3、我們在數(shù)據(jù)庫查了下cacheid:0X10的數(shù)據(jù)字典緩存，詳細(xì)如下：
我們從故障時段的AWR也可以看到中這2種ROWCACHE被訪問的比較多。
一般對于RowCache Lock相關(guān)的等待，通常是由于過度的SQL執(zhí)行解析和sharepool不足導(dǎo)致的。
4、繼續(xù)分析AWR
從上圖我們可以看到SQL運行大部分時間都花在解析上，sharedpool latches上的活動會話占比很高。
正常時段：
故障時段：
查看除了TOP1SQL解析次數(shù)在與平時正常相應(yīng)時段進(jìn)行比對發(fā)現(xiàn)解析次數(shù)并沒有出現(xiàn)突增的情況。但是圖中其他SQL其解析或執(zhí)行次數(shù)都較平時增長不少。
這里就有個疑問了，為啥都是同樣的頻次突增，為啥之前一下就自動恢復(fù)了，這次就hang了呢？
綜合以上情況初步確定，由于sharedpool空閑較少，然后應(yīng)用SQL頻次有增加，并且發(fā)現(xiàn)部分查詢數(shù)據(jù)字典的SQL出現(xiàn)查詢緩慢甚至查不出來的情況，會話積壓導(dǎo)致內(nèi)存不足，此時自動收集統(tǒng)計信息的JOB原本是晚上10點調(diào)起的，但是故障時段下午2點也開始調(diào)起，成為壓死數(shù)據(jù)庫的最后一根稻草。
解決方案：
收集了數(shù)據(jù)字典的統(tǒng)計信息，將部分查詢數(shù)據(jù)字典的SQL綁定了最優(yōu)執(zhí)行計劃。并進(jìn)行了sharedpool的大小調(diào)整，在原來的基礎(chǔ)上增加了SGA預(yù)留的2G，并部署了sharedpool剩余空間的監(jiān)控，少于500M告警。并要求應(yīng)用側(cè)整改SQL突增的問題，從目前來看這些方式行之有效，到目前為止數(shù)據(jù)庫再無發(fā)生過類似的故障。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://specialneedsforspecialkids.com/yun/130091.html
摘要：昨天凌晨，阿里云出現(xiàn)大規(guī)模故障，導(dǎo)致部分互聯(lián)網(wǎng)公司和運行不暢，甚至癱瘓。阿里云表示，針對此次故障，將根據(jù)協(xié)議，盡快處理賠償事宜，但并未公開詳細(xì)的賠償細(xì)節(jié)。事實上，這并非阿里云首次出現(xiàn)故障。由此可見，阿里云此次宕機事件影響程度著實不小。昨天凌晨，阿里云出現(xiàn)大規(guī)模故障，導(dǎo)致部分互聯(lián)網(wǎng)公司和App運行不暢，甚至癱瘓。一時之間，阿里云官微下幾乎被反饋宕機問題的留言攻陷，有網(wǎng)友調(diào)侃稱，程序員、運營和運...
摘要：方法沒有設(shè)置返回值。解決思路是，當(dāng)遇到任務(wù)的返回值是一個或者，并且有自己的方法的時候，就將它當(dāng)做是一個對象處理，等這個對象中的方法處理到的時候，把作為參數(shù)輸出傳遞給后續(xù)的任務(wù)。 前段時間看到關(guān)于microTask的文章，《Tasks, microTasks, queues and schedules》，感覺有必要澄清一下。本篇里用setTimeout來實現(xiàn)的Promise，和瀏覽器原生...
摘要：還有從歐洲飛來的不同國籍的講師和長期在社區(qū)活躍貢獻(xiàn)的開發(fā)者將與大家在北京相聚。將是一次亞洲社區(qū)的大聚會，也因為此次大會，亞洲本土的社區(qū)連接到了全球其它地區(qū)的社區(qū)。大會現(xiàn)場將有同傳支持，所以不必?fù)?dān)心語言障礙。 RustCon Asia 上線 CFP（Call For Proposals）接受議題提交的兩周時間里，我們共計收到了中英文議題 50 份！內(nèi)容非常豐富并且比我們預(yù)期的更加多元，在...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20
