資訊專欄INFORMATION COLUMN
在我們?nèi)粘＿\維過程中，經(jīng)常會遇到兩種類型的運維人員，一種是證明自己負責(zé)的業(yè)務(wù)組件框架沒問題后就事不關(guān)己，高高掛起；另一種是，即便不是自己本職范圍內(nèi)的業(yè)務(wù)組件框架，或者自己負責(zé)的框架不是性能故障的根因，但只要能以自己的能力知識去幫助解決問題，就以一種不到黃河心不死的精神，全力協(xié)助上游或下游進行問題查找，直到業(yè)務(wù)恢復(fù)。其實，自己一畝三分地維護地再好，業(yè)務(wù)就是無法使用，站在全局的角度，有價值嗎？所以，本著業(yè)務(wù)可用性，業(yè)務(wù)連續(xù)性的運維才是運維人該有的思想覺悟，也是運維人的最終價值之一。下面的案例介紹了如何基于數(shù)據(jù)庫，以抽絲剝繭鉆牛角尖精神，最終幫助業(yè)務(wù)側(cè)定位到了業(yè)務(wù)中斷問題的根因（業(yè)務(wù)邏輯問題）。
背 景
現(xiàn)場反饋某一項業(yè)務(wù)在大版本上線之后無法辦理。開發(fā)人員首先懷疑是程序中的某條SQL執(zhí)行較慢導(dǎo)致業(yè)務(wù)辦理超時，于是先配合開發(fā)人員在數(shù)據(jù)庫中抓取高耗SQL。在抓取高耗SQL的過程中，高耗SQL是沒有抓到，卻意外的抓到了一把“鎖”（如下圖），這把“鎖”只有WAITER，卻沒有發(fā)現(xiàn)HOLDER。于是就有了接下來的故事。
在配合開發(fā)人員進行業(yè)務(wù)測試抓取高耗SQL的過程中，發(fā)現(xiàn)每一次該業(yè)務(wù)發(fā)起的時候，數(shù)據(jù)庫中總會出現(xiàn)一條enq:TX - row lockcontention的等待事件。但奇怪的是這個TX鎖中只有WAITER,并沒有持有鎖的HOLDER，于是將該等待事件中的SQL語句（如下圖）發(fā)給開發(fā)側(cè)確認。
開發(fā)側(cè)也從程序錯誤日志中找到了該條SQL，由此可以初步判斷導(dǎo)致業(yè)務(wù)處理無法閉環(huán)的原因應(yīng)該是在執(zhí)行該UPDATE語句時出現(xiàn)TX鎖堵塞導(dǎo)致。但是究竟是誰持有了鎖，導(dǎo)致UPDATE語句執(zhí)行不下去呢？首先按照開發(fā)人員抓取的剛剛辦理業(yè)務(wù)時傳入的綁定變量手動執(zhí)行了該UPDATE語句，看是否會有TX鎖出現(xiàn)。結(jié)果如下圖：
可以看到手動執(zhí)行該UPDATE語句可以執(zhí)行成功，沒有出現(xiàn)TX鎖。進一步排查該表是否有唯一約束，如果有唯一約束，程序在同一個事務(wù)里更新了兩次同一記錄也會產(chǎn)生TX鎖，于是查看了該表上的索引（如下圖）
可以發(fā)現(xiàn)該表的主鍵列在UPDATE語句中并沒有修改，可以排除這一可能。那會不會是該表上存在TRIGGER，在更新的時候會觸發(fā)某一條件導(dǎo)致出現(xiàn)TX鎖呢？
查詢該表的依賴對象發(fā)現(xiàn)只有FUNCTION和PROCEDURE,并沒有TRIGGER,以上常見導(dǎo)致TX原因均被推翻，尋找HOLDER陷入了僵局。
尋找HOLDER陷入僵局，但問題還得接著排查，為了能更多的發(fā)現(xiàn)相關(guān)線索，請求開發(fā)側(cè)多做幾單業(yè)務(wù)，以便于測試過程的跟蹤。平臺這邊也從之前的以表為中心來尋找問題轉(zhuǎn)為以跟蹤數(shù)據(jù)庫對應(yīng)的業(yè)務(wù)SESSION信息來定位問題，看看能否從SESSION中獲取到更有價值的線索信息。
開發(fā)在做第一單測試業(yè)務(wù)時，我們將WAITER的相關(guān)SESSION做了PROCESSDUMP,然而從DUMP下來的TRACE文件中并沒有發(fā)現(xiàn)有異常。于是又讓開發(fā)做了第二單測試單據(jù)，第二單元測試的過程中，查詢數(shù)據(jù)庫相關(guān)視圖發(fā)現(xiàn)被鎖的表上同時有三個SESSION在訪問，這引起了我們的注意。
WAITER明明是一個SESSION，為什么會有3個SESSION在訪問呢，我們接著查看了這3個SESSION的信息（如下圖）
除了WAITER的SESSION之外，另外兩個會話均為INACTIVE狀態(tài)，說明SQL已經(jīng)執(zhí)行完成。而其中為mainsrv程序發(fā)起的會話，主機名剛好和WAITERSESSION的主機名相同，這不免讓人產(chǎn)生懷疑，這兩個會話之間是否具有某種聯(lián)系？
帶著疑問，我們讓開發(fā)人員繼續(xù)做了2單業(yè)務(wù)進行測試，結(jié)果與我們推測一致。每次在業(yè)務(wù)發(fā)起的時候，被鎖的表上均會有2個相同主機發(fā)起的兩個不同程序的SESSION（如下圖）
其中mainsrv程序的SESSION每次狀態(tài)均為INACTIVE，而ordsrv程序的SESSION（即WAITERSESSION）每次狀態(tài)均為ACTIVE。由此可以初步推斷可能是由于mainsrv程序執(zhí)行了某一SQL后可能導(dǎo)致之后的ordsrv程序執(zhí)行的UPDATE語句堵塞。于是緊接著我們對mainsrv和ordsrv的SESSION做了PROCESSDUMP。此時，莫名有些興奮，感覺HOLDER似乎離我們越來越近了，真相也離我們越來越近了。
在對mainsrv和ordsrv的SESSION做了PROCESSDUMP后，馬上對兩個TRACE文件進行了分析排查。果然在mainsrv程序的TRACE文件中發(fā)現(xiàn)了與ordsrv程序TRACE文件中幾乎相同的SQL，原來mainsrv程序和ordsrv程序更新了相同的表，如圖（上圖為mainsrv程序的SQL，下圖為ordsrv程序的SQL）
由此基本可以斷定導(dǎo)致該業(yè)務(wù)辦理超時的原因是:首先是mainsrv程序執(zhí)行了UPDATE語句更新****_worklist表某一行數(shù)據(jù)，之后在同一個事務(wù)中跨服務(wù)調(diào)用了ordsrv程序，ordsrv程序也更新了****_worklist表同一行的數(shù)據(jù)。最終導(dǎo)致我們在數(shù)據(jù)庫中查詢到同時有2個SESSION訪問了****_worklist表，mainsrv程序的SESSION狀態(tài)為INACTIVE是mainsrv先執(zhí)行完了UPDATE語句，ordsrv程序的SESSION狀態(tài)為ACTIVE是由于被mainsrv執(zhí)行的語句所堵塞，所以一直在等待鎖的釋放，直到程序超時。
將診斷結(jié)論發(fā)于開發(fā)側(cè)核實，在開發(fā)側(cè)排查代碼后證實結(jié)論完全正確。至此，該問題根因找到，在開發(fā)側(cè)發(fā)版整改業(yè)務(wù)邏輯后，問題徹底解決。本次分享到此結(jié)束，我們下次再見。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/130219.html
摘要：基于云遷移的三個階段細分為八個主要步驟，評估階段主要包括項目啟動現(xiàn)狀梳理以及應(yīng)用系統(tǒng)關(guān)聯(lián)關(guān)系分析三個步驟，設(shè)計階段包括云架構(gòu)優(yōu)化設(shè)計和云遷移方案設(shè)計，實施階段包括目標架構(gòu)遷移演練及實施和試運行三個步驟。 在云計算市場規(guī)模不斷擴大的大背景下，云遷移的需求越來越大且面臨挑戰(zhàn)。云遷移不是一個遷移軟件工具，而是一種服務(wù)。前IBM資深架構(gòu)師姜亞杰從云遷移的三個階段、四個維度到八個步驟的方法，簡述...
摘要：導(dǎo)讀為數(shù)人云系列活動專題，本文是月日北京站線下活動當(dāng)西方的遇上東方的互聯(lián)網(wǎng)中京東金融王超老師的分享。王超京東金融企業(yè)高級目前在京東金融平臺負責(zé)一個人左右的應(yīng)用運維團隊團隊，也曾負責(zé)人人網(wǎng)團隊。 導(dǎo)讀：[GO SRE！] 為數(shù)人云SRE系列活動專題，本文是3月4日北京站線下活動當(dāng)西方的SRE遇上東方的互聯(lián)網(wǎng)中京東金融王超老師的分享。 他將從SRE，Devops， PE間的關(guān)系開始，介紹企...
摘要：導(dǎo)讀為數(shù)人云系列活動專題，本文是月日北京站線下活動當(dāng)西方的遇上東方的互聯(lián)網(wǎng)中京東金融王超老師的分享。王超京東金融企業(yè)高級目前在京東金融平臺負責(zé)一個人左右的應(yīng)用運維團隊團隊，也曾負責(zé)人人網(wǎng)團隊。 導(dǎo)讀：[GO SRE！] 為數(shù)人云SRE系列活動專題，本文是3月4日北京站線下活動當(dāng)西方的SRE遇上東方的互聯(lián)網(wǎng)中京東金融王超老師的分享。 他將從SRE，Devops， PE間的關(guān)系開始，介紹企...
摘要：通過混合云方案，將前端服務(wù)部署在公有云上，利用公有云多分區(qū)和的優(yōu)勢使服務(wù)盡量靠近最終用戶，后端仍部署在總部私有云中。通過這樣的混合云跨云協(xié)同部署，可以大幅提升系統(tǒng)的服務(wù)能力和用戶體驗。近些年，隨著云計算技術(shù)的逐漸普及，越來越多的企業(yè)選擇了部署云計算方案，多數(shù)會選擇私有云、公有云，混合云也越來越多的被提及和部署，這里簡單聊聊混合云那些事兒。 什么是混合云？ 混合云不是簡單的將幾種云...
摘要：財年營收同比增長這是自財年第一季度以來，阿里云連續(xù)個季度保持超過的增長。聯(lián)手運營商鞏固資源優(yōu)勢阿里云的計算資源體量仍舊在飛快增長。財年營收同比增長121%!這是自2016財年第一季度以來，阿里云連續(xù)8個季度保持超過100%的增長。5月18日晚，阿里巴巴集團公布了2017財年(2016年4月1日-2017年3月31日)全年財報。與阿里云相關(guān)的數(shù)字是，財年營收規(guī)模達到66.63億元人民幣，同比上...
閱讀 1356·2023-01-11 13:20
閱讀 1707·2023-01-11 13:20
閱讀 1215·2023-01-11 13:20
閱讀 1906·2023-01-11 13:20
閱讀 4165·2023-01-11 13:20
閱讀 2757·2023-01-11 13:20
閱讀 1402·2023-01-11 13:20
閱讀 3671·2023-01-11 13:20
