Ora-04023與數據庫軟件磁盤空間

客戶3 月25 日反饋一個位于HPUX 主機的Oracle 11.2.0.4 版本的備庫數據庫軟件所在的LV 空間使用率增長較快。最開始，我并沒有意識到有多大的問題。這個備庫有不少的讀取業務，客戶擔心此問題會影響到正常業務，于是到了客戶現場調查了一下。

   首先，通過統計文件夾的大小，定位到了磁盤空間占用較高的根源在于數據庫的trace 目錄。根據時間來排序了一下trace 文件, 發現有很多較大的文件，僅三天產生的trace 文件相比于正常時間段多了很多，達到了近70G 之多。很多trace 文件較大，至少都在10M 以上，多的有40 多M ，數量也較多，多達幾千個，這足以說明數據庫應該存在問題。

   抽查了幾個較大的trace 文件頭，我注意到這些trace 文件相關的會話的module 都是一個exe （客戶是個醫院，很多程序是C/S 架構）。使用select sid, serial#, machine, module, terminal from v$session where module =’***.exe’ 與select s.sid, s.serial#, s.machine, s.module, s.terminal from v$session s, v_process p where s.module =’***.exe’ and s.paddr=p.addr 分別定位到了會話來源的主機與對應的server process 進程， 再根據進程編號找到了最近的trace ， 發現trace 文件還一直在刷kksfbc: entering reparse diagnosis mode for xsc:******** 之類的信息。Trace 文件末尾還記錄了出錯的SQL 。復制出SQL 到備庫執行，果然出錯，錯誤代碼為：ORA-04023: Object could not be validated or authorized 。 主庫執行可以得到正常的結果。這樣看來，此問題最有可能是備庫的bug 。

客戶登錄到剛剛找到的應用所在的主機，在應用的日志文件中發現了大量的ORA-04023 錯誤，最早是從3 月17 日開始。根據錯誤搜索Oracle Support ，發現了一個相關的bug ：Bug 16713938 : SELECT ON VIEW FAILS WITH ORA-04023 ON ADG FROM VIEW OWNER SCHEMA 。這個bug 沒有給出patch 來修復，work around 是：alter system flush shared_pool, 刷新數據庫實例的共享池。這個問題，有可能是由于主庫端的視圖在發生了狀態變更之后, 備庫的shared pool 中的library cache, 沒有更新以反應主庫端狀態的變化所導致的。

執行alter system flush shared_pool 之后，執行SQL 不再出錯，再檢查應用的日志，也再未看到有類似的錯誤。數據庫的trace 文件大小也恢復了正常。

由這個診斷過程可以看出，Oracle 的active data guard 支持read only, 也不是一件簡單的事情。備庫在應用redo 的時候，怎么去刷新共享池，保證對象的狀態與主庫端一致，是個比較麻煩的問題。

另外， 客戶應用運維也存在較大的問題。事后得知，這個應用現在沒什么人用，所以即使應用端出錯，沒有數據也沒有人關心此事。直到最終數據庫出現了問題，才最終發現了應用出錯的問題。