Oracle/ORA-4031 : 相同的的設定, 不同的結果

今天到 xx科大, user 告訴我一件事, 他們的DB (9.2.0.8) 從 Solaris 移植到 AIX , 所有的 Initialilzation parameter 都相同, 但是在 AIX 上執行時出現記憶體不足...

剛好前兩天我在另一家醫院才剛處理過相同的問題, 所以我就問他是不是 ORA-4031 , 他說對, 可是以前在 Solaris 上也是設定 shared server mode, Large pool 也是設定 384 MB 那時跑的就很正常, 現在只有 OS 移植到 AIX 上而已, Session 數也沒以前多, 反而出現這種錯誤.
我也覺得匪夷所思丫, 因為 ORA-4031 的錯誤不會出現在 alert log 中, user 又有立即解決問題的壓力, 必需重開機以調高 large pool , 所以事後很難還原當時的真相, 只能推測 Oracle 在不同 OS 平台上對記憶體的運用還是有些許的不同.

補充前面那家醫院的後續....
那家醫院的 HIS 是存在 Oracle 8i 中, 因為剛加入了電子病歷系統而導致常常出現 ORA-4031 (Share pool xx KB) 的錯誤訊息, 這個問題不難, 利用中午時間改個參數重新開啟 DB 就好了, 本來要收拾書包回家去了, 結果又傳出 ORA-4031 (Large pool)

怎麼會這樣 !  怎麼會這樣 !  怎麼會這樣 !  怎麼會這樣 !  怎麼會這樣 ! 

(搖了兩次頭, 丫, 有了) 看一下 v$session 的 server 欄位, 全部的  user session 都是 使用 shared server , 查了以前的 report , 果然以前的 user session 都是使用 dedicated server
第一個 Solution , 將 dispatcher 改為 0 , 新的 session 就會改成使用 dedicated server, 但現有的 session 還是持續的出問題.
這樣太慢了, 這時就當機下斷 (因為醫院已經在廣播要各診間改用人工作業) , 馬上再改 pfile 再重開, 狀況就解除了

所以, 有 report 是很重要滴 !!

PS. 事後回想, 這個 DB 很久以前就是因為 shared server 效能不好, 因而改成 dedicated server , 但是只改到記憶體的設定, 沒有改到 pfile ( Oralce 8i 沒有 spfile) 這次重開機時又套用回原先參數.
PS. 事後與 user 閒聊才了解到電子病歷是保護病歷不受醫生事後串竄改丫

留言

這個網誌中的熱門文章

12c RAC, OS log 出現 WARNING: couldn't allocate FBT table for module oracleacfs

11g client 連上 12c server, 出現 ora-28040

新建的 12.2.0.1 資料庫 alert 出現 ORA-12012