ITPub博客

首页 > 数据库 > Oracle > Ora-04023与数据库软件磁盘空间

Ora-04023与数据库软件磁盘空间

原创 Oracle 作者:abstractcyj 时间:2020-03-25 13:55:11 0 删除 编辑

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

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

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/8520577/viewspace-2682433/,如需转载,请注明出处,否则将追究法律责任。

全部评论
曾从事java方向开发多年。近年已经转入数据库方向。主要擅长SQL优化,Oracle数据库问题诊断,Oracle备份与恢复等。服务于医药物流,医院等行业

注册时间:2010-01-26

  • 博文量
    568
  • 访问量
    879022