Email: service@parnassusdata.com 7 x 24 online support!

    You are here

    • You are here:
    • Home > Blogs > PDSERVICE's blog > SRDC – Required Diagnostic Data Collection for ORA-08102 必需的诊断数据收集的

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

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;

 

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

 

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

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

 

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

要保存的额外信息;以备进一步的调查:

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

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