共計(jì) 1348 個(gè)字符，預(yù)計(jì)需要花費(fèi) 4 分鐘才能閱讀完成。

這篇文章給大家介紹 WRH$_ACTIVE_SESSION_HISTORY 問題的處理方法，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

前幾天處理了一次 Oracle 高可用變成不可用的問題。問題出在這個(gè)上面 WRH$_ACTIVE_SESSION_HISTORY。
環(huán)境是有一個(gè) RAC 和一個(gè)單實(shí)例數(shù)據(jù)庫的背景。先是單實(shí)例數(shù)據(jù)庫在我抽查 AWR 的時(shí)候發(fā)現(xiàn)很糟糕。（我不是運(yùn)維 DBA，這些不歸我管，只是遇到問題來找我）有的一個(gè) SQL 執(zhí)行一天都執(zhí)行不完。我就判定開發(fā)寫的一定有問題。
機(jī)器非常好 96C 256G 內(nèi)存。然后有人找我說那個(gè) RAC 的連不上了。我去連接一下，輸入用戶名密碼要等很久。
去檢查一下最近的 AWR 報(bào)告，結(jié)果發(fā)現(xiàn)早上 4 點(diǎn)是最后一個(gè)。而現(xiàn)在是 12 點(diǎn)多。已經(jīng) 8 個(gè)小時(shí)了。
既然沒有 AWR，那么就是 AWR 存不下來了。看看表空間怎么個(gè)情況。
一看 SYSAUX 空間幾乎滿了，大小是 64G。這個(gè)不得讓人看到這個(gè)大小有點(diǎn)奇怪的感覺。操作系統(tǒng)只能認(rèn)到一個(gè)文件 32G，怎么有 64G。那么也就是說應(yīng)該是有兩個(gè)文件。每個(gè)文件都是 32G。一看果然是這樣的。推斷以前運(yùn)維的出現(xiàn)問題直接掩蓋了。
讓文件自動擴(kuò)展，到了 32G 再加一個(gè)，再自動擴(kuò)展。為什么出現(xiàn)異常不管。這就留下來隱患。如果還是繼續(xù)原來的思路，再加一個(gè)，然后讓他自動到 32. 那么就越來越大，不好解決。
在看一下 session 和 process 兩個(gè)視圖。都是將近 4000 的。在看看數(shù)據(jù)庫中這兩個(gè)參數(shù)一個(gè)是 4000 一個(gè)是 6000 多。也就是說運(yùn)維之前應(yīng)該是看到了他們增大，但是沒覺得異常，既然連接數(shù)不夠就加。至于這些問題都不去解決。好像覺得這些不是他們事情。
可以想象如果現(xiàn)在連接數(shù)不夠了，繼續(xù)擴(kuò)大參數(shù)，那么這個(gè)也會越來越大。后面就控制不住了。
查了一下 SYSAUX 空間最大的表是 WRH$_ACTIVE_SESSION_HISTORY 大概 7000 多萬條數(shù)據(jù)。這個(gè)表顧名思義是活動會話歷史表。所以這個(gè)和開發(fā)的問題是有關(guān)系的。
估算了一下，truncate 一下可以回收 26G 空間。這個(gè)過程大概花了 20 分鐘。越大越難做，時(shí)間越長。這就是平時(shí)不注意問題的后果。
當(dāng)然再做這個(gè)之前查查這個(gè)哪天開始是大的，查下來上周五開始，每秒都是 3500 條。
徹底根治辦法是開發(fā)改，但是眼前先只能 truncate 這個(gè) WRH$_ACTIVE_SESSION_HISTORY 釋放空間。然后創(chuàng)建個(gè)概要文件給單實(shí)例用戶，限制連接到 RAC 的連接。因?yàn)檫@個(gè)主要是單實(shí)例連接到 RAC 造成的。而這個(gè)單實(shí)例其實(shí)是 dblink 過來的。這本來沒有問題。單實(shí)例建立物化視圖。但是開發(fā)就是不訪問本地已經(jīng)有的物化視圖就是要遠(yuǎn)程連接到 RAC 上來。
最初分開目的是為了讓單實(shí)例的機(jī)器不對 RAC 重啟，結(jié)果還是這樣。其實(shí)如果做得好的情況下，放在一起也沒有問題。業(yè)務(wù)不大。做不到的情況下，分開也沒有用。就實(shí)際的開發(fā)現(xiàn)狀而言，看看單實(shí)例上滿負(fù)荷在運(yùn)行就知道開發(fā)的水平和能力了。
這些機(jī)器每天處理 30-50 萬筆交易不是問題，但是現(xiàn)在估算 3000 都處理不了。

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