诗檀软件专业数据库修复团队
oerr ora 8102
08102, 00000, "index key not found, obj# %s, file %s, block %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
适用于：
Oracle Database - Enterprise Edition – 版本10.2.0.1 到12.1.0.2 [Release 10.2 to 12.1]
本文信息适用于任何平台。
主要内容
适用于
产品：
收集了什么，为什么？
该SRDC将收集由错误ORA-08102报告的启动块损坏的分析所需要的信息
行动计划
- .识别受影响的索引
ORA-08102的错误和跟踪文件为受影响的索引提供了obj＃（object_id）。
一个SQL*Plus会话收到错误的示例：
SQL> DELETE dept WHERE deptno=10;
DELETE dept WHERE deptno=10
*
行1的错误：
ORA-08102: index key not found,
obj# 46115, file 5, block 90 (2)
跟踪文件：
oer 8102.2 -
obj# 46115, rdba: 0x02c0005a(afn 5, blk# 90)
kdk key 8102.2:
ncol: 3, len: 16
key: (16):
06 c5 02 01 01 27 02 04 c3 02 32 33 06 02 c0 00 4a 00 05
通过运行下一个查询来识别索引；在示例中，obj_number 是 46115：
select *
from dba_objects
where object_id = &obj_number;
- 在基表上执行 ANALYZE VALIDATE STRUCTURE CASCADE
识别受影响索引的基表并表上运行analyze VALIDATE STRUCTURE CASCADE ：
ANALYZE TABLE <table name> VALIDATE STRUCTURE CASCADE ONLINE;
如果这是一个分区表，会生成错误ORA-14508；然后按照
Note 111990.1
如果分析生成错误ORA-01499 ，请上传跟踪文件。注意跟踪文件没有错误ORA-01499 但有以下信息：
"row not found in index"
"Table/Index row count mismatch"
"row mismatch in index dba"
"Table row count/Bitmap index bit count mismatch"
"kdavls: kdcchk returns %d when checking cluster dba 0x%08lx objn %d\n"
- 识别所有受影响的键值
可选地找出所有受影响的键，可以执行有索引搜索的全表搜索Full Table Scan：
不在索引中的表中行：
spool tablenotindex.log
SELECT /*+ FULL(t1) */ rowid, <indexed column list>
FROM <Table name> t1
MINUS
SELECT /*+ index(t <Index name>) */ rowid, <indexed column list>
FROM <Table name> t;
spool off
示例：
Table name = DEPT, Index name = I_DEPT1, Indexed columns in index I_DEPT1 are: DEPTNO, DNAME.
spool tablenotindex.log
SELECT /*+ FULL(t1) */ rowid, deptno, dname
FROM dept t1
MINUS
SELECT /*+ index(t I_DEPT1) */ rowid, deptno, dname
FROM dept t;
spool off
确保查询的执行疾患使用受影响的索引；例如执行计划中显示Index I_DEPT1。查询不使用索引的原因之一是列被所以为允许NULL 值，如果这样的话，添加一个where子句，例如：
where deptno is not null.
4.上传跟踪文件，警报日志，OS日志文件和历史记录
请上传：
- ORA-08102 错误的跟踪文件。
- ORA-01499 的跟踪文件（仅当ANALYZE 生成了ORA-01499错误）
- 所有实例的alert.log文件和相关错误的事件跟踪文件：
使用
Note:1676101.1 中所述的TFA Collector，这会收集所有需要的文件。
- 在步骤1 中执行的识别索引的查询的输出。
- 上传受影响对象的DDL 语句。有rows=N 的基表的导出可能有用，因为它包含表/索引定义（查看以上示例row=N的导出）。
- 在以上步骤2中创建的文件tablenotindex.log
- 提供索引最后如何被创建的描述。例如，它是否是用ONLINE选项创建的？PARALLEL子句是否被使用？等。
- 有关记录如何被插入基表的信息。例如，在基表中是否使用直接加载DIRECT Load？MERGE语句是否被使用？平行DML是否被使用？等。
- 获取在报告ORA-01499之前索引被重建/创建的最后时间的时间戳；查找索引上的dba_objects.LAST_DDL_TIME。
- 导致损坏的事件的详细历史；找出是否有任何显著的环境变化，例如硬件变化，操作系统的升级/补丁，最近的文件系统配置（添加新磁盘等），新的应用程序代码，新的init.ora参数，Oracle补丁，Oracle升级，和操作系统升级。
- 保存数据库和存档日志的备份
要保存的额外信息；以备进一步的调查：
保存从错误生成之前到错误报告至少6小时的归档日志文件。