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

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

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

從 TOP EVENT，你的第一反應(yīng)是什么呢？肯定絕大多數(shù)DBA會認(rèn)為共享池出問題了，CURSOR爭用很嚴(yán)重。

如果我們來看LOAD PROFILE會發(fā)現(xiàn)什么呢？每秒執(zhí)行量很小，只有幾百，每秒解析的數(shù)量也只有幾百。我們再來看看命中率指標(biāo)。

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

為什么這個系統(tǒng)會出現(xiàn)如此嚴(yán)重的CURSOR問題呢，我們先來看一下OS的情況，LOAD居然高達(dá)2814，對于一個128核256線程的服務(wù)器來說，這個值相當(dāng)?shù)馗摺?/p>

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

在這個系統(tǒng)中，經(jīng)過分析我們發(fā)現(xiàn)，是幾條創(chuàng)建全局臨時表的DDL引發(fā)了CURSOR的爭用。這其實應(yīng)該是應(yīng)用的一個BUG導(dǎo)致的，而并不是因為SQL 硬解析過大引發(fā)的問題。如果我們判斷錯了問題，采取了錯誤的優(yōu)化手段，可能會引發(fā)更大的危機(jī)。

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

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