執行job時出現錯誤ORA-08102

1.問題&處理

昨天在做定期清理job的時候出現ORA-08102的錯誤

BAK.PKG_CLEAN.PROC_MS_CLEANfailed: ORA-08102: index key not found, obj# 58401, file 69, block 447746 (2)

--查看58401這個對象具體是什麼

SELECT owner, object_name, object_type FROM Dba_ObjectsWHERE object_id=58401;

 

OWNER               OBJECT_NAME   OBJECT_TYPE

-------------------------------------------------------------------

MS                      IDX_MI_VV                   INDEX

 

將索引rebuild online即可。

alter index MS.IDX_MI_VV rebuild online;

 

2.查閱文檔

查閱下metalink對此問題的解釋：

ORA-08102:TRYING TO MANIPULATE A JOB IN DBA_JOBS [ID 1036858.6]

***Checked forrelevance on 17-NOV-2010***

Problem Description:

====================

You are trying tomanipulate a job in the job queue

(DBA_JOBS/USER_JOBS)and you receive:

 

 ORA-08102: index key not found, object...

     Cause: Internal error: possibleinconsistency in index

    Action: Send trace file to your customersupport representative, along

            with information on reproducing theerror

 

Example:

SQL> executedbms_job.remove(1);

ORA-08102: indexkey not found, object #124 ->>> SYS.I_JOB_NEXT

where object #124is the object# in DBA_OBJECTS

 

SQL> columnowner format a10

SQL> columnobject_type format a10

SQL> columnobject_id format 99999

SQL> columnobject_name format a10

 

SQL> selectowner, object_name, object_type, object_id

  2  fromdba_objects where object_id=124;

OWNER      OBJECT_NAM OBJECT_TYP OBJECT_ID

-------------------- ---------- ---------

SYS        I_JOB_NEXT INDEX            124                       

 

Solution Description:

=====================

You need torecreate the index I_JOB_NEXT.

Script"$ORACLE_HOME/rdbms/admin/cat7103.sql" creates the I_JOB_NEXT:

Drop and recreatethis index.

connect sys/<password>

drop index i_job_next;

create index i_job_next on job$ (next_date)

Note: alter index I_JOB_NEXT rebuild;

Willnot fix the problem.

直接rebuild索引不能解決這個問題，需要刪除後重建。

 

Explanation:

============

The ORA-8102pointed to index corruption, so rebuilding the offending index

fixed the problem.

 

3.拓展

如果index的obj# <56，即爲bootstrap$核心對象，那麼使用event 38003或migrate 模式都無法rebuild 該index。可以藉助BBED來進行修復。

參考博客love wife & love life —Roger：

http://www.killdb.com/2011/07/30/bootstrap%e6%a0%b8%e5%bf%83%e5%af%b9%e8%b1%a1%e6%95%b0%e6%8d%ae%e4%b8%8d%e4%b8%80%e8%87%b4%e5%af%bc%e8%87%b4ora-08102.html

昨天準備研究11g的query cache result特性，準備用10g的老方法來直接通過
show parameter xxxx的方式來查看隱含參數，發現下面的創建視圖語句居然報錯ora-08102
如下是創建視圖的腳本，後面是錯誤：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

CREATE OR REPLACE VIEW show_hidden_v$parameter (inst_id,                                                 num,                                                 NAME,                                                 TYPE,                                                 VALUE,                                                 display_value,                                                 isdefault,                                                 isses_modifiable,                                                 issys_modifiable,                                                 isinstance_modifiable,                                                 ismodified,                                                 isadjusted,                                                 isdeprecated,                                                 description,                                                 update_comment,                                                 HASH                                                ) AS    SELECT x.inst_id, x.indx+1, ksppinm, ksppity, ksppstvl, ksppstdvl,           ksppstdf, DECODE (BITAND (ksppiflg / 256,1),1, 'TRUE','FALSE'),           DECODE (BITAND (ksppiflg / 65536, 3),                   1,'IMMEDIATE',                   2,'DEFERRED',                   3,'IMMEDIATE',                   'FALSE'                  ),           DECODE (BITAND (ksppiflg, 4),                   4,'FALSE',                   DECODE (BITAND(ksppiflg/65536,3), 0,'FALSE','TRUE')                  ),           DECODE (BITAND (ksppstvf, 7),                   1,'MODIFIED',                   4,'SYSTEM_MOD',                   'FALSE'                  ),           DECODE (BITAND (ksppstvf, 2), 2,'TRUE','FALSE'),           DECODE (BITAND (ksppilrmflg / 64, 1),1,'TRUE', 'FALSE'), ksppdesc,           ksppstcmnt, ksppihash      FROM x$ksppi x, x$ksppcv y     WHERE (x.indx = y.indx);

ORA-08102: index key not found, obj# 39, file 1, block 59847 (2)

從上面的8102錯誤來看，很明顯是數據字典信息不一致了，也就是說該記錄在ind$可能已經被清除了，
而在obj$中還存在。我們來看看obj# 39是什麼對象？

SQL> SELECT relative_fno, owner, segment_name, segment_type

  2  FROM dba_extents

  3  WHERE file_id=1

  4  AND59847BETWEEN block_idAND block_id+ blocks - 1;

 

RELATIVE_FNO OWNER   SEGMENT_NAME                   SEGMENT_TYPE

------------ ------- ------------------------------ ------------------

           1 SYS     I_OBJ4                        INDEX

 

SQL> SELECT owner,object_name,object_type,object_idFROM                                                              

  2  dba_objects WHERE object_name='I_OBJ4';                                                                          

 

OWNER                OBJECT_NAME               OBJECT_TYPE          OBJECT_ID                                         

-------------------- ------------------------- ------------------- ----------                                         

SYS                  I_OBJ4                    INDEX                      39

對於ora-08102錯誤，如果是發生在index上，那麼我們直接drop index然後重建就ok了。
那我們來試試直接重建會怎麼樣？

SQL> ALTER systemSET event='38003 trace name context forever, level 10' scope=spfile;

System altered.

 

SQL> shutdown immediate;

DATABASE closed.

DATABASE dismounted.

ORACLE instance shut down.

 

SQL> startup

 

ORACLE instance started.

Total System Global Area  167395328 bytes

Fixed SIZE                 1335220 bytes

Variable SIZE            104857676 bytes

DATABASE Buffers          58720256 bytes

Redo Buffers                2482176 bytes

DATABASE mounted.

DATABASE opened.

 

SQL> ALTERINDEX I_OBJ4 rebuild;

ALTER INDEX I_OBJ4 rebuild

*

ERROR at line 1:

ORA-00604: error occurred at recursiveSQL level1

ORA-00060: deadlock detected while waitingFOR resource

 

SQL> shutdown abort;

ORACLE instance shut down.

 

SQL> startup migrate;

 

ORACLE instance started.

Total System Global Area  167395328 bytes

Fixed SIZE                 1335220 bytes

Variable SIZE            104857676 bytes

DATABASE Buffers          58720256 bytes

Redo Buffers                2482176 bytes

DATABASE mounted.

DATABASE opened.

 

SQL> ALTERINDEX I_OBJ4 rebuild;

ALTER INDEX I_OBJ4 rebuild

*

ERROR at line 1:

ORA-00604: error occurred at recursiveSQL level1

ORA-00060: deadlock detected while waitingFOR resource

 

SQL> DROPINDEX I_OBJ4;

DROP INDEX I_OBJ4

           *

ERROR at line 1:

ORA-00701: object necessary FOR warmstarting DATABASE cannot be altered 

 

SQL> ALTERINDEX I_OBJ4 rebuild online;

ALTER INDEX I_OBJ4 rebuild online

*

ERROR at line 1:

ORA-00604: error occurred at recursiveSQL level1

ORA-08102: INDEXKEYNOT found, obj#39, file1, block 59847(2)

 

SQL> analyze TABLE obj$ VALIDATESTRUCTURE CASCADE;

analyze TABLE obj$ VALIDATESTRUCTURE CASCADE

*

ERROR at line 1:

ORA-01499: TABLE/INDEXCROSS reference failure - see trace file

到這裏，可能有人會問，爲什麼使用event 38003或migrate模式無法rebuild該index呢？
很簡單，該index的obj# <56,換句話說，也就是對於bootstrap$核心對象是無法通過上面
的2種方式來完成重建的。

通常來說到這個地步，如果不使用其他手段的話，那麼只能使用ODU或DUL進行抽取數據然後重建數據庫了。
其實對於這個問題，我們可以藉助BBED來進行修復。
既然是數據不一致，那麼我就想知道到底是哪兒不一致了？metalink提供處理ora-8102的方法：

SQL> SELECT/*+ FULL(t1) */ DATAOBJ#,TYPE#, OWNER#, rowid

  2  FROM obj$ t1

  3  MINUS

  4  SELECT/*+ index(t I_OBJ4) */ DATAOBJ#,TYPE#, OWNER#, rowid

  5  FROM obj$ t;

 

  DATAOBJ#      TYPE#     OWNER# ROWID

---------- ---------- ---------- ------------------

     73416          2          0 AAAAASAABAAAPt8AAB

     73419          0          0 AAAAASAABAAAADxAAb

 

SQL> SELECT obj#,OWNER#,NAME,TYPE#,STATUS,FLAGSFROM obj$ WHERE rowid='AAAAASAABAAAPt8AAB';

 

      OBJ#     OWNER# NAME                                TYPE#     STATUS      FLAGS

---------- ---------- ------------------------------ ---------- ---------- ----------

     73416          0 TEST01                                  2         1         0

 

SQL> SELECT obj#,OWNER#,NAME,TYPE#,STATUS,FLAGSFROM obj$ WHERE rowid='AAAAASAABAAAADxAAb';

 

      OBJ#     OWNER# NAME                                TYPE#     STATUS      FLAGS

---------- ---------- ------------------------------ ---------- ---------- ----------

         1          0 _NEXT_OBJECT                            0         0         0

 

SQL> SELECTCASE

  2            WHEN(nextobjnum- maxobjnum)>0

  3               THEN'GOOD'

  4            ELSE'BAD'

  5         END"OBJ_NUM_STATE"

  6    FROM(SELECT(SELECT dataobj#

  7                    FROM SYS.obj$

  8                   WHERE NAME = '_NEXT_OBJECT') nextobjnum,

  9                 (SELECT MAX (obj#)

 10                    FROM SYS.obj$) maxobjnum

 11          FROM DUAL);

 

 

OBJ_

----

GOOD

從這裏來看，_NEXT_OBJECT是ok的。那麼我們重點就放在TEST01上了。
到這裏，看到test01，我纔想起這是很久以前做關於手工構造某個由於數據字典信息不一致而引發的某個600錯誤
而留下的隱患。

根據前面的報錯，我們找到相應的trace，發現如下信息：

oer 8102.2 - obj# 39, rdba: 0x0040e9c7(afn 1, blk# 59847)

kdk key 8102.2:

  ncol: 4, len: 16

  key: (16):  04 c3 08 23 14 01 80 01 80 06 00 40 00 f1 00 1b

  mask: (2048):

這裏簡單的進行說明：
ncol — 表示列數目
len — 表示長度
key: ():

關於ora-08012錯誤，大家可以參考

OERR: ORA-8102“index key not found, obj# %s, file %s, block %s (%s)” [ID 8102.1]

下面我們繼續，既然該block有問題，那麼我就dump該block。

SQL> ALTER system dump datafile1 block59847;   確定爲如下2行數據：   ROW#131[2131] flag:---D--, lock: 3, len=18 col 0; len 4; (4):  c3 0823 0a col 1; len 1; (1): 80 col 2; len 1; (1): 80 col 3; len 6; (6):  0040 00 f1 00 1b   ROW#133[2113] flag:------, lock: 3, len=18 col 0; len 4; (4):  c3 0823 0f col 1; len 1; (1): 80 col 2; len 1; (1): 80 col 3; len 6; (6):  0040 00 f1 00 1b   SQL> SELECT2131+44+24*3FROM dual;   2131+44+24*3 ------------         2247

BBED> set file 1 block 59847           FILE#           1         BLOCK#          59847   BBED> set offset 2247           OFFSET          2247   BBED> d /v    File: /oracle/product/oradata/roger/system01.dbf (1)  Block: 59847   Offsets: 2247 to 2758  Dba:0x0040e9c7 -------------------------------------------------------  010304c3 08230a01 80018006 004000f1 l .....#.......@..  001b0000 04c30823 0202c102 01800600 l .......#........  40fb7c00 1a010003 c3082302 c1020180 l @.|.......#.....  060040fb 7c001b00 0004c308 226402c1 l ..@.|......."d..  03018006 00402750 00090100 04c30822 l .....@'P......."  6202c102 01800600 40fb7c00 1a010004 l b.......@.|.....  c3082263 02c10201 80060040 fb7c001c l .."c.......@.|..  010004c3 08230501 80018006 004000f1 l .....#.......@..  001b0100 04c30822 6002c102 01800600 l ......."`.......  40fb7c00 1a010004 c3082264 01800180 l @.|......."d....  06004000 f1001b01 0004c308 225e02c1 l ..@........."^..  02018006 0040fb7c 001c0100 04c30822 l .....@.|......."  5d02c102 01800600 40fb7c00 1b010004 l ].......@.|.....  c308225b 02c10201 80060040 fb7c001c l .."[.......@.|..  010004c3 08225a02 c1020180 060040fb l ....."Z.......@.  7c001a01 0004c308 225f0180 01800600 l |......."_......  4000f100 1b010004 c3082256 02c11501 l @........."V....  80060040 fb7c0019 000004c3 08225702 l ...@.|......."W.  c1150180 060040fb 7c001801 0004c308 l ......@.|.......  225502c1 14018006 0040fb7b 000f0000 l "U.......@.{....  04c30822 5402c114 01800600 40fb7c00 l ..."T.......@.|.  17010004 c308225a 01800180 06004000 l ......"Z......@.  f1001b01 0004c308 225202c1 15018006 l ........"R......  0040fb7c 00160000 04c30822 5302c115 l .@.|......."S...  01800600 40fb7c00 15010004 c3082251 l ....@.|......."Q  02c11401 80060040 fb7b000c 000004c3 l .......@.{......  08225002 c1140180 060040fb 7c001401 l ."P.......@.|...  0004c308 22550180 01800600 4000f100 l ...."U......@...  1b010004 c308224e 02c11501 80060040 l ......"N.......@  fb7c0013 000004c3 08224f02 c1150180 l .|......."O.....  060040fb 7c001201 0004c308 224d02c1 l ..@.|......."M..  14018006 0040fb7b 00090000 04c30822 l .....@.{......."    <16 bytes per line>   BBED> modify /x 14 offset 2253    File: /oracle/product/oradata/roger/system01.dbf (1)  Block: 59847            Offsets: 2253 to 2764           Dba:0x0040e9c7 ------------------------------------------------------------------------  14018001 80060040 00f1001b 000004c3 08230202 c1020180 060040fb 7c001a01  0003c308 2302c102 01800600 40fb7c00 1b000004 c3082264 02c10301 80060040  27500009 010004c3 08226202 c1020180 060040fb 7c001a01 0004c308 226302c1  02018006 0040fb7c 001c0100 04c30823 05018001 80060040 00f1001b 010004c3  08226002 c1020180 060040fb 7c001a01 0004c308 22640180 01800600 4000f100  1b010004 c308225e 02c10201 80060040 fb7c001c 010004c3 08225d02 c1020180  060040fb 7c001b01 0004c308 225b02c1 02018006 0040fb7c 001c0100 04c30822  5a02c102 01800600 40fb7c00 1a010004 c308225f 01800180 06004000 f1001b01  0004c308 225602c1 15018006 0040fb7c 00190000 04c30822 5702c115 01800600  40fb7c00 18010004 c3082255 02c11401 80060040 fb7b000f 000004c3 08225402  c1140180 060040fb 7c001701 0004c308 225a0180 01800600 4000f100 1b010004  c3082252 02c11501 80060040 fb7c0016 000004c3 08225302 c1150180 060040fb  7c001501 0004c308 225102c1 14018006 0040fb7b 000c0000 04c30822 5002c114  01800600 40fb7c00 14010004 c3082255 01800180 06004000 f1001b01 0004c308  224e02c1 15018006 0040fb7c 00130000 04c30822 4f02c115 01800600 40fb7c00  12010004 c308224d 02c11401 80060040 fb7b0009 000004c3 08224c02 c1140180    <32 bytes per line>   BBED> sum apply   Check value for File 1, Block 59847: current = 0xe5a9, required = 0xe5a9 BBED> modify /x 14 offset 2235  File: /oracle/product/oradata/roger/system01.dbf (1)  Block: 59847            Offsets: 2235 to 2746           Dba:0x0040e9c7 ------------------------------------------------------------------------  14018001 80060040 00f1001b 010304c3 08231401 80018006 004000f1 001b0000  04c30823 0202c102 01800600 40fb7c00 1a010003 c3082302 c1020180 060040fb  7c001b00 0004c308 226402c1 03018006 00402750 00090100 04c30822 6202c102  01800600 40fb7c00 1a010004 c3082263 02c10201 80060040 fb7c001c 010004c3  08230501 80018006 004000f1 001b0100 04c30822 6002c102 01800600 40fb7c00  1a010004 c3082264 01800180 06004000 f1001b01 0004c308 225e02c1 02018006  0040fb7c 001c0100 04c30822 5d02c102 01800600 40fb7c00 1b010004 c308225b  02c10201 80060040 fb7c001c 010004c3 08225a02 c1020180 060040fb 7c001a01  0004c308 225f0180 01800600 4000f100 1b010004 c3082256 02c11501 80060040  fb7c0019 000004c3 08225702 c1150180 060040fb 7c001801 0004c308 225502c1  14018006 0040fb7b 000f0000 04c30822 5402c114 01800600 40fb7c00 17010004  c308225a 01800180 06004000 f1001b01 0004c308 225202c1 15018006 0040fb7c  00160000 04c30822 5302c115 01800600 40fb7c00 15010004 c3082251 02c11401  80060040 fb7b000c 000004c3 08225002 c1140180 060040fb 7c001401 0004c308  22550180 01800600 4000f100 1b010004 c308224e 02c11501 80060040 fb7c0013  000004c3 08224f02 c1150180 060040fb 7c001201 0004c308 224d02c1 14018006    <32 bytes per line>   BBED> sum apply   Check value for File 1, Block 59847: current = 0xfea9, required = 0xfea9   BBED> verify   DBVERIFY - Verification starting FILE = /oracle/product/oradata/roger/system01.dbf BLOCK = 59847   Block Checking: DBA = 4254151, Block Type = KTB-managed data block **** row 132: key out of order ---- end index block validation Block 59847 failed with check code 6401   DBVERIFY - Verification complete   Total Blocks Examined         : 1 Total Blocks Processed (Data) : 0 Total Blocks Failing   (Data) : 0 Total Blocks Processed (Index): 1 Total Blocks Failing   (Index): 1 Total Blocks Empty            : 0 Total Blocks Marked Corrupt   : 0 Total Blocks Influx           : 0 Message 531 not found;  product=RDBMS; facility=BBED   最後重啓後，創建成功，再次檢查發現一切ok。   BBED> verify   DBVERIFY - Verification starting FILE = /oracle/product/oradata/roger/system01.dbf BLOCK = 59847   DBVERIFY - Verification complete   Total Blocks Examined         : 1 Total Blocks Processed (Data) : 0 Total Blocks Failing   (Data) : 0 Total Blocks Processed (Index): 1 Total Blocks Failing   (Index): 0 Total Blocks Empty            : 0 Total Blocks Marked Corrupt   : 0 Total Blocks Influx           : 0 Message 531 not found;  product=RDBMS; facility=BBED

最後嘗試創建視圖，發現一切正常，如下：

SQL> CREATEORREPLACE VIEW show_hidden_v$parameter(inst_id,

  2                                                  num,

  3                                                  NAME,

  4                                                 TYPE,

  5                                                  VALUE,

  6                                                  display_value,

  7                                                  isdefault,

  8                                                  isses_modifiable,

  9                                                  issys_modifiable,

 10                                                  isinstance_modifiable,

 11                                                  ismodified,

 12                                                  isadjusted,

 13                                                  isdeprecated,

 14                                                  description,

 15                                                  update_comment,

 16                                                  HASH

 17                                                 )

 18  AS

 19     SELECT x.inst_id, x.indx+1, ksppinm, ksppity, ksppstvl, ksppstdvl,

 20            ksppstdf, DECODE(BITAND(ksppiflg/ 256,1),1, 'TRUE','FALSE'),

 21            DECODE (BITAND (ksppiflg / 65536,3),

 22                    1, 'IMMEDIATE',

 23                    2, 'DEFERRED',

 24                    3, 'IMMEDIATE',

 25                    'FALSE'

 26                   ),

 27            DECODE (BITAND (ksppiflg,4),

 28                    4, 'FALSE',

 29                    DECODE (BITAND (ksppiflg / 65536,3),0, 'FALSE','TRUE')

 30                   ),

 31            DECODE (BITAND (ksppstvf,7),

 32                    1, 'MODIFIED',

 33                 4, 'SYSTEM_MOD',

 34                 'FALSE'

 35                ),

 36         DECODE (BITAND (ksppstvf,2),2, 'TRUE','FALSE'),

 37         DECODE (BITAND (ksppilrmflg / 64,1),1, 'TRUE','FALSE'), ksppdesc,

 38         ksppstcmnt, ksppihash

 39    FROM x$ksppi x, x$ksppcv y

 40   WHERE(x.indx= y.indx);

 

VIEW created.

 

轉載須註明出處

2014.04.14