alertlog中大量job报错的解决

     今天上班的时候一看，发现数据库的目录97%了，顿时觉得奇怪，都已经写了shell定期删除oracle目录下的文件，怎么会突然就这么满了呢，估计又是出问题了，果然一看alertlog全是下面这样的报错，生成了大量的trace

 

Thu Jun 16 13:54:44 2011
Errors in file /oracle/admin/zhdu/bdump/zhdu2_j000_19455.trc:
Thu Jun 16 13:56:51 2011
Errors in file /oracle/admin/zhdu/bdump/zhdu2_j000_19455.trc:
Thu Jun 16 13:58:40 2011
Trace dumping is performing id=[cdmp_20110616135840]
Thu Jun 16 14:00:50 2011
Errors in file /oracle/admin/zhdu/bdump/zhdu2_j000_19455.trc:
Thu Jun 16 14:04:54 2011
Errors in file /oracle/admin/zhdu/bdump/zhdu2_j001_27814.trc:
Thu Jun 16 14:08:54 2011
Errors in file /oracle/admin/zhdu/bdump/zhdu2_j000_29512.trc:

 

打开trace文件发现有这样的报错信息

 

*** 2011-06-04 06:00:18.414
ksedmp: internal or fatal error
Current SQL statement for this session:
DELETE FROM WFE_ACTIVITY WHERE PROCESSINSID = :B1
----- PL/SQL Call Stack -----
  object      line  object
  handle    number  name
c0000000ce7a4a60        94  procedure CCATSUPT.CP_WF_ARCHIVE_FLOWINSTANCE
c0000000bc1d74e8         1  anonymous block

 

看来是过程CCATSUPT.CP_WF_ARCHIVE_FLOWINSTANCE 的94行

 

DELETE FROM WFE_ACTIVITY WHERE PROCESSINSID = :B1

 

这条sql执行的时候抛出来的，仔细检查了这个过程发现过程本身倒没有什么问题，这下感觉非常奇怪，alertlog 里面没有 ORA错误，无从查起，花了很长时间都无法定位到问题，后来trace文件中的

 

c0000000bc1d74e8         1  anonymous block

 

引起注意，难道是block的问题，于是决定将表移动一下，由于表比较大又没有停机时间，所以使用在线重定义的方式操作，折腾了一会后重定义完成了，结果出现新的问题，alertlog中的内容如下

 

ORA-00600: internal error code, arguments: [kcbz_check_objd_typ], [0], [0], [1], [], [], [], []
Mon Jun 27 12:10:55 2011
Errors in file /oracle/admin/zhdu/udump/zhdu2_ora_471.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ], [0], [0], [1], [], [], [], []
Mon Jun 27 12:11:31 2011
Errors in file /oracle/admin/zhdu/udump/zhdu2_ora_785.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ], [0], [0], [1], [], [], [], []
Mon Jun 27 12:12:09 2011
Errors in file /oracle/admin/zhdu/udump/zhdu2_ora_25118.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ], [0], [0], [1], [], [], [], []

这下郁闷了，看了下trace文件内容基本如下：

 

*** 2011-06-27 11:47:46.396
*** ACTION NAME:() 2011-06-27 11:47:46.396
*** MODULE NAME:(JDBC Thin Client) 2011-06-27 11:47:46.396
*** SERVICE NAME:(zhdu) 2011-06-27 11:47:46.396
*** SESSION ID:(371.6344) 2011-06-27 11:47:46.396
*** SESSION ID:(371.6344) 2011-06-27 11:47:46.396
OBJD MISMATCH typ=6, seg.obj=128602, diskobj=146729, dsflg=100000, dsobj=128602, tid=128602, cls=1

 

集合google出来的资料，发现问题是：

 

diskobj 是对象的data object id

dsobj 是object id

根据objectid来查询：

SQL> select t.object_id,t.data_object_id from dba_objects t where t.object_id = 146729;

OBJECT_ID DATA_OBJECT_ID
---------- --------------
146729 394023

SQL>

可以发现这个对象的data_object_id已经变了，而又由于此时PMON进程正在对这个表的数据进行事物的回滚操作，当PMON根据以上信息检查对象是发现对象不存在，于是就抛出了以上错误。

 

看来在线重定义也不是那么的安全啊，还好后来没什么大问题，job的问题确实是解决了，现在记录下来备忘，以后进行在线重定义的时候一定要小心了。