?二十年前搞Oracle運維的時候，被折騰得最厲害的是共享池的問題，ORA-4031絕對是DBA必須面對的，也是最束手無措的錯誤。很多DBA面試官也會問大量的共享池診斷與優(yōu)化的問題，雖然他自己對很多問題的了解也不過如此。

今早的這篇文章的主體結構是昨天下班前寫出來的，今早做了一些補充就發(fā)出來了。因為昨天上午我一直在做D-SMART這個部分的優(yōu)化設計，這篇文章實際上是我這一天工作的一些總結。

Oracle 10G以后有了SGA動態(tài)分配的能力，而且服務器的內存也從MB級別進入到了VLM的級別，共享池和ORA-4031的問題也就見得少了。在D-SMART里，針對ORA-4031的監(jiān)控功能比較少，只提供了一些用于分析的工具，不過這幾年也很少能發(fā)揮作用。

最近一個客戶的數據庫因為遇到BUG導致了一個實例出現(xiàn)ORA-4031,必須重啟才能解決問題。用戶提出了針對ORA-4031問題能否加強監(jiān)控與分析。我這幾天也一直在考慮這個問題。Oracle數據庫中最脆弱和最復雜的組件就是SHARED POOL，對SHARED POOL的監(jiān)控一定要特別小心。十多年前給用戶做Oracle服務的時候也經常遇到采集SHARED POOL的數據的時候把數據庫實例HANG死的問題。我甚至養(yǎng)成了采集共享池數據的時候一定另外開好另外一個窗口，一旦有問題立馬殺掉采集的會話。

可能很多朋友開發(fā)的Oracle監(jiān)控工具里都有共享池監(jiān)控的功能，他們也覺得監(jiān)控共享池的手段是很豐富的，為什么我們會把這件事搞得這么復雜呢？

在D-SMART的共享池數據采集方面，我也是十分謹慎的，不希望因為監(jiān)控工具設計的不慎而導致原本負載過高的數據庫實例被監(jiān)控腳本搞垮。在V2.2版本的D-SMART中，和SHARED POOL相關的指標都是通過比較穩(wěn)妥的系統(tǒng)視圖采集的。如今要加強共享池數據的采集，首先想到的就是v$sgastat，因為Oracle的AWR也會采集這個視圖里的數據。

為了確認訪問的視圖的風險，我們需要找出視圖訪問的基礎數據結構，如果需要大量掃描共享池，那么就應該盡可能避免。通過下面的腳本可以查找相關信息。

SELECT view_definition FROM v$fixed_view_definition        WHERE view_name='GV$SGASTAT';

可以看出，GV$SGASTAT的基礎視圖是x$ksmfs ,x$ksmss ,x$ksmls ,x$ksmjs ,x$ksmns, x$ksmstrs，這些基礎數據結構都是匯總KGH的數據的，本身不需要遍歷KGH，因此風險都不大。

比如ksmss存儲了共享對象的一些屬性，雖然不會在訪問該對象時持有shared pool的閂鎖，不過訪問過程中也會對共享池內的對象的變更產生影響。因此雖然我們可以比較安全的采集數據，不過也不適合過于頻繁。這樣的指標的采集，每個小時一次就可以了。

column indx heading "indx|indx num" 

column kghlurcr heading "RECURRENT|CHUNKS"

column kghlutrn heading "TRANSIENT|CHUNKS"

column kghlufsh heading "FLUSHED|CHUNKS"

column kghluops heading "PINS AND|RELEASES"

column kghlunfu heading "ORA-4031|ERRORS"

column kghlunfs heading "LAST ERROR|SIZE"

select   indx,  kghlurcr,  kghlutrn,  kghlufsh,  kghluops,  kghlunfu,  kghlunfs from  sys.x$kghlu where   inst_id = userenv('Instance')

對于監(jiān)控共享池的情況來說，kghlu數據結構更為有效，可以十分詳細地查看到共享池中的每個子池的統(tǒng)計信息。

特別是kghlunfu/ kghlunfs這兩個字段，顯示了每個子池出現(xiàn)的ORA-4031錯誤的次數以及最后一次分配錯誤所需分配的空間的大小。一般來說如果在某個子池中分配共享池空間失敗只是一個miss，此時會從另外一個池中分配，直到所有的子池中都無法分配空間，才會真正的出現(xiàn)FAILURE。因此ERRORS數量真正指出了共享池內存無法分配空間的情況。對該內存結構的監(jiān)控可以比較準確地反映出共享池碎片產生的后果。不過這個數據結構的訪問也需要通過相關閂鎖，并且這個結構的訪問頻率要比前面所提的那些結構要頻繁。因此對該數據結構的采集依然不建議過于頻繁，一個小時采集一次已經足夠了。

為什么這樣說呢？kghlu中的kghlusep指針是一個十分重要的指針，它指向了共享池LRU鏈上的一個關鍵位置，那個位置分割了共享池LRU鏈的冷熱區(qū)。當新的CHUNK要加入LRU鏈的時候，是添加在該指針左側的冷區(qū)尾部。而冷區(qū)中的CHUNK被多次訪問時會遷移到LRU鏈的熱端，以便于被重用。因此這個指針是訪問十分頻繁的，采集該結構的數據要格外謹慎。

x$kghlu經常被某些數據庫監(jiān)控軟件用來監(jiān)控共享池問題，不過頻繁的訪問這個數據結構還是會對數據庫產生影響的，特別是數據庫并發(fā)比較大，共享池存在性能問題的時候，如果過于頻繁的監(jiān)控這個數據結構，可能會產生一些相當嚴重的問題。如果知道了這一點，我想大家應該理解為什么我會對共享池的監(jiān)控數據采集如此謹慎了。

col "avg size" format a30 truncate;

col siz format 999999999999

SELECT KSMCHCLS CLASS, COUNT(KSMCHCLS) NUM, SUM(KSMCHSIZ) SIZ,To_char( ((SUM(KSMCHSIZ) /COUNT(KSMCHCLS) /1024)), '999,999.00')||'k' "AVG SIZE" FROM X$KSMSP GROUP BY KSMCHCLS;

實際上要分析shared pool的風險，上面的語句具有更好的效果，如果發(fā)現(xiàn)perm內存不斷增長，free的平均大小不斷下降，甚至低于4KB，那么說明共享池出現(xiàn)了較大的碎片化風險。而下面的語句可以作更細致的分析。

col sga_heap format a15

col size format a10

select KSMCHIDX "SubPool", 'sga heap('||KSMCHIDX||',0)'sga_heap,ksmchcom ChunkComment,decode(round(ksmchsiz/1000),0,'0-1K', 1,'1-2K', 2,'2-3K',3,'3-4K',4,'4-5K',5,'5-6k',6,'6-7k',7,'7-8k',8,'8-9k', 9,'9-10k','> 10K') "size" ,count(*),ksmchcls Status, sum(ksmchsiz) Bytes from x$ksmsp where KSMCHCOM = 'free memory' group by ksmchidx, ksmchcls,'sga heap('|| KSMCHIDX||',0)',ksmchcom, ksmchcls,decode(round(ksmchsiz/1000),0,'0-1K',1,'1-2K', 2,'2-3K', 3,'3-4K',4,'4-5K',5,'5-6k',6,'6-7k',7,'7-8k',8,'8-9k', 9,'9-10k','> 10K');

這條SQL可以采集到共享池中free內存的詳細情況，如果較大的heap比較少時，共享池的碎片化就很嚴重了。

似乎我們可以直接對x$ksmsp直接做采集，從而獲得對共享池分析的更有效的數據。不過真的如此嗎？我們如果看一下x$ksmsp的實際結構，就會明白為什么我們不想把這個采集放到自動化采集的腳本中，更好的采集共享池的信息了。

我們可以看到ksmsp實際上指向了一個kghds的鏈表，而這個鏈表實際上是指向真實的heap鏈，對x$ksmsp的統(tǒng)計實際上會遍歷heap鏈表，對于共享池很大，并且共享池并發(fā)訪問很重，特別是共享池存在性能問題的場景，這種訪問無疑會加重共享池的負擔，甚至成為壓垮駱駝的最后一根稻草。如果這種采集放到不受控的自動化采集中去，那可能會帶來不可知的影響。因此這種分析我們只是在手工點擊的工具中提供，而不會做成自動化采集的一部分。

監(jiān)控與診斷實際上也是一種運維知識，開發(fā)監(jiān)控與診斷工具，產品經理中應該有資深的運維專家，僅僅依靠高水平的研發(fā)人員是開發(fā)不出一套真正高水平的運維監(jiān)控與診斷工具的。而對于一些比較脆弱的數據庫模塊的監(jiān)控采集，也需要十分謹慎的做設計，否則監(jiān)控軟件會成為偽裝成天使的惡魔。