Email: service@parnassusdata.com 7 x 24 online support!
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报告的启动块损坏的分析所需要的信息
行动计划
- .识别受影响的索引
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小时的归档日志文件。