一次WRH$_ACTIVE_SESSION_HISTORY問題處理

前幾天處理了一次Oracle高可用變成不可用的問題。問題出在這個上面WRH$_ACTIVE_SESSION_HISTORY。
環境是有一個RAC和一個單例項資料庫的背景。先是單例項資料庫在我抽查AWR的時候發現很糟糕。（我不是運維DBA，這些不歸我管，只是遇到問題來找我）有的一個SQL執行一天都執行不完。我就判定開發寫的一定有問題。
機器非常好96C 256G記憶體。然後有人找我說那個RAC的連不上了。我去連線一下，輸入使用者名稱密碼要等很久。
去檢查一下最近的AWR報告，結果發現早上4點是最後一個。而現在是12點多。已經8個小時了。
既然沒有AWR，那麼就是AWR存不下來了。看看錶空間怎麼個情況。
一看SYSAUX空間幾乎滿了，大小是64G。這個不得讓人看到這個大小有點奇怪的感覺。作業系統只能認到一個檔案32G，怎麼有64G。那麼也就是說應該是有兩個檔案。每個檔案都是32G。一看果然是這樣的。推斷以前運維的出現問題直接掩蓋了。
讓檔案自動擴充套件，到了32G再加一個，再自動擴充套件。為什麼出現異常不管。這就留下來隱患。如果還是繼續原來的思路，再加一個，然後讓他自動到32.那麼就越來越大，不好解決。
在看一下session 和process兩個檢視。都是將近4000的。在看看資料庫中這兩個引數一個是4000一個是6000多。也就是說運維之前應該是看到了他們增大，但是沒覺得異常，既然連線數不夠就加。至於這些問題都不去解決。好像覺得這些不是他們事情。
可以想象如果現在連線數不夠了，繼續擴大引數，那麼這個也會越來越大。後面就控制不住了。
查了一下SYSAUX空間最大的表是WRH$_ACTIVE_SESSION_HISTORY大概7000多萬條資料。這個表顧名思義是活動會話歷史表。所以這個和開發的問題是有關係的。
估算了一下，truncate一下可以回收26G空間。這個過程大概花了20分鐘。越大越難做，時間越長。這就是平時不注意問題的後果。
當然再做這個之前查查這個哪天開始是大的，查下來上週五開始，每秒都是3500條。
徹底根治辦法是開發改，但是眼前先只能truncate這個WRH$_ACTIVE_SESSION_HISTORY釋放空間。然後建立個概要檔案給單例項使用者，限制連線到RAC的連線。因為這個主要是單例項連線到RAC造成的。而這個單例項其實是dblink過來的。這本來沒有問題。單例項建立物化檢視。但是開發就是不訪問本地已經有的物化檢視就是要遠端連線到RAC上來。
最初分開目的是為了讓單例項的機器不對RAC重啟，結果還是這樣。其實如果做得好的情況下，放在一起也沒有問題。業務不大。做不到的情況下，分開也沒有用。就實際的開發現狀而言，看看單例項上滿負荷在執行就知道開發的水平和能力了。
這些機器每天處理30-50萬筆交易不是問題，但是現在估算3000都處理不了。