帮忙查下ORA-08103异常，谢谢！
几个存储过程的日志中查出“ORA-08103: object no longer exists”，重跑存储过程又不报错误了。用dbv和rman查了相关表所在的数据文件，确认没有坏块。alert日志如附件，请帮忙提供下意见。非常感谢！ 1、对于 8103 dbv或rman 检测一般是没用的
2、你没提版本，就trace看是11.2.0.4.0 + RAC
3、
$ grep "seg/obj" 1.txt
seg/obj: 0x1e62f csc: 0x5c5.a3c70f65 itc: 2 flg: E typ: 1 - DATA
seg/obj: 0x1e62f csc: 0x5c5.bb80a7e2 itc: 2 flg: E typ: 1 - DATA
seg/obj: 0x1e62f csc: 0x5c5.9b9d806b itc: 2 flg: E typ: 1 - DATA
seg/obj: 0x1e62f csc: 0x5c5.bb7a40e5 itc: 2 flg: E typ: 1 - DATA
seg/obj: 0x1e62f csc: 0x5c5.bb80a7e4 itc: 2 flg: E typ: 1 - DATA
seg/obj: 0x1e62f csc: 0x5c5.a3c70f66 itc: 2 flg: E typ: 1 - DATA
seg/obj: 0x1e62f csc: 0x5c5.bb80a7e4 itc: 2 flg: E typ: 1 - DATA
seg/obj: 0x1e62f csc: 0x5c5.9b9d806c itc: 2 flg: E typ: 1 - DATA
seg/obj: 0x1e62f csc: 0x5c5.ea5a7ea5 itc: 2 flg: E typ: 1 - DATA
seg/obj: 0x1e62f csc: 0x5c5.f37ae3dd itc: 2 flg: E typ: 1 - DATA
seg/obj: 0x1e62f csc: 0x5c5.ea62e947 itc: 2 flg: E typ: 1 - DATA
seg/obj: 0x1e62f csc: 0x5c5.eed720e7 itc: 2 flg: E typ: 1 - DATA
seg/obj: 0x1e62f csc: 0x5c5.bb80a7e5 itc: 2 flg: E typ: 1 - DATA
seg/obj: 0x1e62f csc: 0x5c5.bb7a40e5 itc: 2 flg: E typ: 1 - DATA
seg/obj: 0x1e62f csc: 0x5c5.f37ae3de itc: 2 flg: E typ: 1 - DATA
============
Plan Table
============
----------------------------------------------------------------------+-----------------------------------+
| Id | Operation | Name | Rows | Bytes | Cost | Time |
----------------------------------------------------------------------+-----------------------------------+
| 0 | INSERT STATEMENT | | | | 21K | |
| 1 | LOAD TABLE CONVENTIONAL | | | | | |
| 2 | HASH JOIN RIGHT OUTER | | 2340 | 514K | 21K | 00:04:22 |
| 3 | TABLE ACCESS FULL | TB_QUOTATION | 9415 | 248K | 21K | 00:04:21 |
| 4 | VIEW | | 2340 | 452K | 115 | 00:00:02 |
| 5 | HASH JOIN RIGHT OUTER | | 2340 | 512K | 115 | 00:00:02 |
| 6 | VIEW | | 77 | 3003 | 4 | 00:00:01 |
| 7 | SORT UNIQUE | | 77 | 1771 | 4 | 00:00:01 |
| 8 | TABLE ACCESS FULL | TB_CAPITAL_ACCOUNT_COMBINATION| 77 | 1771 | 3 | 00:00:01 |
| 9 | HASH JOIN | | 2286 | 413K | 110 | 00:00:02 |
| 10 | TABLE ACCESS FULL | TCL_ORG | 48 | 1152 | 3 | 00:00:01 |
| 11 | HASH JOIN RIGHT OUTER | | 2285 | 359K | 107 | 00:00:02 |
| 12 | TABLE ACCESS FULL | TB_DICT_ENTRY_MAP | 19 | 912 | 11 | 00:00:01 |
| 13 | HASH JOIN OUTER | | 2285 | 252K | 96 | 00:00:02 |
| 14 | HASH JOIN RIGHT OUTER | | 2285 | 203K | 28 | 00:00:01 |
| 15 | TABLE ACCESS FULL | TB_DICT_ENTRY_MAP | 4 | 116 | 11 | 00:00:01 |
| 16 | TABLE ACCESS FULL | TRL_STKASSET | 2285 | 138K | 17 | 00:00:01 |
| 17 | TABLE ACCESS FULL | TCL_STOCK | 17K | 380K | 68 | 00:00:01 |
----------------------------------------------------------------------+-----------------------------------+
Content of other_xml column
===========================
dop_reason : IO calibrate statistics are missing
dop : 1
px_in_memory : no
db_version : 11.2.0.4
parse_schema : KINGSTAR
dynamic_sampling: 5
plan_hash : 943612278
plan_hash_2 : 4062143583
找出data_object_id=0x1e62f=124463 并作
analyze table xx validate structure cascade ;
或者 expdp 导出该全表
由于8103可能仅仅出现在cache中，所以执行上面命令以便验证，如果确实仅仅发生在cache中，那么可以忽略，如果发生在磁盘上，那么建议 重建该表 刘总回复真快啊！非常感谢！之前已对data_object_id=0x1e62f=124463的表做过analyze的动作（这张表的数据才1600多条），没有异常提示，并且这张表平时查询的多，但平时几乎不做dml及ddl。另外，您说的”8103可能仅仅出现在cache中，所以执行上面命令以便验证“，是什么意思呢？再次感谢！ http://www.askmaclean.com/archives/ora-8103.html 哎，根据您的指导，做了所有的动作，但存储过程还是时不时报8103的错误。 奇葩了！trc文件中居然还有调用SYS.DBMS_SPACE_ADMIN报8103的错误，这回真是完全不知道方向了。
页:
[1]