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