Wednesday, June 19, 2013

ORA-8102 - Traces generated with no error in alert.log, OER 8102 reported in the trace

In alert log appears the message that a trace file was created, but no oracle error was reported:

bash-3.2$ less alert_db11.log

Wed Jun 19 10:00:38 2013
Errors in file /u02/app/oracle/diag/rdbms/db11/db11/trace/db11_j000_24568.trc:
Wed Jun 19 10:00:42 2013
Dumping diagnostic data in directory=[cdmp_20130619100042], requested by (instance=1, osid=24568 (J000)), summary=[abnormal process termination].

In trace file following error appears:

bash-3.2$ less /u02/app/oracle/diag/rdbms/db11/db11/trace/db11_j000_24568.trc

oer 8102.2 - obj# 70688, rdba: 0x0081a2ea(afn 2, blk# 107242)
kdk key 8102.2:
  ncol: 4, len: 64
....

Details for ORA-8102:

Error: ORA-08102 (ORA-8102)
Text: 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

Bellow there is also the current sql running:

dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=3, mask=0x0)
----- Error Stack Dump -----
----- Current SQL Statement for this session (sql_id=11p815z8hkfms) -----
DELETE MGMT_SYSTEM_PERFORMANCE_LOG WHERE TIME < :B2 AND ROWNUM <= :B1
----- PL/SQL Stack -----
----- PL/SQL Call Stack -----
  object      line  object
  handle    number  name

The recommendation from Oracle support is to rebuild indexes for affected tables.

Select affected index:

SELECT *
FROM   dba_objects
WHERE  object_id = 70688;

MGMT_SYSTEM_PERF_LOG_IDX_01

If there is an inconsistency between table and index, the next analyze command produces an error ORA-01499:

ANALYZE TABLE MGMT_SYSTEM_PERFORMANCE_LOG VALIDATE STRUCTURE CASCADE;


ORA-01499: table/index cross reference failure - see trace file


bash-3.2$ less db11_ora_25102.trc
....
row not found in index tsn: 1 rdba: 0x00809d52
env [0xfffffd7fffde70a0]: (scn: 0x0857.ee95b7d8  xid: 0x00a6.011.00000198  uba: 0x00000000.0000.00  statement num=0  parent xid
: 0x0000.000.00000000  st-scn: 0x0000.00000000  hi-scn: 0x0000.00000000  ma-scn: 0x0857.ee95b7c3  flg: 0x00000060)
col 0; len 36; (36):
 4d 47 4d 54 5f 43 4f 4c 4c 45 43 54 49 4f 4e 2e 43 6f 6c 6c 65 63 74 69 6f
 6e 20 53 75 62 73 79 73 74 65 6d
col 1; len 7; (7):  78 71 06 0e 10 0d 02
col 2; len 11; (11):  43 6f 6c 6c 65 63 74 69 6f 6e 73
col 3; len 6; (6):  00 81 01 ed 00 32
Block header dump:  0x008101ed
 Object id on Block? Y
 seg/obj: 0x11190  csc: 0x857.ee8b62d4  itc: 2  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x8101e8 ver: 0x01 opc: 0
     inc: 0  exflg: 0
....
kdgDumpRedo: dump redo on table/index mismatch:
             table block tsn=1 rdba=0x008101ed index objn=70688
             head rowid 0x008101ed.0032

Detect if the corruption is at table or at index level:

ANALYZE TABLE MGMT_SYSTEM_PERFORMANCE_LOG VALIDATE STRUCTURE;
ANALYZE INDEX MGMT_SYSTEM_PERF_LOG_IDX_01 VALIDATE STRUCTURE;

Recreate index:

DROP INDEX SYSMAN.MGMT_SYSTEM_PERF_LOG_IDX_01;

CREATE INDEX SYSMAN.MGMT_SYSTEM_PERF_LOG_IDX_01 ON SYSMAN.MGMT_SYSTEM_PERFORMANCE_LOG
(JOB_NAME, TIME, NAME)
LOGGING
TABLESPACE SYSAUX;

Now, analyzing table with cascade options give no errors:

ANALYZE TABLE MGMT_SYSTEM_PERFORMANCE_LOG VALIDATE STRUCTURE CASCADE;

No errors are reported in alert log, no trace file are created.

1 comment:

  1. Really It was nice trick to analyze and thanks a lot for resolving this error or suggestion.

    ReplyDelete