為了及時共享行業案例，通知共性問題，達成共享和提前預防，我們整理和編輯了《雲和恩墨技術通訊》，通過對過去一段時間的知識回顧，故障歸納，以期提供有價值的資訊供大家參考。同時，我們也希望能夠将熱點事件、新的産品特性及其他有價值的資訊聚集起來，為您提供具有前瞻性的支援資訊，保持對于目前最新的資料庫新聞和事件的了解，其中包括重要資料庫産品釋出、警報、更新、新版本、更新檔等。
墨天輪文檔：《雲和恩墨技術通訊（6月刊）》：https://www.modb.pro/doc/4551（複制到浏覽器中打開或者點選文末左下角“閱讀原文”立即下載下傳）
以下截取部分頁面：
以下列出其中一個頻發問題。
頻發：不規範SQL引發大量TX鎖——易金東
在資料庫日常運維中，由于開發人員的一個不規範操作，很有可能會對生産業務造成不可估量的損失，下面是一個由于SQL寫法不規範引發大量TX鎖的案例：
問題描述
某客戶資料庫5月14日上午8點半突發大範圍業務堵塞，大量程序等待TX鎖。
問題分析
第一步找到HOLDER：
HOLDER程序總是空閑狀态，殺掉以後後面的SESSION也會進入空閑HOLDER。堵塞不會減少。是以我們當時分析應該是由于業務部主動送出引發的問題，但随後征得業務人員同意殺掉所有鎖相關程序後全部會話依然會進入等待新的EVENT 為：“transaction”。
第二步分析資料庫事務
經過分析：發現了當時有大事務復原，根據分析復原段查詢到了相關的表為，owner.tab_info這是業務的核心表， 根據這張表反查ASH資訊，我們發現了一條SQL執行了14小時, 這個SQL語句引發的大事務復原。SQL文本如下：
updateowner.tab_info set col1='018',COL2=10,COL3=null where col4 in (select col4 fromowner.tab_init)
第三步分析問題原因
首先IN字句裡的文法有問題，（select col4 from owner.tab_init）根本無法執行，因為這張表上根本沒有col4列。是以單獨執行直接報錯了，而且表owner.tab_init也是一個很簡單的小表，業務人員的原意也是隻修複個别錯誤的資料。ORACLE資料庫在子查詢還是會優先找子查詢中表自身的列，如果找不到相關列就會自動引用父查詢的列。那麼這條語句的語義就變了，原本的SQL等效于
update owner.tab_info set col1='018',COL2=10,COL3=nullwhere col4 in (select col4 from dual)
或者
update owner.tab_info set col1='018',COL2=10,COL3=nullwhere col4 =col4
業務人員原本是想做個别條的維護，沒想到做成了全表更新，導緻了一個天大的事務復原引發了這個故障。
問題解決
1、業務運維人員停止相關業務更新資料。
2、建立一張新表，COPY老表的所有資料，并按照原表建立索引。
3、導出并導入原表的統計資訊。
4、切換表名，RENAME。
5、通知業務重新開機業務進行觀察。
我們合理使用了并行、統計資訊導出導入、導出建表、建索引語句等技術半小時内完成了這個20G表，數千萬條記錄的表的切換，恢複業務後一切正常。
回過頭來想想一身冷汗，如果這個表沒那麼大，這個語句就執行成功了，可能會導緻整個系統資料被全部該亂，造成資料紊亂的損失。是以開發階段編寫SQL時一定要通過别名指定列名，明确每一列的具體出處，才能防範這種問題再次發生。另外，在系統方面，我們也設想能通過實作代理+阻斷的方式由系統阻斷這類SQL，禁止往生産分發。
墨天輪原文連結：https://www.modb.pro/doc/4551
推薦閱讀：144頁！分享珍藏已久的資料庫技術年刊
資料和雲
ID：OraNews
如有收獲，請劃至底部，點選“在看”，謝謝！
點選下圖檢視更多 ↓
雲和恩墨大講堂 | 一個分享交流的地方
長按，識别二維碼，加入萬人交流社群
請備注：雲和恩墨大講堂
點個“在看”
你的喜歡會被看到❤