客戶中一個資料庫做查詢時，報錯，出現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

【ERROR】ORA-8103錯誤分析處理

相關文章