客户中一个数据库做查询时，报错，出现ORA-08103, 该错误主要有两方面原因，造成。 - 数据块的类型是无效的，或者读取的块类型跟Oracle数据库中描述不一致，如Oracle数据库人为该块类型是data(type=6),实际不是。 - 数据块中的data_object_id 和数据字典中的不一致，造成错误。（该错误也有一些bug，有时候清理一下缓存可临时解决） 下面我们通过一则示例 ，说明出现该错误是如果分析 处理 我们可以通过10046 跟踪，确定问题 ``` sql alter session set events '10046 trace name context forver,level 12'; select count(*) from xxx.table; alter session set events '10046 trace name context off'; ``` 分析trace文件 ``` shell #跟踪文件开头，有个明显的错误提示 [kteinckf] ORA-8103 unexpected block type:6 (0x6) [kteinckf] ORA-8103 in rdba:0x02403b03 #我们可以根据这个dba地址继续找 buffer tsn: 9 rdba: 0x02403b03 (9/15107) scn: 0xde09295d0cb seq: 0x02 flg: 0x04 tail: 0xd0cb0602 frmt: 0x02 chkval: 0x9613 type: 0x06=trans data Hex dump of block: st=0, typ_found=1 ``` 通过以上，我们可以确定，我们要找的数据类型与实际不匹配，该块类型是 事务数据。后边指向一个索引 ``` shell OBJD MISMATCH typ=6, seg.obj=87270, diskobj=87299, dsflg=100000, dsobj=87270, tid=87270, cls=1 FETCH #140737249388872:c=10630,e=11217,p=1,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2087748367,tim=22142578958182 STAT #140737249388872 id=1 cnt=0 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=0 pr=0 pw=0 str=1 time=16 us)' STAT #140737249388872 id=2 cnt=0 pid=1 pos=1 obj=475731 op='INDEX FULL SCAN USERINFO_PK (cr=0 pr=0 pw=0 str=1 time=7 us cost=1 size=0 card=157)' WAIT #140737249388872: nam='SQL*Net break/reset to client' ela= 4 driver id=1650815232 break?=1 p3=0 obj#=475731 tim=22142578958344 WAIT #140737249388872: nam='SQL*Net break/reset to client' ela= 127 driver id=1650815232 break?=0 p3=0 obj#=475731 tim=22142578958487 ``` 检查该索引相关信息 ``` sql SQL> select owner,tablespace_name,header_file,header_block,blocks,buffer_pool,inmemory from dba_segments 2 where segment_name='USERINFO_PK'; OWNER TABLESPACE_NAME HEADER_FILE HEADER_BLOCK BLOCKS BUFFER_ INMEMORY ---------- ------------------------------ ----------- ------------ ---------- ------- -------- TESTSA TESTSA_INDEX 139 15107 128 DEFAULT DISABLED ``` 发现，15107 是该索引的段头，正常来说不应该是 事务数据类型，再次确认 ``` sql select index_name,index_type,owner,table_name,UNIQUENESS,LAST_ANALYZED,SEGMENT_CREATED from dba_indexes where index_name='USERINFO_PK'; INDEX_NAME INDEX_TYPE OWNER TABLE_NAME UNIQUENES LAST_ANAL SEG --------------------------- --------------------------- ---------- -------------------- --------- --------- --- USERINFO_PK NORMAL TESTSA USERINFO UNIQUE 25-SEP-21 YES select segment_name,segment_type,owner,extent_id,file_id,block_id,blocks from dba_extents where file_id=139 and 15107 between block_id and block_id+blocks-1; SEGMENT_NAME SEGMENT_TYPE OWNER EXTENT_ID FILE_ID BLOCK_ID BLOCKS ------------------------- ------------------ ---------- ---------- ---------- ---------- ---------- APPS_KEY_PK INDEX TESTSA 28 139 15104 128 ``` 通过检查区信息，发现15107块被对象MPPS_KEY_PK使用，属于其区内事务块。USERINFO_PK在区中无信息。 清除该无效索引后，语句select count(*) 可以正常执行。 后续操作，为了排查该用户是否还存在，执行以下语句，发现有三个，与业务沟通后，删除重建。 ``` sql select distinct segment_name from dba_segments where owner='TESTSA' and segment_type='INDEX' minus select distinct segment_name from dba_extents where owner='TESTSA' and segment_type='INDEX' ; ``` 其他处理思路： 可以通过事件进行跟踪 ``` sql ALTER SYSTEM SET EVENTS ’8103 TRACE NAME ERRORSTACK LEVEL 3′; alter system set events='8103 trace name errorstack off'; ``` 该事件有以下级别： - 0 仅转储错误堆栈 - 1 转储错误堆栈和函数调用堆栈 - 2 level 1 + process state - 3 level 2 + context area （显示所有cursors，着重显示当前cursor） 可以通过以下命令进行处理 ``` sql alter system flush buffer cache; analyze validate structure; --分析索引的数据块是否有坏块，存放在index_state ``` 参考： - https://blog.csdn.net/lixora/article/details/8862875