oracle_j000,trace目录产生极大xxxx_j000_xxx.trc文件

本帖最后由 alexanderr 于 2011-10-10 18:26 编辑

发现oracle home所在的/u01盘空间使用率快速增长

检查发现$oracle_base/diag/rdbms/test/test1/trace目录下产生非常大的trace文件，文件名类似xxxx_j000_xxx.trc，有几个达到5G，更有一个文件达到18G

检查trace文件内容，发现与ORA$AT_OS_OPT_SY_227计划任务有关，j000跟踪文件均由ORA$AT_OS_OPT_SY_%计划任务产生。

ORA$AT_OS_OPT_SY_%应该是oracle自动收集信息的计划任务，周一至周五晚上10点运行，周六，周日分别在早6点，早10点，下午2点，下午6点，晚上10点运行

同时alert log内有如下报错

Errors in file /u01/app/diag/rdbms/ctsdb/ctsdb1/trace/ctsdb1_j000_978962.trc:

ORA-12012: error on auto execute of job 1265803

ORA-00942: table or view does not exist

ORA-06512: at "SYS.DBMS_STATS_INTERNAL", line 176

ORA-06512: at "SYS.DBMS_STATS_INTERNAL", line 2786

ORA-06512: at "SYS.DBMS_STATS", line 26173

查询DBA_SCHEDULER_JOB_RUN_DETAILS 视图，发现ORA$AT_OS_OPT_SY_227的status为failed，ADDITIONAL_INFO栏位显示同alert log同样的报错

检查trace文件内容，类似如下

--------------------------------------------------------------------------------------------------------------

*** 2011-10-01 18:03:52.306

*** SESSION ID

22.47123) 2011-10-01 18:03:52.306

*** CLIENT ID

) 2011-10-01 18:03:52.306

*** SERVICE NAME

SYS$USERS) 2011-10-01 18:03:52.306

*** MODULE NAME

DBMS_SCHEDULER) 2011-10-01 18:03:52.306

*** ACTION NAME

ORA$AT_OS_OPT_SY_148) 2011-10-01 18:03:52.306

kcbzib: dump suspect buffer

buffer tsn: 6 rdba: 0x01802d2a (6/11562)

scn: 0x0000.066171db seq: 0x01 flg: 0x04 tail: 0x71db2301

frmt: 0x02 chkval: 0x52ab type: 0x23=PAGETABLE SEGMENT HEADER

Hex dump of block: st=0, typ_found=1

Dump of memory from 0x07000000FF89E000 to 0x07000000FF8A0000

7000000FF89E000 23A20000 01802D2A 066171DB 00000104  [#.....-*.aq.....]

7000000FF89E010 52AB0000 00000000 00000000 00000000  [R...............]

7000000FF89E020 00000000 00000001 00000008 0A9C0000  [................]

7000000FF89E030 00000000 00000003 00000008 01802D2B  [..............-+]

7000000FF89E040 00000000 00000000 00000000 00000000  [................]

7000000FF89E050 00180011 00031D51 00000001 00000000  [.......Q........]

7000000FF89E060 00000003 00000008 01802D2B 00000000  [..........-+....]

7000000FF89E070 00000000 00000000 00000000 01802D28  [..............-(]

7000000FF89E080 01802D28 00000000 00000000 00000000  [..-(............]

7000000FF89E090 00000000 00000000 00000000 00000000  [................]

Repeat 3 times

7000000FF89E0D0 00010000 00002000 00000000 00001434  [...... ........4]

7000000FF89E0E0 00000000 01802D29 00000001 01802D28  [......-)......-(]

7000000FF89E0F0 01802D29 00000000 00000000 00000000  [..-)............]

7000000FF89E100 00000000 00000000 00000001 00000000  [................]

7000000FF89E110 0010668F 10000000 01802D28 00000008  [..f.......-(....]

7000000FF89E120 00000000 00000000 00000000 00000000  [................]

。

。

。

REDO RECORD - Thread:2 RBA: 0x0004f8.0001142c.0098 LEN: 0x0048 VLD: 0x01

SCN: 0x0000.066c16ef SUBSCN:  3 10/01/2011 20:31:01

CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:0 OP:18.3 ENC:0

Reuse redo entry

Object reuse: tsn=6 objd=1078246

REDO RECORD - Thread:2 RBA: 0x0004f8.00011434.0010 LEN: 0x0074 VLD: 0x05

SCN: 0x0000.066c173e SUBSCN:  1 10/01/2011  20:31:01

-------------------------------------------------------------------------------------------

检查之后的expdp备份日志发现有报错

ORA-31693: Table data object "EASORA"."VTIAMEQVZ6VAJ6X1GL95X8HXI" failed to load/unload and is being skipped due to error:

ORA-02354: error in exporting/importing data

Job "SYSTEM"."SYS_EXPORT_FULL_05" completed with 37 error(s) at 00:46:46

37处error全是说VT表找不到，VT表为临时表，系统会随时删随时建

为什么会导致trace文件猛涨？

跟VT表被删除导致自动分析的job出错导致的吗？

求解

2011-10-10 18:26 上传

点击文件名下载附件

68.17 KB, 下载次数: 10