WRH$_ACTIVE_SESSION_HISTORY問題的處理方法

這篇文章給大家介紹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都處理不了。

關于WRH$_ACTIVE_SESSION_HISTORY問題的處理方法就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。