您的位置:首页 > 其它

解决ORA-08102: index key not fou…

2017-05-02 10:45 411 查看
如图,执行存储过程报错

ORA-08102: index key
not found, obj# 304067, dba 33580767 (2)

oerr ora 8102

08102, 00000, "index key not found, obj# %s, dba %s (%s)"

// *Cause: Internal error: possible inconsistency in index

// *Action: Send trace file to your customer support
representative, along

// with information on reproducing the error

错误信息的意思似乎是需要重新建立索引。

SQL> SELECT owner, object_name, object_type

 
2       
FROM Dba_Objects

 
3      
WHERE object_id IN (304067);

OWNER                         
OBJECT_NAME                                                                     
OBJECT_TYPE

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

SHARE001                      
IDX_SHARE_TMP_IPID                                                              
INDEX

SQL>alter index share001.IDX_SHARE_TMP_IPID
rebuild online;

问题解决!

别人解决此问题的方法:

应用报错:SQLERRM =ORA-08102[/b]: index key
not found, obj# 255136, dba 3137557995 (2)

经过analyze table t validate structure
cascade;验证表和索引的完整性。在udump产生一个trace文件。

  *** SESSION ID:(570.35812) 2006-01-01 10:49:34.095

  row not found in index tsn: 37 rdba: 0xfe037009

  env: (scn: 0x0725.c9cfed6d xid: 0x0000.000.00000000 uba:
0x00000000.0000.00)col 0; len 4; (4): 38 34 30 20

  col 1; len 4; (4): 38 34 30 20

  col 2; len 12; (12): 39 32 39 31 35 33 30 30 20 20 20 20

  col 3; len 10; (10): 30 30 30 65 74 64 42 38 45 30

  col 4; len 1; (1): 80

  col 5; len 1; (1): 80

  col 6; len 1; (1): 80

  col 7; len 1; (1): 80

  col 8; NULL

  col 9; len 6; (6): ff c3 26 01 00 15Block header dump:
0xffc32601

  Object id on Block? Y

  seg/obj: 0x28fec csc: 0x725.c9568687 itc: 32 flg: - typ: 1 -
DATA

  fsl: 0 fnx: 0x0 ver: 0x01

  ................................................

  同时在trace文件中列出了和表数据不一致的索引项。
如上黑体字部分应该是Oracle验证的正确的表数据的索引项格式。

  而我在该trace文件的Block dump部分却没有找到对应的索引条目。且index block
dump中的格式(如下)明显不匹配索引的定义。

  tab 0, row 0, @0x41e

  tl: 102 fb: --H-FL-- lb: 0x0 cc: 19

  col 0: [10] 30 30 30 65 74 64 41 37 31 57

  col 1: [ 4] 38 34 30 20

  col 2: [ 4] 38 34 30 20

  col 3: [12] 39 32 39 31 35 36 30 30 20 20 20 20

  col 4: [ 4] 4d 52 50 59

  col 5: [ 1] 42

  col 6: [10] 30 30 30 31 77 79 4e 54 57 77

  col 7: [ 3] 45 55 52

  col 8: [ 1] 80

  col 9: [ 1] 80

  col 10: [ 1] 80

  col 11: [ 1] 80

  col 12: [ 7] 78 69 0c 1f 18 3c 01

  col 13: *NULL*

  col 14: [10] 2e 31 30 34 38 34 35 32 31 38

  col 15: [10] 2e 31 30 34 38 34 35 31 30 34

  col 16: *NULL*

  col 17: *NULL*

  col 18: [ 1] 80

  该索引建立在9列上。而index block dump显示的却是18列。
经过检查,该索引为compress的;怀疑compress导致索引不一致。查metalink,也发现很多与compress
index相关的bug.

  然后删除/重新建立非压缩索引(或者rebuild
online;rebuild可能会读取原先的索引段而不会去读表),查询成功,错误消失。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐