一次AWR報告引發的自我檢討

AWR引發的血案

昨天一早到公司，例行巡檢資料庫伺服器，CRS正常，執行個體正常，ASM正常，各項服務正常，背景程序正常，RMAN備份正常，做了一個AWR報告，矮油，不對，怎麼snap_id隻顯示到5點就沒再有了呢，算了，先不管他，忙東忙西的也沒在意。

下午快下班的時候，測試部要測試資料庫壓力情況，希望抓一個15點到18點的報告，OK，easy，看熊熊來搞定，到了資料庫裡執行指令

<a href="http://bearlovecat.blog.51cto.com/attachment/201205/11/1293914_133671690476zC.png"></a>

一路走下去，唉，不對，為啥還是隻有5點之前的snap_id，這時候冷汗已經下來了。

<a href="http://bearlovecat.blog.51cto.com/attachment/201205/11/1293914_1336716908dd4U.png"></a>

執行AWR的運作周期看了一下，沒問題啊，使用的是預設配置的，每小時抓取一次，保留七天資料，沒錯啊，那是為啥呢？ 詭異了。

<a href="http://bearlovecat.blog.51cto.com/attachment/201205/11/1293914_1336716908Sv6c.png"></a>

為了搞定，手工生成了一下快照試了一下，卡住了，一直半個多小時都沒反應（其實這時候熊熊應該找到問題所在了，但是由于着急回家就忽略了）

<a href="http://bearlovecat.blog.51cto.com/attachment/201205/11/1293914_1336716912fiV7.jpg"></a>

到家以後，從遠端連接配接到資料，查找了一下最大的snap_id，發現一直處在淩晨5點那個snap_id就沒更改過

又做了一次報告，按最長7天收集，發現隻有100條snap_id，不算多啊，可是為什麼呢？

<a href="http://bearlovecat.blog.51cto.com/attachment/201205/11/1293914_1336716913EFCD.jpg"></a>

想運作删除指令删除一些快照，卻發現卡住不動了，我靠，XXD，不會讓我删都删不了吧。

<a href="http://bearlovecat.blog.51cto.com/attachment/201205/11/1293914_1336716914RGAZ.png"></a>

執行了一下背景程序檢視，mmon和mmnl程序都正常使用ing啊，沒有問題啊，見鬼了。

<a href="http://bearlovecat.blog.51cto.com/attachment/201205/11/1293914_1336716915nW01.jpg"></a>

這時候忽然想到了，是不是空間不夠了，使用指令檢視了一下，确實，SYSAUX表空間使用率達到了92%左右，這是一個很尴尬的值，既不到自動擴充的時候，也因為預留的10%政策導緻無法再寫入資料（AWR報告的快照資訊都寫在這個表空間裡），于是對這個表空間進行了一些簡單的收縮工作，可是還是不行，TMD，真奇怪了。

<a href="http://bearlovecat.blog.51cto.com/attachment/201205/11/1293914_1336716922z6py.jpg"></a>

通過上圖指令可以查到表空間是否可以自動擴充。

繼續執行快照删除指令，還是死在那裡，XX，怎麼會這樣，忽然想起，還有一個該死的表空間忘記了，臨時表空間。

<a href="http://bearlovecat.blog.51cto.com/attachment/201205/11/1293914_1336716926W8wi.jpg"></a>

查詢臨時表空間，4個臨時表空間都滿了（當初設定的太小），我暈死，問題就在這裡了，删除了原有的臨時表空間，并重建了新的臨時表空間，同時為一些空間較小的表空間增加了資料檔案，重新開機資料庫後，該死的AWR終于又正常運作了。

<a href="http://bearlovecat.blog.51cto.com/attachment/201205/11/1293914_1336716926ilR3.jpg"></a>

正常登入以後，更改了AWR的收集閥值

<a href="http://bearlovecat.blog.51cto.com/attachment/201205/11/1293914_1336716930NG2y.jpg"></a>

重新查詢，時間間隔已經為2小時一次，收集依然是保留7天，至此，AWR問題全部解決。

這個問題，從9點折騰到11點才解決，最終發現是表空間的問題，并且還重新開機了外網的資料庫，最終我們會發現，往往問題都出現很小的地方，我們很不會留意到的地方，是以一次合理的規劃很重要，這次錯誤感謝劉穩童鞋的技術支援和強強上司的信任與支援。

本文轉自bear_cat51CTO部落格，原文連結：http://blog.51cto.com/bearlovecat/860733 ，如需轉載請自行聯系原作者