select 操作报ora-8103

ALLSTARS_ORACLE

对一张大分区表进行selecct count（*） 操作，出现报错ora-8103，对象不在存在
用rman执行了validata database ,在相关视图里面没有出现记录
在使用analyze table validate structure的时候，可以执行select count(*) 操作，且不会报错，但表记录一直没有改变


做了每个节点的flush buffer_cache和shared_pool，仍旧查询报错，也执行了alter diskgroup check norepair提示no error
按metalink 说
In 9.2.0.8 or above if ktrget is in the call stack trace for an ORA-8103, setting Event 10236 will include the block number causing the error:

alter session set events '8103 trace name errorstack level 3';
alter session set events '10236 trace name context forever, level 1';
alter session set tracefile_identifier='ORA8103';

run the query that produces the error ORA-8103 and identify the trace with the form of <sid>_ora_<pid>_ORA8103.trc

Open the trace file and if function ktrget is in the call stack trace, then the trace file may have:

KTRVAC: path typ=22, rdba=32810e06

Meaning that the error is produced in rdba=0x32810e06 . Convert that number to decimal and get the relative_fno, block#:

select dbms_utility.data_block_address_file(847318534) relative_fno
,dbms_utility.data_block_address_block(847318534) block#
from dual;

RELATIVE_FNO BLOCK#
------------ ----------
         202 69126

Then use Note <> to identify the object; section "Identify the Corrupt Object".
Identify the object with event 10200.

Event 10200 can be used to identify the last accessed block when this error is produced. event trace_buffer_on can be used to generate a smaller trace file.  Errorstack and event 10236 can be added to get a more complete trace file:

alter session set max_dump_file_size=unlimited;
alter session set db_file_multiblock_read_count=1;
alter session set events 'immediate trace name trace_buffer_on level 1048576';
alter session set events '10200 trace name context forever, level 1';
alter session set events '8103 trace name errorstack level 3';
alter session set events '10236 trace name context forever, level 1';
alter session set tracefile_identifier='ORA8103';

run the query that produces the error ORA-8103

alter session set events 'immediate trace name trace_buffer_off';
exit

Identify the trace with the form of <sid>_ora_<pid>_ORA8103.trc

In the trace file generated locate last information about:

"Consistent read started for block <XXX>: <YYY>"

where XXX is the tablespace number and YYY is the rdba for that block.  Normally this is the affected block.






现在是只要全表扫，整个表或一个分区一个分区的全表扫描都没有问题，不会有报错
走快速索引扫描就会报ora-01410 无效rowid，已经重建过索引，重建索引前报ora-8103 对象不再存在
用rman检查坏块，也没有坏块记录，登入asm实例alter diskgroup check norepair了所有磁盘组也没有报错在后台日志
清空了buffer cache 和shared pool很多次，仍然报错，重建索引前进行过analyze structure，仍旧查询报错
做了errorstack ，查到了块号和文件号，但是查询对象时是空
也按metalink 做了很多events 最后也没有consisitent read block。。。。的内容

目前尝试再次analyze table structure和index ，以我的情况，是否可以判断出是索引导致的，而非其他原因导致？