關於作者：
江健，薄冰科技創始人，甲骨文ACE，11G OCM，擁有多年甲骨文設計、管理和實施經驗，精通資料庫優化、甲骨文CBO和並行性。 Eagle Eye 監控核心設計和開發人員，是一名高階 python Web 開發人員。
背景
最近我訪問客戶網站時，客戶報告說資料庫幾天前遇到了乙個“bug”，希望我們能幫忙排查。
客戶反饋現象如下：有乙個非常核心的系統資料庫，突然有一天用xxx schema登入後，正在執行的SQL處於並行狀態，DOP非常高，在多次故障定位失敗的情況下，只能暫時使用並行max servers引數將併發降低到32，以緩解過度併發的壓力。
故障確認
我們來看看前幾天資料庫的情況，失敗期確實很高。
切換到單個SQL操作**的情況，DOP非常高，然後被節流，這與客戶描述一致。
我開啟旁邊的監測報告，DOP被大幅降級。
初始並行度為192，邏輯CPU為96，與自動並行時資料庫的預設併發度非常相似。
初步調查
在客戶的帶領下，確認故障期與客戶描述基本一致。 僅聽描述，似乎有乙個觸發器用於在會話級別調整併發性或與資源管理器相關的東西。
但是，這是客戶的核心生產系統，理論上應該不可能進行猜想的調整。 通過快速調查，證實了該猜想不正確。
二次檢查
經過初步調查，我不禁懷疑客戶的描述是否有問題。 頂層活動按使用者過濾，突然發現使用者級別沒有並行性，很多執行在xxx使用者下的SQL都沒有並行性，其實只有乙個併發度高的SQL。 這也說明，最初的調查方向已經偏離。
此SQL文字未並行指定提示，結合觀察到的資訊，有點懷疑，想找應用確認最近有沒有變化。 甲方的另一位DBA斬釘截鐵地說，一定沒有改過，不僅沒改過，還懷疑是Oracle的bug。
當他說這可能是乙個錯誤時，我想申請在機器上做跟蹤的許可，但在我說之前，我問他為什麼懷疑這是乙個錯誤。 他說了一句話，讓我下定決心要寫一篇文章來記錄這個案例：“因為之前的SQL執行異常，他會用SQL Profile來修復SQL執行計畫，但經過這次修復，完全沒有效果。
震驚的罪魁禍首
實際上有乙個sqlprofile？ 令我驚訝的是，為什麼我忽略了 SQLprofile SQL 基線疑難解答。
主要原因是他們之前已經優化過自己的系統，他們知道他們很難對核心進行更改，並且經常需要詳細演示新增索引的好處，以及可能的危害，首先在測試中，準生產環境來驗證邏輯讀取的縮減率， 然後演示哪些 SQL 受到影響，並描述對 Redo 的影響。
拿著這些材料再去開發團隊（嗯，外資企業），預約開會，多得到n封郵件確認，然後安排生產（每週只有一天可以生產在清晨），第二天生產完畢，需要在工廠觀察，確保生產倉庫的安全。
根據我對他們流程的了解，我幾乎可以原諒自己對 sqlprofile 的疏忽。 看了一下SQL對應的執行計畫，就有乙個sqlprofile，它以sys開頭，一般不在addm sql tune中。
確認了這一點，問題基本定位了，馬上驗證，果然這個系統的SQLprofile讓SQL使用高並行度，並且讓客戶的DBA新生成的SQLprofile沒有生效，結合審計等資訊，後來也確認確實是甲方的另乙個DBA在晚上執行了ADDM報告，並且看到報告給出的建議的好處，非常誘人，於是很快就採納了這個建議，並請了幾天假。
回顧和反思
這個案例在技巧上並不強，有很多值得深思的地方，但我感受最深的是，在系統資料庫的運維中，對運維人員運維行為的監督嚴重不足。 然而，正是這種高權重、無監督的運維，經常帶來故障，而且是相對難以排除的，至少經常是甲方DBA難以定位的故障。
在歷史文章中有很多這樣的情況，比如偷偷收集系統統計資訊、省略新增磁碟命令、不重啟就修改引數、重啟後失敗等。 彌補這種失誤的辦法，就是成為規矩，加入巡查，那麼有沒有好的做法來預測敵人的機會，防止它發生呢？ 有成熟實踐或對這類問題有顧慮的朋友，歡迎在評論區交流。