客户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 的时候，怎么去刷新共享池，保证对象的状态与主库端一致，是个比较麻烦的问题。

另外， 客户应用运维也存在较大的问题。事后得知，这个应用现在没什么人用，所以即使应用端出错，没有数据也没有人关心此事。直到最终数据库出现了问题，才最终发现了应用出错的问题。