索引数据块损坏日志不停trace ero 8102

----alter 日志

Restarting dead background process DIA0
Fri Jul 18 08:36:22 2014
DIA0 started with pid=10, OS id=15008848 
Fri Jul 18 08:40:27 2014
Errors in file /u01/app/oracle/diag/rdbms/stddb/stddb2/trace/stddb2_ora_27132018.trc:
Fri Jul 18 08:40:29 2014
Dumping diagnostic data in directory=[cdmp_20140718084029], requested by (instance=2, osid=27132018), summary=[abnormal process termination].


---检查trace
user session for deadlock lock 0x700004a45872c60
  sid: 3358 ser: 16187 audsid: 508641698 user: 118/YTSTL
    flags: (0x100045) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
    flags2: (0x40009) -/-/INC
  pid: 1885 O/S info: user: grid, term: UNKNOWN, ospid: 14091666
    image: oracle@standby2
  client details:
    O/S info: user: Administrator, term: unknown, ospid: 1234
    machine: vmu010101 program: JDBC Thin Client
    application name: JDBC Thin Client, hash value=2546894660
  current SQL:
  UPDATE STL.T_STL_TRANSFER_DIGEST SET TRANS_WEIGHT = CASE WHEN :1  IS NULL THEN TRANS_WEIGHT ELSE :2  END , SEND_BACK = CASE 
WHEN :3  IS NULL THEN SEND_BACK ELSE :4  END,  SCAN_RULE_TYPE_CODE = :5  , EXPRESS_CONTENT_CODE = :6  , MODIFY_TIME = :7  , OP_CODE 
= :8  , AUX_OP_CODE = :9  , IO_TYPE = :10  , CONTAINER_NO = CASE WHEN :11  IS NULL THEN CONTAINER_NO ELSE :12  END  WHERE WAYBILL_NO
 = :13  
DUMP LOCAL BLOCKER: initiate state dump for TIMEOUT
  possible owner[1885.14091666] on resource TX-13410007-0144525B


*** 2014-07-18 02:12:12.227
Submitting asynchronized dump request [28]. summary=[ges process stack dump (kjdglblkrdm1)].
oer 8102.2 - obj# 9421646, rdba: 0xecb4ad12(afn 946, blk# 3452178)


---注意这一句 oer 8102.2 - obj# 9421646, rdba: 0xecb4ad12(afn 946, blk# 3452178)
***********************************************
ORA-8102错误出现的原理是当表或者LOB SEGMENT上存在一个键值，但是该键值在索引上却找不到时，则出现错误。
其TRACE部分类似于：


oer 8102.<code> - obj# <object id>, rdba: <rdba value>(afn <file#>, blk# <block#>)
kdk key 8102.2:
ncol: <number of columns in the key including the rowid>, len: <key length>
key: (<length>):<hexadecimal value>


其中 obj#为 受影响对象的object_id， rdba为相对数据块地址，AFN为绝对文件号，blk#为 该key应当存放在的索引的块号。
***********************************************
分析：
首先trace 里有报出一个语句，我们可以大概确认是哪个表。
然后我们根据  oer 8102.2 这句提示的一系列信息，我们可以去查询：
select * from dba_objects where object_id='9421646';  ---找到出现问题的对象
 ---我这边是索引 IDX_DIGEST_05 
--------------------------------
select  header_file,header_block,relative_fno   
from dba_segments where segment_name='IDX_DIGEST_05' and partition_name='PAR_2014_07_18' ;
---我们可以看到头文件，头快，相对文件号等信息
--------------------------------
select * from dba_part_indexes where index_name='IDX_DIGEST_05' and owner='STL';
---我们也可以根据查到的索引去确认表（通过该操作，我确认了出问题的表就上面update 语句所修改的表）
--------------------------------
select * from dba_data_files where file_id=946 ;
select * from v$datafile where file#=946 ;
---如果有必要我们也可以通过文件号找到对应的数据文件
--------------------------------


结论：通过8102的原理及从trace 文件中得到的信息，可以确认，是索引IDX_DIGEST_05出了问题。
常规解决方案：重建索引，分析表，或者删除索引，重建索引


*****************************************************
使用ANALYZE TABLE VALIDATE STRUCTURE CASCADE;命令来验证，如果确实存在表和索引的不一致则会出现ORA-149
-------
也可以选择 通过全表扫描的结果与索引扫描的结果对比：
 
SELECT /*+ FULL(t1) */ <indexed column list>
FROM <Table name> t1
MINUS
SELECT /*+ index(t <Index name>) */ <indexed column list>
FROM <Table name> t;
需要保证该查询的执行计划确实使用了受损的索引搜索，可以通过查看执行计划来确认


ORA-8102即可能是ORACLE的bug，也可能是由于硬件I/O错误所引起。
硬件或者I/O子系统由于丢失写 Lost Write造成块的逻辑上讹误，当一个Lost Io发生，包含对key的修改或者没有写入到ORACLE数据文件上，这即可能发生在表块上也可能发生在索引块上。


 
若已经确认是由于表和索引间的不一致引起的ORA-8102，则drop和重建索引可以解决大部分情况。
 
但是如果确认是表上存在的损坏，则解决方法可以是 单独修复表上的损坏块 或者 考虑重建表。
如果发生错误的是LOB Index，则移动LOB并重建LOB INDEX
 
alter table &table_owner.&table_with_lob
move LOB (&&lob_column) store as (tablespace &tablespace_name);
*****************************************************