SRDC – Required Diagnostic Data Collection for ORA-08102 必需的诊断数据收集的

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

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]
本文信息适用于任何平台。

主要内容

适用于

产品：

• 10.1到12.1的Oracle 数据库

收集了什么，为什么？

该SRDC将收集由错误ORA-08102报告的启动块损坏的分析所需要的信息

行动计划

1. .识别受影响的索引

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;

2. 在基表上执行 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”

3. 识别所有受影响的键值

可选地找出所有受影响的键，可以执行有索引搜索的全表搜索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升级，和操作系统升级。

5. 保存数据库和存档日志的备份

要保存的额外信息；以备进一步的调查：

• 保存生成错误时的数据库备份。

保存从错误生成之前到错误报告至少6小时的归档日志文件。