建站
咨詢
售后
建站咨詢
新聞中心
?以前和一個(gè)朋友討論通過異常檢測(cè)的方法去分析某個(gè)故障的產(chǎn)生原因，我們是通過知識(shí)圖譜找到與這個(gè)故障現(xiàn)象有關(guān)的指標(biāo)，經(jīng)過對(duì)這些指標(biāo)做異常檢測(cè)發(fā)現(xiàn)其中存在的問題，然后再根據(jù)這些問題進(jìn)行歸類分析，找出問題的主因和次因。他覺得既然異常檢測(cè)算法與問題歸類算法都已經(jīng)比較完備，還通過知識(shí)圖譜去收集指標(biāo)集干嘛，干脆用全量指標(biāo)集去計(jì)算好了，雖然算力要求比較高，不過大部分企業(yè)還花得起這個(gè)算力的。
實(shí)際上算力并不是主要問題，主要的問題是我們的系統(tǒng)往往是處于亞健康狀態(tài)的，平時(shí)系統(tǒng)中就有這個(gè)那個(gè)的問題，有一些性能瓶頸。這些問題是常態(tài)化存在的，很可能和發(fā)生的故障無關(guān)，如果拿全量指標(biāo)去做分析，那么診斷結(jié)論里就會(huì)摻雜一些和這個(gè)故障無關(guān)的因素在里面。
做優(yōu)化工作也是如此，很多朋友在做Oracle數(shù)據(jù)庫優(yōu)化的時(shí)候，會(huì)抓取AWR報(bào)告，然后根據(jù)TOP EVENT從上到下分析一遍，把存在的問題解決掉。實(shí)際上有時(shí)候這種做法會(huì)適得其反。
從 TOP EVENT，你的第一反應(yīng)是什么呢？肯定絕大多數(shù)DBA會(huì)認(rèn)為共享池出問題了，CURSOR爭(zhēng)用很嚴(yán)重。
如果我們來看LOAD PROFILE會(huì)發(fā)現(xiàn)什么呢？每秒執(zhí)行量很小，只有幾百，每秒解析的數(shù)量也只有幾百。我們?cè)賮砜纯疵新手笜?biāo)。
LIBRARY HIT 指標(biāo)只有89%，有些朋友就會(huì)說，SQL解析出問題了。實(shí)際上當(dāng)時(shí)參與這個(gè)項(xiàng)目的有位專家也提出了這個(gè)問題，建議開啟CURSOR_SHARING，降低硬解析的比例。實(shí)際上我們不能僅僅看幾個(gè)指標(biāo)就下結(jié)論。首先這個(gè)系統(tǒng)中NO-PARSE CPU的比例很高，說明解析對(duì)系統(tǒng)的影響并不大。哪怕解決了SQL解析的問題，對(duì)系統(tǒng)整體性能的提升是幫助不大的。而對(duì)于ERP系統(tǒng)這樣十分復(fù)雜的，大多數(shù)是人操作的系統(tǒng)，SQL的并發(fā)執(zhí)行量是有限的。在這個(gè)系統(tǒng)業(yè)務(wù)高峰期比較正常的時(shí)候，每秒執(zhí)行數(shù)的一小時(shí)平均值也只有5000多。使用CURSOR_SHARING或者全面使用綁定變量并不一定是一件好事，這會(huì)增加執(zhí)行計(jì)劃錯(cuò)誤的機(jī)會(huì)，從而引發(fā)更為嚴(yán)重的性能問題。
為什么這個(gè)系統(tǒng)會(huì)出現(xiàn)如此嚴(yán)重的CURSOR問題呢，我們先來看一下OS的情況，LOAD居然高達(dá)2814，對(duì)于一個(gè)128核256線程的服務(wù)器來說，這個(gè)值相當(dāng)?shù)馗摺?/p>
在CPU上%SYS的比重極高，這是因?yàn)閲?yán)重的閂鎖和MUTEX沖突引起的。實(shí)際上我們只要找出引起這些等待的SQL語句就可以了。通過V$SESSION我們很容易可以找出這些SQLID。并且根據(jù)我的猜測(cè)，肯定這些SQL是相同或者類似的。
在這個(gè)系統(tǒng)中，經(jīng)過分析我們發(fā)現(xiàn)，是幾條創(chuàng)建全局臨時(shí)表的DDL引發(fā)了CURSOR的爭(zhēng)用。這其實(shí)應(yīng)該是應(yīng)用的一個(gè)BUG導(dǎo)致的，而并不是因?yàn)镾QL 硬解析過大引發(fā)的問題。如果我們判斷錯(cuò)了問題，采取了錯(cuò)誤的優(yōu)化手段，可能會(huì)引發(fā)更大的危機(jī)。
對(duì)于剛剛參加優(yōu)化工作的DBA來說，我今天說的這個(gè)問題是個(gè)常見問題，沒有抓住重點(diǎn)，從主要矛盾入手去解決問題，那么很可能在小河溝里翻船。我最近參與的這個(gè)項(xiàng)目，經(jīng)過幾天的救火，昨天終于出現(xiàn)了好轉(zhuǎn)的跡象。雖然用戶使用起來還不爽，不過系統(tǒng)基本上可用，不會(huì)出現(xiàn)長(zhǎng)時(shí)間無響應(yīng)的情況了。消除掉了前面的瓶頸，系統(tǒng)中讓應(yīng)用變慢的最核心的問題也逐漸露出來了。
從昨天的監(jiān)控?cái)?shù)據(jù)看，r隊(duì)列得到了有效的控制，活躍會(huì)話數(shù)也從2000+下降到了一個(gè)比較合理的范圍，CPU也出現(xiàn)了空閑。不過RAC集群流量從前兩天的4-50MB提高到了100M左右，單個(gè)節(jié)點(diǎn)的每秒REDO量也達(dá)到了新高，兩個(gè)節(jié)點(diǎn)都超過了30MB/秒。不過目前這些問題還都在可控范圍內(nèi)，本階段工作的成效已經(jīng)看得很清楚了。下一階段的優(yōu)化工作才是真正解決用戶感覺系統(tǒng)太慢的主要原因。這種情況下，問題的主要原因分散了，優(yōu)化工作的覆蓋面就更大了，因此工作也需要做得更為細(xì)致了。?
分享標(biāo)題：我們一起優(yōu)化工作中如何抓住主要矛盾
本文路徑：http://www.dlmjj.cn/article/dpooeop.html
