?以前和一個朋友討論通過異常檢測的方法去分析某個故障的產生原因，我們是通過知識圖譜找到與這個故障現象有關的指標，經過對這些指標做異常檢測發現其中存在的問題，然后再根據這些問題進行歸類分析，找出問題的主因和次因。他覺得既然異常檢測算法與問題歸類算法都已經比較完備，還通過知識圖譜去收集指標集干嘛，干脆用全量指標集去計算好了，雖然算力要求比較高，不過大部分企業還花得起這個算力的。

實際上算力并不是主要問題，主要的問題是我們的系統往往是處于亞健康狀態的，平時系統中就有這個那個的問題，有一些性能瓶頸。這些問題是常態化存在的，很可能和發生的故障無關，如果拿全量指標去做分析，那么診斷結論里就會摻雜一些和這個故障無關的因素在里面。

做優化工作也是如此，很多朋友在做Oracle數據庫優化的時候，會抓取AWR報告，然后根據TOP EVENT從上到下分析一遍，把存在的問題解決掉。實際上有時候這種做法會適得其反。

從 TOP EVENT，你的第一反應是什么呢？肯定絕大多數DBA會認為共享池出問題了，CURSOR爭用很嚴重。

如果我們來看LOAD PROFILE會發現什么呢？每秒執行量很小，只有幾百，每秒解析的數量也只有幾百。我們再來看看命中率指標。

LIBRARY HIT 指標只有89%，有些朋友就會說，SQL解析出問題了。實際上當時參與這個項目的有位專家也提出了這個問題，建議開啟CURSOR_SHARING，降低硬解析的比例。實際上我們不能僅僅看幾個指標就下結論。首先這個系統中NO-PARSE CPU的比例很高，說明解析對系統的影響并不大。哪怕解決了SQL解析的問題，對系統整體性能的提升是幫助不大的。而對于ERP系統這樣十分復雜的，大多數是人操作的系統，SQL的并發執行量是有限的。在這個系統業務高峰期比較正常的時候，每秒執行數的一小時平均值也只有5000多。使用CURSOR_SHARING或者全面使用綁定變量并不一定是一件好事，這會增加執行計劃錯誤的機會，從而引發更為嚴重的性能問題。

為什么這個系統會出現如此嚴重的CURSOR問題呢，我們先來看一下OS的情況，LOAD居然高達2814，對于一個128核256線程的服務器來說，這個值相當地高。

在CPU上%SYS的比重極高，這是因為嚴重的閂鎖和MUTEX沖突引起的。實際上我們只要找出引起這些等待的SQL語句就可以了。通過V$SESSION我們很容易可以找出這些SQLID。并且根據我的猜測，肯定這些SQL是相同或者類似的。

在這個系統中，經過分析我們發現，是幾條創建全局臨時表的DDL引發了CURSOR的爭用。這其實應該是應用的一個BUG導致的，而并不是因為SQL 硬解析過大引發的問題。如果我們判斷錯了問題，采取了錯誤的優化手段，可能會引發更大的危機。

對于剛剛參加優化工作的DBA來說，我今天說的這個問題是個常見問題，沒有抓住重點，從主要矛盾入手去解決問題，那么很可能在小河溝里翻船。我最近參與的這個項目，經過幾天的救火，昨天終于出現了好轉的跡象。雖然用戶使用起來還不爽，不過系統基本上可用，不會出現長時間無響應的情況了。消除掉了前面的瓶頸，系統中讓應用變慢的最核心的問題也逐漸露出來了。

從昨天的監控數據看，r隊列得到了有效的控制，活躍會話數也從2000+下降到了一個比較合理的范圍，CPU也出現了空閑。不過RAC集群流量從前兩天的4-50MB提高到了100M左右，單個節點的每秒REDO量也達到了新高，兩個節點都超過了30MB/秒。不過目前這些問題還都在可控范圍內，本階段工作的成效已經看得很清楚了。下一階段的優化工作才是真正解決用戶感覺系統太慢的主要原因。這種情況下，問題的主要原因分散了，優化工作的覆蓋面就更大了，因此工作也需要做得更為細致了。?