資訊專欄INFORMATION COLUMN
大家好！最近遇到一起數(shù)據(jù)庫節(jié)點(diǎn)實(shí)例異常重啟故障，隨筆記記。
數(shù)據(jù)庫節(jié)點(diǎn)3因大量高并發(fā)insert語句導(dǎo)致sql積壓，從而短時(shí)間內(nèi)消耗大量主機(jī)資源，對數(shù)據(jù)庫性能產(chǎn)生了很大影響，嚴(yán)重影響數(shù)據(jù)庫的正常運(yùn)行，導(dǎo)致節(jié)點(diǎn)3數(shù)據(jù)庫發(fā)生重啟。
1、20點(diǎn)28分左右，收到節(jié)點(diǎn)3大量sql積壓短信告警,積壓SQL主要為：9yy1zhgjvfbpj。
節(jié)點(diǎn)3：
2、登陸環(huán)境核查數(shù)據(jù)庫實(shí)例狀態(tài)及實(shí)例啟動(dòng)時(shí)間，20點(diǎn)36分確認(rèn)數(shù)據(jù)庫實(shí)例狀態(tài)正常，且實(shí)例沒有重啟。當(dāng)即對異常等待事件的sql進(jìn)行查殺，但是由于應(yīng)用還在不停的發(fā)起連接，在20點(diǎn)45分時(shí)節(jié)點(diǎn)3發(fā)生重啟。
3、查看主機(jī)日志，并確認(rèn)無異常報(bào)錯(cuò)信息。
節(jié)點(diǎn)3主機(jī)日志：
4、通過檢查數(shù)據(jù)庫運(yùn)行狀況時(shí)發(fā)現(xiàn)節(jié)點(diǎn)3上有大量sql積壓的等待事件
對應(yīng)等待事件主要為：enq:us-contention，rowcache local行緩存鎖,enq: IV - contention隊(duì)列等待之詢問IV。
附：
enq:us-contention：
這個(gè)等待事件有許多脫機(jī)撤消段，并且工作負(fù)載在短時(shí)間內(nèi)開始聯(lián)機(jī)許多撤消段。當(dāng)使用具有自動(dòng)調(diào)整的撤銷保留期的系統(tǒng)管理撤銷時(shí)，這可能會(huì)導(dǎo)致在DC_ROLLBACK_SEGMENTS上出現(xiàn)高“閂鎖：行緩存對象”爭用，同時(shí)出現(xiàn)高“enq:US-爭用”等待。
rowcache local：
該是一個(gè)共享池相關(guān)的等待事件。是由于對于字典緩沖的訪問造成的。每一個(gè)行緩沖隊(duì)列鎖都對應(yīng)一個(gè)特定的數(shù)據(jù)字典對象，這被叫做隊(duì)列鎖類型，并可以在V$ROWCACHE視圖中找到。在AWR中需要查看DictionaryCache Stats部分用以確定問題。
enq:IV - contention：
物化視圖（mview）有兩部分：（1）保存數(shù)據(jù)的表，和（2）摘要對象。當(dāng)提交mview基表上的DML時(shí)，summary對象將失效。這是必要的，因?yàn)?/span>mview可能需要用于查詢重寫。失效采用IV排隊(duì)，直到summary對象在所有節(jié)點(diǎn)上失效為止。如果存在大量摘要無效，則會(huì)導(dǎo)致此排隊(duì)上的爭用。
5、通過核查節(jié)點(diǎn)3上sql積壓等待事件對應(yīng)的會(huì)話信息，定位到積壓sql對應(yīng)的sql_id，查到其sql文本就是一個(gè)insert語句。
節(jié)點(diǎn)3：
6、故障時(shí)間段節(jié)點(diǎn)3redo變化分析。
故障時(shí)間段每秒產(chǎn)生的redo量相比正常時(shí)間段增長了約180%。
故障時(shí)間段每秒產(chǎn)生redo量：
正常時(shí)間段每秒產(chǎn)生redo量：
7、查看會(huì)話變化情況發(fā)現(xiàn)從20點(diǎn)15分開始數(shù)據(jù)庫會(huì)話開始突增。
8、通過分析故障時(shí)間段哪些SQL占用了資源，發(fā)現(xiàn)其中sql_id為9yy1zhgjvfbpj的語句占用了數(shù)據(jù)庫48.24%的DBTIME。并最終于20:45分CPU資源耗盡導(dǎo)致實(shí)例重啟。
9yy1zhgjvfbpj語句執(zhí)行頻次突增截圖如下所示，11月2日故障時(shí)間段該sql執(zhí)行頻次上下浮動(dòng)較大，而本次故障時(shí)間段該sql每分鐘的執(zhí)行頻次持續(xù)保持在四千+，最高峰甚至達(dá)到1萬+
結(jié)論：sql_id為9yy1zhgjvfbpj的語句因高并發(fā)且頻次突增，引發(fā)數(shù)據(jù)庫序列及undo爭用，消耗了大量的數(shù)據(jù)庫資源，數(shù)據(jù)庫主機(jī)最終CPU資源耗盡導(dǎo)致實(shí)例重啟。
建議一：應(yīng)用連接降低并發(fā)，并查詢到該SQL是單次commit，建議修改成批量提交。
建議二：先將高并發(fā)insert寫入內(nèi)存庫，然后在批量同步至核心庫。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.hztianpu.com/yun/130007.html
摘要：哨兵是社區(qū)版本推出的原生高可用解決方案，部署架構(gòu)主要包括兩部分集群和數(shù)據(jù)集群，其中集群是由若干節(jié)點(diǎn)組成的分布式集群。自研推薦推薦自研的高可用解決方案，主要體現(xiàn)在配置中心故障探測和的處理機(jī)制上，通常需要根據(jù)企業(yè)業(yè)務(wù)的實(shí)際線上環(huán)境來定制化。 最近很多朋友向我咨詢關(guān)于高可用的方案的優(yōu)缺點(diǎn)以及如何選擇合適的方案線上使用，剛好最近在給宜人貸，光大銀行做企業(yè)內(nèi)訓(xùn)的時(shí)候也詳細(xì)講過，這里我再整理發(fā)出來...
摘要：哨兵是社區(qū)版本推出的原生高可用解決方案，部署架構(gòu)主要包括兩部分集群和數(shù)據(jù)集群，其中集群是由若干節(jié)點(diǎn)組成的分布式集群。自研推薦推薦自研的高可用解決方案，主要體現(xiàn)在配置中心故障探測和的處理機(jī)制上，通常需要根據(jù)企業(yè)業(yè)務(wù)的實(shí)際線上環(huán)境來定制化。 最近很多朋友向我咨詢關(guān)于高可用的方案的優(yōu)缺點(diǎn)以及如何選擇合適的方案線上使用，剛好最近在給宜人貸，光大銀行做企業(yè)內(nèi)訓(xùn)的時(shí)候也詳細(xì)講過，這里我再整理發(fā)出來...
此文已由作者王盼授權(quán)網(wǎng)易云社區(qū)發(fā)布。 歡迎訪問網(wǎng)易云社區(qū)，了解更多網(wǎng)易技術(shù)產(chǎn)品運(yùn)營經(jīng)驗(yàn)~ 現(xiàn)狀計(jì)算節(jié)點(diǎn)發(fā)生磁盤損壞等數(shù)據(jù)無法恢復(fù)的異常時(shí)，節(jié)點(diǎn)上的云主機(jī)系統(tǒng)盤無法恢復(fù)，導(dǎo)致云主機(jī)只能被清理重建 計(jì)算節(jié)點(diǎn)宕機(jī)但磁盤數(shù)據(jù)可用時(shí)，重啟即可恢復(fù)所有云主機(jī)的運(yùn)行 計(jì)算節(jié)點(diǎn)多次宕機(jī)（或一段時(shí)間內(nèi)頻繁宕機(jī)），則需要遷移所有云主機(jī)或者直接清理重建，云硬盤需要遷移到其他cinder-volume存儲(chǔ)服務(wù)節(jié)點(diǎn) 一般來...
摘要：原文鏈接解決了什么問題使用模型來克服傳統(tǒng)面向?qū)ο缶幊棠Ｐ偷木窒扌裕?yīng)對高并發(fā)分布式系統(tǒng)所帶來的挑戰(zhàn)。在某些情況，這個(gè)問題可能會(huì)變得更糟糕，工作線程發(fā)生了錯(cuò)誤但是其自身卻無法恢復(fù)。 這段時(shí)間由于忙畢業(yè)前前后后的事情，拖更了很久，表示非常抱歉，回歸后的第一篇文章主要是看到了Akka最新文檔中寫的What problems does the actor model solve?,閱讀完后覺...
摘要：祈使式的腳本很難長期地對系統(tǒng)狀態(tài)進(jìn)行自動(dòng)維護(hù)。這些事件包括的創(chuàng)建消亡的更新例如標(biāo)簽副本數(shù)量等。每當(dāng)上述事件發(fā)生，這個(gè)事件所牽扯到的具體的對象就會(huì)被放入這個(gè)工作隊(duì)列中。 本期文章來自才云科技（Caicloud）CEO 張鑫的技術(shù)原創(chuàng)。導(dǎo)言：Kubernetes 是一個(gè)龐大的軟件系統(tǒng)，欲從源碼層精通 Kubernetes 的進(jìn)階學(xué)習(xí)者往往會(huì)經(jīng)歷 Kubernetes：從入門到放棄 的挫敗...
摘要：負(fù)載均衡器又分為四層和七層負(fù)載均衡器，顧名思義，四層的工作在協(xié)議棧上，通過修改請求報(bào)文的源目的地址和源目的端口來轉(zhuǎn)發(fā)，比如，一個(gè)主機(jī)對應(yīng)一個(gè)域名，適用于每秒超過一萬的業(yè)務(wù)。每一次變更都是一次發(fā)布，每一次發(fā)布都是一個(gè)獨(dú)立的鏡像啟動(dòng) showImg(https://segmentfault.com/img/bVbvtgW?w=1080&h=720); 以一個(gè)經(jīng)典問題拋磚引玉，當(dāng)用戶在瀏覽器...
閱讀 1459·2023-01-11 13:20
閱讀 1815·2023-01-11 13:20
閱讀 1267·2023-01-11 13:20
閱讀 2007·2023-01-11 13:20
閱讀 4227·2023-01-11 13:20
閱讀 2886·2023-01-11 13:20
閱讀 1489·2023-01-11 13:20
閱讀 3814·2023-01-11 13:20
