監控與診斷實際上也是一種運維知識，開發監控與診斷工具，產品經理中應該有資深的運維專家，僅僅依靠高水平的研發人員是開發不出一套真正高水平的運維監控與診斷工具的。而對于一些比較脆弱的數據庫模塊的監控采集，也需要十分謹慎的做設計，否則監控軟件會成為偽裝成天使的惡魔。
?二十年前搞Oracle運維的時候，被折騰得最厲害的是共享池的問題，ORA-4031絕對是DBA必須面對的，也是最束手無措的錯誤。很多DBA面試官也會問大量的共享池診斷與優化的問題，雖然他自己對很多問題的了解也不過如此。
今早的這篇文章的主體結構是昨天下班前寫出來的，今早做了一些補充就發出來了。因為昨天上午我一直在做D-SMART這個部分的優化設計，這篇文章實際上是我這一天工作的一些總結。
Oracle 10G以后有了SGA動態分配的能力，而且服務器的內存也從MB級別進入到了VLM的級別，共享池和ORA-4031的問題也就見得少了。在D-SMART里，針對ORA-4031的監控功能比較少，只提供了一些用于分析的工具，不過這幾年也很少能發揮作用。
最近一個客戶的數據庫因為遇到BUG導致了一個實例出現ORA-4031,必須重啟才能解決問題。用戶提出了針對ORA-4031問題能否加強監控與分析。我這幾天也一直在考慮這個問題。Oracle數據庫中最脆弱和最復雜的組件就是SHARED POOL，對SHARED POOL的監控一定要特別小心。十多年前給用戶做Oracle服務的時候也經常遇到采集SHARED POOL的數據的時候把數據庫實例HANG死的問題。我甚至養成了采集共享池數據的時候一定另外開好另外一個窗口，一旦有問題立馬殺掉采集的會話。
可能很多朋友開發的Oracle監控工具里都有共享池監控的功能，他們也覺得監控共享池的手段是很豐富的，為什么我們會把這件事搞得這么復雜呢？
在D-SMART的共享池數據采集方面，我也是十分謹慎的，不希望因為監控工具設計的不慎而導致原本負載過高的數據庫實例被監控腳本搞垮。在V2.2版本的D-SMART中，和SHARED POOL相關的指標都是通過比較穩妥的系統視圖采集的。如今要加強共享池數據的采集，首先想到的就是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')
對于監控共享池的情況來說，kghlu數據結構更為有效，可以十分詳細地查看到共享池中的每個子池的統計信息。
特別是kghlunfu/ kghlunfs這兩個字段，顯示了每個子池出現的ORA-4031錯誤的次數以及最后一次分配錯誤所需分配的空間的大小。一般來說如果在某個子池中分配共享池空間失敗只是一個miss，此時會從另外一個池中分配，直到所有的子池中都無法分配空間，才會真正的出現FAILURE。因此ERRORS數量真正指出了共享池內存無法分配空間的情況。對該內存結構的監控可以比較準確地反映出共享池碎片產生的后果。不過這個數據結構的訪問也需要通過相關閂鎖，并且這個結構的訪問頻率要比前面所提的那些結構要頻繁。因此對該數據結構的采集依然不建議過于頻繁，一個小時采集一次已經足夠了。
為什么這樣說呢？kghlu中的kghlusep指針是一個十分重要的指針，它指向了共享池LRU鏈上的一個關鍵位置，那個位置分割了共享池LRU鏈的冷熱區。當新的CHUNK要加入LRU鏈的時候，是添加在該指針左側的冷區尾部。而冷區中的CHUNK被多次訪問時會遷移到LRU鏈的熱端，以便于被重用。因此這個指針是訪問十分頻繁的，采集該結構的數據要格外謹慎。
x$kghlu經常被某些數據庫監控軟件用來監控共享池問題，不過頻繁的訪問這個數據結構還是會對數據庫產生影響的，特別是數據庫并發比較大，共享池存在性能問題的時候，如果過于頻繁的監控這個數據結構，可能會產生一些相當嚴重的問題。如果知道了這一點，我想大家應該理解為什么我會對共享池的監控數據采集如此謹慎了。
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的風險，上面的語句具有更好的效果，如果發現perm內存不斷增長，free的平均大小不斷下降，甚至低于4KB，那么說明共享池出現了較大的碎片化風險。而下面的語句可以作更細致的分析。
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的統計實際上會遍歷heap鏈表，對于共享池很大，并且共享池并發訪問很重，特別是共享池存在性能問題的場景，這種訪問無疑會加重共享池的負擔，甚至成為壓垮駱駝的最后一根稻草。如果這種采集放到不受控的自動化采集中去，那可能會帶來不可知的影響。因此這種分析我們只是在手工點擊的工具中提供，而不會做成自動化采集的一部分。
監控與診斷實際上也是一種運維知識，開發監控與診斷工具，產品經理中應該有資深的運維專家，僅僅依靠高水平的研發人員是開發不出一套真正高水平的運維監控與診斷工具的。而對于一些比較脆弱的數據庫模塊的監控采集，也需要十分謹慎的做設計，否則監控軟件會成為偽裝成天使的惡魔。
