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

今早的這篇文章的主體結(jié)構(gòu)是昨天下班前寫出來(lái)的，今早做了一些補(bǔ)充就發(fā)出來(lái)了。因?yàn)樽蛱焐衔缥乙恢痹谧鯠-SMART這個(gè)部分的優(yōu)化設(shè)計(jì)，這篇文章實(shí)際上是我這一天工作的一些總結(jié)。

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

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

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

在D-SMART的共享池?cái)?shù)據(jù)采集方面，我也是十分謹(jǐn)慎的，不希望因?yàn)楸O(jiān)控工具設(shè)計(jì)的不慎而導(dǎo)致原本負(fù)載過(guò)高的數(shù)據(jù)庫(kù)實(shí)例被監(jiān)控腳本搞垮。在V2.2版本的D-SMART中，和SHARED POOL相關(guān)的指標(biāo)都是通過(guò)比較穩(wěn)妥的系統(tǒng)視圖采集的。如今要加強(qiáng)共享池?cái)?shù)據(jù)的采集，首先想到的就是v$sgastat，因?yàn)镺racle的AWR也會(huì)采集這個(gè)視圖里的數(shù)據(jù)。

為了確認(rèn)訪問(wèn)的視圖的風(fēng)險(xiǎn)，我們需要找出視圖訪問(wèn)的基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)，如果需要大量掃描共享池，那么就應(yīng)該盡可能避免。通過(guò)下面的腳本可以查找相關(guān)信息。

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

可以看出，GV$SGASTAT的基礎(chǔ)視圖是x$ksmfs ,x$ksmss ,x$ksmls ,x$ksmjs ,x$ksmns, x$ksmstrs，這些基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)都是匯總KGH的數(shù)據(jù)的，本身不需要遍歷KGH，因此風(fēng)險(xiǎn)都不大。

比如ksmss存儲(chǔ)了共享對(duì)象的一些屬性，雖然不會(huì)在訪問(wèn)該對(duì)象時(shí)持有shared pool的閂鎖，不過(guò)訪問(wèn)過(guò)程中也會(huì)對(duì)共享池內(nèi)的對(duì)象的變更產(chǎn)生影響。因此雖然我們可以比較安全的采集數(shù)據(jù)，不過(guò)也不適合過(guò)于頻繁。這樣的指標(biāo)的采集，每個(gè)小時(shí)一次就可以了。

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')

對(duì)于監(jiān)控共享池的情況來(lái)說(shuō)，kghlu數(shù)據(jù)結(jié)構(gòu)更為有效，可以十分詳細(xì)地查看到共享池中的每個(gè)子池的統(tǒng)計(jì)信息。

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

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

x$kghlu經(jīng)常被某些數(shù)據(jù)庫(kù)監(jiān)控軟件用來(lái)監(jiān)控共享池問(wèn)題，不過(guò)頻繁的訪問(wèn)這個(gè)數(shù)據(jù)結(jié)構(gòu)還是會(huì)對(duì)數(shù)據(jù)庫(kù)產(chǎn)生影響的，特別是數(shù)據(jù)庫(kù)并發(fā)比較大，共享池存在性能問(wèn)題的時(shí)候，如果過(guò)于頻繁的監(jiān)控這個(gè)數(shù)據(jù)結(jié)構(gòu)，可能會(huì)產(chǎn)生一些相當(dāng)嚴(yán)重的問(wèn)題。如果知道了這一點(diǎn)，我想大家應(yīng)該理解為什么我會(huì)對(duì)共享池的監(jiān)控?cái)?shù)據(jù)采集如此謹(jǐ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;

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

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內(nèi)存的詳細(xì)情況，如果較大的heap比較少時(shí)，共享池的碎片化就很嚴(yán)重了。

似乎我們可以直接對(duì)x$ksmsp直接做采集，從而獲得對(duì)共享池分析的更有效的數(shù)據(jù)。不過(guò)真的如此嗎？我們?nèi)绻匆幌聏$ksmsp的實(shí)際結(jié)構(gòu)，就會(huì)明白為什么我們不想把這個(gè)采集放到自動(dòng)化采集的腳本中，更好的采集共享池的信息了。

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

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