awr
引發的血案
昨天一早到公司，例行巡檢資料庫伺服器，crs正常，例項正常，asm正常，各項服務正常，後台程序正常，rman備份正常，做了乙個awr報告，矮油，不對，怎麼snap_id只顯示到5點就沒再有了呢，算了，先不管他，忙東忙西的也沒在意。
下午快下班的時候，測試部要測試資料庫壓力情況，希望抓乙個15點到18點的報告，ok，easy，看熊熊來搞定，到了資料庫裡執行命令
一路走下去，唉，不對，為啥還是只有5點之前的snap_id，這時候冷汗已經下來了。
執行awr的執行週期看了一下，沒問題啊，使用的是預設配置的，每小時抓取一次，保留七天資料，沒錯啊，那是為啥呢？ 詭異了。
為了搞定，手工生成了一下快照試了一下，卡住了，一直半個多小時都沒反應（其實這時候熊熊應該找到問題所在了，但是由於著急回家就忽略了）
到家以後，從遠端連線到資料，查詢了一下最大的snap_id，發現一直處在凌晨5點那個snap_id就沒更改過
又做了一次報告，按最長7天收集，發現只有100條snap_id，不算多啊，可是為什麼呢？
想執行刪除命令刪除一些快照，卻發現卡住不動了，我靠，xxd，不會讓我刪都刪不了吧。
執行了一下後台程序檢視，mmon和mmnl程序都正常使用ing啊，沒有問題啊，見鬼了。
這時候忽然想到了，是不是空間不夠了，使用命令檢視了一下，確實，sysaux表空間使用率達到了92%左右，這是乙個很尷尬的值，既不到自動擴充套件的時候，也因為預留的10%政策導致無法再寫入資料（awr報告的快照資訊都寫在這個表空間裡），於是對這個表空間進行了一些簡單的收縮工作，可是還是不行，***，真奇怪了。
通過上圖命令可以查到表空間是否可以自動擴充套件。
繼續執行快照刪除命令，還是死在那裡，xx，怎麼會這樣，忽然想起，還有乙個該死的表空間忘記了，臨時表空間。
查詢臨時表空間，4個臨時表空間都滿了（當初設定的太小），我暈死，問題就在這裡了，刪除了原有的臨時表空間，並重建了新的臨時表空間，同時為一些空間較小的表空間增加了資料檔案，重啟資料庫後，該死的awr終於又正常運作了。
正常登入以後，更改了awr的收集閥值
重新查詢，時間間隔已經為2小時一次，收集依然是保留7天，至此，awr問題全部解決。
這個問題，從9點折騰到11點才解決，最終發現是表空間的問題，並且還重啟了外網的資料庫，最終我們會發現，往往問題都出現很小的地方，我們很不會留意到的地方，因此一次合理的規劃很重要，這次錯誤感謝劉穩童鞋的技術支援和強強領導的信任與支援。
一次AWR報告引發的自我反省
awr 引發的血案 昨天一早到公司，例行巡檢資料庫伺服器，crs正常，例項正常，asm正常，各項服務正常，後台程序正常，rman備份正常，做了乙個awr報告，矮油，不對，怎麼snap id只顯示到5點就沒再有了呢，算了，先不管他，忙東忙西的也沒在意。下午快下班的時候，測試部要測試資料庫壓力情況，希望...
溝通的藝術 一次技術演講的自我反省
只練不說是傻把式，只說不練是假把式，又說又練才是真把式。溝通的藝術系列，不敢托大，純屬自己心得分享。本財年32場演唱會才剛剛開頭，卻一下子落在自己的主場。幸者，有不少熟識的圈內人。不幸者，自己的演講風格和內容還不到位，在家門口丟人可丟大發了。本意遮頭蔽面，好事者卻上傳錄影到youtube。藉此點評，...
溝通的藝術 一次技術演講的自我反省
只練不說是傻把式，只說不練是假把式，又說又練才是真把式。溝通的藝術系列，不敢托大，純屬自己心得分享。本財年32場演唱會才剛剛開頭，卻一下子落在自己的主場。幸者，有不少熟識的圈內人。不幸者，自己的演講風格和內容還不到位，在家門口丟人可丟大發了。本意遮頭蔽面，好事者卻上傳錄影到youtube。藉此點評，...