某客户于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的时候，怎么去刷新共享池，保证对象的状态与主库端一致，是个比较麻烦的问题。 另外， 客户应用运维也存在较大的问题。事后得知，在客户方这个应用现在没什么人用，所以即使应用端出错，没有数据也没有人关心此事。直到最终数据库出现了问题，才发现应用出错。
