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