ORA-8103 Troubleshooting, Diagnostic and Solution (文件 ID 8103.1)

APPLIES TO:

PURPOSE

This article provides information about error ORA-8103 and possible actions.

SCOPE

This note is intended for general audience as initial starting point for beginning diagnosis of ORA-8103.

DETAILS

Description

ORA-8103 is reporting that a SQL statement found a block that no longer belongs to the object referenced in the statement. 

Cause

ORA-8103 is caused by an invalid block type. The block header has an invalid block type or the block type inside the block is not expected; e.g. a data block (Type = 6) was expected but the actual block information is not a data block (Type != 6).

ORA-8103 is also caused by an unexpected data_object_id where it is concurrently changing for the involved object while the affected SQL statement is executed.

These two causes might be due to an expected behavior or other problems.  Details are:

Expected behavior.

Tables are being dropped/truncated while a SQL statement for those tables is still in execution. In the case of an index, it might be caused by an index rebuild. In other words the object has been deleted by another session since the operation began.

Look if dba_objects.data_object_id is changing for the affected object while queries are being executed.

data_object_id is changed by DDL statements like:

truncate table
alter index .. rebuild
alter table .. move
alter table .. exchange partition
alter table .. split partition
etc.

For a truncate look for column TRUNCATED in DBA_TAB_MODIFICATIONS. Note that it indicates whether the table has been truncated since the last analyze.  See documentation.

In 11g+ parameter enable_ddl_logging can be set to TRUE to print DDL statements in the alert log or in 12c in the log/ddl sub-directory of the ADR home (example /rdbms///log/ddl_$ORACLE_SID.log) and identify what DDL's are run that may potentially cause this error.

Block Corruption.

Hardware, IO subsystem or OS problems may cause block corruptions overwriting the Block Type in the block header causing the error ORA-8103. 

The block is healthy but it is an "OLD/STALE" block. These kind of corruptions might be caused by LOST IO/LOST WRITE or a bug in external non-oracle tools that migrate file systems while the database is OPEN.   In that case the data_object_id for the affected object could have changed but the actual block does not reflect it.

Note that the block may also be temporarily corrupted in the buffer cache (SGA Memory).

Overlapped Extents.

Overlapped Extents means that two or more segments incorrectly use the same block. This is a LMT Bitmap Extent inconsistency or Data Dictionary inconsistency.

To identify overlapped extents run the next checks:

For LMT (Locally Managed Tablespaces) run :

sqlplus / as sysdba

execute dbms_space_admin.tablespace_verify('&tablespace_name')
oradebug setmypid
oradebug tracefile_name

In 10gR2 and forward, for locally managed tablespaces using ASSM (DBA_TABLESPACES.SEGMENT_SPACE_MANAGEMENT=AUTO) run:

execute dbms_space_admin.assm_tablespace_verify('&tablespace_name',dbms_space_admin.TS_VERIFY_BITMAPS)
oradebug setmypid
oradebug tracefile_name

• Note that the session running dbms_space_admin does not say in the screen if an inconsistency is detected.  dbms_space_admin will generate a trace file instead.   So check if "oradebug tracefile_name" provides a trace file.
• If ORA-8103 is produced by tablespace_verify, it means that a block associated to the segment header is affected.  Identify the affected object as explained in the section below and drop it.  It may convert the segment to temporary which may need the usage of dbms_space_admin.segment_corrupt and dbms_space_admin.segment_drop to completely remove the segment. 

For Data Dictionary managed tablespaces run the hcheck script in: 

Note 136697.1 (it checks for overlapped extents through fet$/uet$).

Overlapped ASM extent.

If using ASM: overlapped ASM extents is when 2 different files and 2 different extents use the same Allocation Unit (AU) in the same ASM disk. 

From the ASM instance run:

SQL> alter diskgroup check all norepair;

In ASM alert log the next message is registered:

ERROR: file +data1.3551.721223631: F3551 PX3819 => D254 A78 => F3564 PX337: fnum mismatch

Meaning that ASM file number 3551 Physical Extent 3819 is using Allocation unit 78 in Disk 254 and at the same time ASM File Number 3564 has Physical Extent pointing to the same Allocation unit.

Oracle defect.

It can be an Oracle bug.  See section "known issues" below.

Identify the affected object

Sometimes the SQL statement producing the ORA-8103 involves several tables and the affected object can be an index.  Follow the next procedures to identify the affected object:

Get the SQL statement that is causing the error.

Reproduce the error from SQL*Plus if possible by running the affected SQL statement.

Identify the affected object in trace file section "dump suspect buffer".

In some cases when a trace file is generated, either by default with no error printed or by enabling the 8103 errorstack event mentioned later, there is a section "dump suspect buffer" that can be used to extract the object_id of the affected segment and query dba_objects to identify it. Example from a trace file:

  

: dump suspect buffer ...
buffer tsn: .....
....
BH (0x0000000449F392B8) file#: 51 rdba: 0x0ccb247d (51/730237) class: 1 ba: 0x0000000448ADE000
  set: 46 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,25
  dbwrid: 1 obj: 116770 objn: 76458 tsn: 14 afn: 51 ..

To identify the affected segment execute: select * from dba_objects where object_id = 76458;

 

Identify the affected object with ANALYZE.

Is it a TABLE or an INDEX causing the error?.  Exectute the analyze command and if there is an error, open the trace file as it may contain the suspect buffer:

For a TABLE run:

analyze table validate structure;

Alternatively  identify if a full table scan is producing the error.

For an INDEX run:

analyze index validate structure;

Identify the object with event 10236.

In 9.2.0.8 or above if ktrget is in the call stack trace for an ORA-8103, setting Event 10236 will include the block number in the trace file causing the error:

alter session set events '8103 trace name errorstack level 3';
alter session set events '10236 trace name context forever, level 1';
alter session set max_dump_file_size='UNLIMITED';
alter session set db_file_multiblock_read_count=1;
alter session set tracefile_identifier='ORA8103';

run the query that produces the error ORA-8103 and identify the trace with the form of _ora__ORA8103.trc

Open the trace file, it may have:

KTRVAC: path typ=22, rdba=32810e06
or
KTRVAC: path typ=0, rdba=32810e06
KTRGET: pobj=0, dsobj=882063, dsd=32810e06, sd=32010005

Meaning that the error is produced in rdba=0x32810e06

Convert that number to decimal and get the relative_fno, block#:

select dbms_utility.data_block_address_file(847318534) relative_fno
,dbms_utility.data_block_address_block(847318534) block#
from dual;

RELATIVE_FNO BLOCK#
------------ ----------
         202 69126

Then use Note 819533.1 to identify the object; section "Identify the Corrupt Object".

In some cases the event 10236 may produce the next information, meaning that the error is produced by rdba=0x1965ee16:

KTRVAC: obj=774488, seg. obj=798088, seg rdba=18454f9b
KTRGET: pobj=774488, dsobj=798088, dsd=1965ee16, sd=18454f9b

 

Identify the object with event 10200.

Event 10200 can be used to identify the last accessed block when this error is produced. event trace_buffer_on can be used to generate a smaller trace file.  Errorstack and event 10236 can be added to get a more complete trace file:

alter session set max_dump_file_size=unlimited;
alter session set db_file_multiblock_read_count=1;
alter session set events 'immediate trace name trace_buffer_on level 1048576';
alter session set events '10200 trace name context forever, level 1';
alter session set events '8103 trace name errorstack level 3';
alter session set events '10236 trace name context forever, level 1';
alter session set tracefile_identifier='ORA8103';

run the query that produces the error ORA-8103

alter session set events 'immediate trace name trace_buffer_off';
exit

Identify the trace with the form of _ora__ORA8103.trc

In the trace file generated locate last information about:

"Consistent read started for block : "

where XXX is the tablespace number and YYY is the rdba for that block.  Normally this is the affected block.

Trace output example:

*** 2004-01-28 09:40:16.000
*** SESSION ID:(9.5) 2004-01-28 09:40:16.000
Consistent read started for block 0 : 00405302
env: (scn: 0x0000.001a9434 xid: 0x0000.000.00000000 uba: 0x00000000.0000.00 statement num=0 parent xid: xid: 0x0000.000.00000000 scn: 0x0000.00000000 0sch: scn: 0x0000.00000000)
CR exa ret 9 on: 01FEE950 scn: 0xffff.ffffffff xid: 0x0000.000.00000000 uba: 0x00000000.0000.00 scn: 0xffff.ffffffff sfl: 0
Consistent read finished for block 0 : 405302
Consistent read finished for block 0 : 405302
Consistent read started for block 0 : 00405303

The error is produced while reading rdba=0x00405303 (File=1,Block=21251) as there is NOT a message like:
"Consistent read finished for block 0 : 00405303"

Then use Note 819533.1 to identify the object; section "Identify the Corrupt Object".

Identify object affected by Block Corruption.

Use DBVerify or RMAN to identify corrupted blocks associated to the datafiles where the object is stored. 

A common corruption is when the block has been zeroed out (block type is also zero). DBVerify reports it as:

Completely zero block found during dbv

Use sections "DBVerify - Identify Datafile Block Corruptions" or "RMAN - Identify Datafile Block Corruptions" in Note 836658.1 and Note 819533.1 to identify the affected object.

Identify object affected by Overlapped Extents.

If overlapped extents in Locally Managed Tablespace is identified, use Note 887263.1 to identify the segments involved.

ORA-8103 in XML objects

XDB status may be INVALID in DBA_registry or it could be due to XDB metadata corruption. Check Doc ID 1553078.1 for reference; although it mentions an ORA-1410 the treatment is the same.   Contact Oracle XDB support for futher information.

Observations

• Setting event "8103 trace name errorstack level .." will report all the ORA-8103 errors produced in the database; it will also include those cases where the error is internally handled by the Oracle rdbms. This may give the false impression of an issue; there are cases where the error is handled internally by Oracle and the server process will not report the error to the user even though there is a trace reported for the ORA-8103.  If the error is not reported to the application then the error should not be a concern.

Solution

Fix Block Corruption.

If error ORA-8103 is constantly reproduced by ANALYZE and if it has been determined that it is not the expected behavior, then it means that there is a possible block corruption. The possible solutions are:

Flush the buffer cache.

It might be a corruption only in the SGA memory (Buffer cache):

alter session set events 'immediate trace name flush_cache level 1';

In a RAC system, flushing the buffer cache may be needed in the additional rac instances.

If error persists, continue with the next steps:

Flush the shared pool.

In some cases the problem can be caused by an cursor invalidation problem for which flushing the shared_pool can be a workaround:

alter system flush shared_pool;

 If error still persists, then it could be a permanent problem present on disk.  Continue with next steps:

Index Corruption.

Drop and recreate the index.

Table Corruption.

1. Consider to apply media recovery if it is determined that the problem was caused by a corrupt block (Like zeroed out blocks). RMAN BLOCKRECOVER can be used to repair a zeroed out block. 

2. TRUNCATE or DROP it and reload the data from export dump. If the the same error is produced by dropping/truncating a PARTITION, then consider to EXCHANGE:

alter table . exchange partition with table .;

Note: has to have the same structure as .

3. If recover from a backup is not an option, table data can be saved skipping the blocks that are causing the ORA-8103 error:

OPTION 1 - No backup

If the table has an index use the plsql script provided in Note  1527738.1

OPTION 2 - No backup

If the table does not have an index, use script provided in Note 422547.1

Another solution is to determine if dbms_repair can be used to skip these blocks or if procedure described in Note 61685.1 can be used to skip corrupted blocks using rowid scans.

Temporary Segment Corruption

If it is identified that the ORA-8103 is caused by a temporary segment, use dbms_space_admin to drop the temporary segment and rebuild the tablespace bitmap:

sqlplus / as sysdba

execute dbms_space_admin.segment_corrupt('&tablespace_name',&relative_fno,&block_number)
execute dbms_space_admin.segment_drop_corrupt('&tablespace_name',&relative_fno,&block_number)
execute dbms_space_admin.tablespace_rebuild_bitmaps('&tablespace_name')

Fix Overlapped Extents.

If the error is caused by Overlapped extents in a LOCALLY MANAGED Tablespace (LMT):

• Drop one of the affected objects. If the segment is converted to temporary then use dbms_space_admin.segment_corrupt and dbms_space_admin.segment_drop to remove the segment.
• Make sure that there are not more overlap extents by running dbms_space_admin.assm_tablespace_verify or dbms_space_admin.tablespace_verify
• Fix the overlap inconsistency by running dbms_space_admin.tablespace_rebuild_bitmaps.   Note that it will not fix the current affected blocks producing ORA-8103.

For a DICTIONARY MANAGED tablespace determine if the database has to be recreated.

You can restrict the list below to issues likely to affect one of the following versions by clicking the relevant button: 
                

NB	Prob	Bug	Fixed	Description
	II	26203182	18.1	Lost Writes on ZFS if DNFS is enabled causing several Internal Errors. ORA-600 [kdsgrp1] ORA-8103 ORA-600 [3020] ORA-752 ORA-756
	II	25768681	18.1	Corrupt block message in alert log when re-read disk block for logical corruption like ORA-1410 / ORA-8103
	IIII	18259031	11.2.0.4.170718, 12.1.0.2, 12.2.0.1	ORA-600 [...:objdchk_kcbnew_3] or ORA-8103 with concurrent DROP / SELECT of ASSM segment
	II	18240704	12.1.0.2, 12.2.0.1	ORA-8103 during upgrade on ALTER TABLE kottd$ MOVE LOB
	IIII	17480600	12.1.0.2, 12.2.0.1	ORA-8103 / ORA-600 [ktsfbfmt:objdchk_kcbnew_3] after ALTER INDEX on AQ$_QT_I/T
	I	16862882	12.1.0.2
	II	24668398	18.1	ORA-8103 on EHCC Compress Table in Exadata after Parallel Direct Path Load
	I	22821472	18.1	ORA-8103 when revoking DBA privileges
	III	23315889	11.2.0.4.171017, 12.1.0.2.171017, 12.2.0.1	New Datafile is not Encrypted After Offline Tablespace Encryption with compatibility of 11.2
	III	22575209	12.2.0.1	ORA-600 [kdsgrp1] ORA-600 [25027] ORA-8103 ORA-3254 in ADG Standby Database for Full Scan on ASSM segment - superseded
	II	22519146	12.1.0.2.171017, 12.2.0.1	ORA-600 [kdsgrp1] or ORA-600 [kdsgrpcalcblockcount: hwmbno<=dbabno] or ORA-8103 in 12c on HCC Table in EXADATA
	III	22365117	12.1.0.2.170117, 12.2.0.1	Wrong Results / ORA-7445 from Query with Table Function
	IIII	21960504	12.1.0.2.161018, 12.2.0.1	ORA-8103 in 12c by Direct Read in after block format during concurrent Inserts and/or Updates
	II	21899588	12.1.0.2.160419, 12.2.0.1	Correct corrupt block 8103 reports from kcbzibmlt
	III	21896069	12.1.0.2.170117, 12.2.0.1	ORA-8103 in 12c EXADATA on Compressed HCC Tables stored in Bigfile Tablespaces
	II	21813529	12.1.0.2.DBBP13, 12.2.0.1	ORA-8103 in 12c by Direct Read after block format during concurrent Inserts. No TRUNCATE / DDLs are being executed - Superseded
	IIII	21752827	12.2.0.1	ORA-600 [kkpamrefget: bad objd] ORA-600 [12406] ORA-600 [25027] ORA-8103 ORA-1499 in Partition Tables after DDL maintenance
	IIII	21246723	12.1.0.2.160719, 12.2.0.1	ORA-8103 during DIRECT PATH reads. No TRUNCATE / DDLs are being executed
	II	20860659	11.2.0.4.180116, 12.1.0.2.171017, 12.2.0.1	ORA-600 [kdilroot_undoable: emptyleaf] or ORA-8103 from SQL*Loader loading an Interval Partitioned Table
	III	20798891	12.1.0.2.160719, 12.2.0.1	ORA-8103 in 12c during reads for a "block typ=58" while there are concurrent INSERTs. No TRUNCATE / DDLs are being executed
	II	20708701	12.1.0.2.160719, 12.2.0.1	ORA-8103 on Query for an EHCC Table in a Bigfile Tablespace in EXADATA
	IIII	19689979	11.2.0.4.170718, 12.1.0.2.160119, 12.1.0.2.DBBP07, 12.2.0.1	ORA-8103 or ORA-600 [ktecgsc:kcbz_objdchk] or Wrong Results on PARTITION table after TRUNCATE in 11.2.0.4 or above
	IIII	19614585	11.2.0.4.BP17, 12.1.0.2.DBBP03, 12.2.0.1	Wrong Results / ORA-600 [kksgaGetNoAlloc_Int0] / ORA-600 [12406] / ORA-7445 / ORA-8103 / ORA-1555 from query on RAC ADG Physical Standby Database
	II	19302393	12.1.0.2.DBBP01, 12.2.0.1	ORA-600 [25027] or ORA-8103 by IM Scan
	II	19192600	12.1.0.2.DBBP01, 12.2.0.1	ORA-8103 from IM (inmemory) populate
	III	18284763	11.2.0.4.BP13, 12.1.0.2, 12.2.0.1	ORA-600 [3020] on ASSM blocks in Standby Database after CONVERT TO PHYSICAL or ORA-8103 ORA-600 [4552] in non-standby after FLASHBACK
	II	15996357	11.2.0.4, 12.1.0.2, 12.2.0.1	ORA-8103 when revoking DBA privileges
	I	13029141	12.1.0.2, 12.2.0.1	Intermittent ORA-8103 While Select Securefile LOB Columns
	-	21266182	12.1.0.2	ORA-600 [25027] ORA-8103 ORA-8102 ORA-1499 after TTS of Unusable Index
	III	13785734	11.2.0.4, 12.1.0.0	ORA-8103 or similar from queries on PARTITION table in ADG Standby Database - superseded
	III	25330273	12.1.0.2.170418	Fix for Missing Bug 21960504 Changes in October 2016 and January 2017 Patch Set Updates and Bundled Patches - ORA-8103 by Direct Read in after block format during concurrent DML
	II	18441511	12.1.0.2, 12.2.0.1	ORA-600 [25027] / ORA-8103 / ORA-600 [ktrget2:clschk_kcbgtcr_12] by a query on a compress EHCC Table in 12c bigfile ASSM Tablespace
	II	17204397	12.1.0.2, 12.2.0.1	ORA-8005 ORA-8103 ORA-1410 ORA-600 [kdsgrp1] on Bitmap Index. Root Block may be repeatedly pinned/unpinned
	II	16844448	11.2.0.3.9, 11.2.0.3.BP22, 11.2.0.4, 12.1.0.2	ORA-600 [3020] after flashback database in a RAC
	III	15969429	11.2.0.4, 12.1.0.1	Wrong Results / ORA-600 [qesmagettblseg1] / ORA-8103 at physical standby with fix for bug 13536971 - superseded
	II	13910420	11.2.0.3.6, 11.2.0.3.BP09, 11.2.0.4, 12.1.0.1	ORA-8103 during insert / update of basicfile LOB in assm segment using space search cache
	III	13725395	11.2.0.3.8, 11.2.0.3.BP07, 11.2.0.4, 12.1.0.1	ORA-600 [kdzhFindHeadPiece: unnewed > 1] from load into HCC table
	II	13700577	11.2.0.3.BP07, 11.2.0.4, 12.1.0.1	PQ slave dies with ORA-600 [kdblddr_2]
	III	12940620	11.2.0.3.7, 11.2.0.3.BP14, 11.2.0.4, 12.1.0.1	Cached block/extent counts in SEG$ not updated after ADD extent
	II	12821418	11.2.0.3.8, 11.2.0.3.BP18, 11.2.0.4, 12.1.0.1	Direct NFS appears to be sending zero length windows to storage device. It may also cause Lost Writes
	IIII	12747437	11.2.0.3.8, 11.2.0.3.BP21, 11.2.0.4, 12.1.0.1	ORA-600 [ktspfmdb:objdchk_kcbnew_3] after purging single consumer queue table
	I	12582839	11.2.0.3, 12.1.0.1	ORA-8103/ORA-600 [3020] on RMAN recovered locally managed tablespace
P	I	12330911	12.1.0.1	EXADATA LSI firmware for lost writes
	II	12321309	11.2.0.4, 12.1.0.1	ORA-600 / ORA-8103 UNUSABLE state of partitioned index is not carried across by TABLESPACE transport using DataPump
	II	11937253	11.2.0.2.6, 11.2.0.2.BP11, 11.2.0.3, 12.1.0.1	A Parallel query fails with ORA-8103 on an Active Dataguard Enviroment.
	II	11850492	11.2.0.3, 12.1.0.1	ORA-8103 ORA-600 ORA-3113 on temporary tables using INDEX FAST FULL SCAN and DIRECT read
	III	10385812	11.2.0.2.BP20, 11.2.0.3, 12.1.0.1	ORA-1410 or ORA-8103 by queries with DIRECT READ while concurrent DIRECT INSERT
	I	10329146	11.2.0.1.BP10, 11.2.0.2.2, 11.2.0.2.BP03, 11.2.0.2.GIBUNDLE02, 11.2.0.2.GIPSU02, 11.2.0.3, 12.1.0.1	Lost write in ASM with multiple DBWs and a disk is offlined and then onlined
+	III	10209232	11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2.1, 11.2.0.2.BP02, 11.2.0.2.GIBUNDLE01, 11.2.0.3, 12.1.0.1	ORA-1578 / ORA-600 [3020] Corruption. Misplaced Blocks and Lost Write in ASM
*	III	10205230	11.2.0.1.6, 11.2.0.1.BP09, 11.2.0.2.2, 11.2.0.2.BP04, 11.2.0.3, 12.1.0.1	ORA-600 / corruption possible during shutdown in RAC
	II	10136415	11.2.0.3, 12.1.0.1	ORA-8103 on Partitioned IOT after partition maintenance
	II	10064796	12.1.0.1	ORA-8176 / ORA-8102 ORA-1499 ORA-8103 Row Inserted in a Wrong Partition with PARTITION BY REFERENCE
	II	10026972	11.2.0.2.BP02, 11.2.0.3, 12.1.0.1	Intermittent Wrong results from Parallel Query with chained rows in RAC
	I	9965085	11.2.0.3, 12.1.0.1	ORA-1578 / ORA-8103 Temporary table block corruption / space wastage from PDML - superseded
	II	9659614	10.2.0.5.3, 11.2.0.3.5, 11.2.0.3.BP05, 11.2.0.4, 12.1.0.1	Large trace file for ORA-8103
	IIII	9651350	11.2.0.2.2, 11.2.0.2.BP05, 11.2.0.3, 12.1.0.1	Large redo dump and ORA-308 might be raised due to ORA-8103
	III	9275027	11.2.0.2, 12.1.0.1	ORA-600 [kcbnew_3] can occur after TRUNCATE / DROP
	II	9272086	11.1.0.7.4, 11.2.0.1.2, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.1	ORA-8103 by a query on DBA_EXTENTS. Trace file with Block type: 0x44=NGLOB: Extent Map
	I	8754670	11.2.0.2, 12.1.0.1	IMP-17 / ORA-8103 transporting a large dictionary managed tablespace
	III	8740993	11.1.0.7.8, 11.2.0.2, 12.1.0.1	ORA-1410 / ORA-8103 on ADG STANDBY during table scan after DROP/TRUNCATE/SHRINK in PRIMARY
	II	8725282	11.2.0.1.BP08, 11.2.0.2, 12.1.0.1	Corruption from cross platform transport of tablespace with securefile objects
	II	8716064	11.2.0.2, 12.1.0.1	Analyze Table Validate Structure fails on ADG standby with several errors
+	II	8597106	11.2.0.1.BP06, 11.2.0.2, 12.1.0.1	Lost Write in ASM when normal redundancy is used
	II	8428523	11.2.0.2, 12.1.0.1	Alter Table Rename causes wrong results/ora-8103/hangs on ADG Standby.
	II	7710827	11.2.0.2, 12.1.0.1	Index rebuild or Merge partition causes wrong results in concurrent reads instead of ORA-8103
	II	7519406	10.2.0.5.1, 11.2.0.1.2, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.1	Larger trace than needed for ORA-8103 under kteinicnt1
	II	8876094	11.1.0.7.2, 11.2.0.2	ORA-8103 by DBA_UNDO_EXTENTS or DBMS_SPACE_ADMIN.TABLESPACE_VERIFY on Block type: 0x25
	I	9167831	11.2.0.2	ORA-8103 instead of ORA-1410
	III	7650993	11.1.0.7.1, 11.2.0.1	ORA-8103 in a select at ADG standby database from table stored in ASSM tablespace
	II	7432556	11.1.0.7.1, 11.2.0.1	ORA-8103 by Parallel Query on Partitioned Tables in BIGFILE Tablespaces
	-	7390324	11.2.0.1	ANALYZE signals OERI [kcbgtcr_12]/ORA-8103 on bitmap index
	II	7117200	11.2.0.1	ORA-8103 after TSPITR/PLUGIN tablespace from a restored Level 1 Backup
E	II	8825048	11.1.0.7.3	ORA-308/ORA-27037 when dumping archived log for ORA-8103. Dump when event 10736 level 4 is set
	II	6337376	11.1.0.7	OERI:kcbgcur_3 / ORA-8103 after truncating a partition table with LOBs
	I	9711472	11.1.0.6	ORA-8103 on operations for a partitioned LOB if any different partition is dropped
	I	5637976	10.2.0.4, 11.1.0.6	ORA-8103/ORA-1410 from concurrent INSERT / export on ASSM tables
	II	5083393	10.2.0.4, 11.1.0.6	DBA_FREE_SPACE FILE_ID / REL_FNO may be wrong
	II	4592596	10.2.0.4, 11.1.0.6	Corruption (ORA-1410 / ORA-8103) from multi-table insert with direct load
	II	6864586	10.2.0.5	ORA-8103 on partitioned table with a LOB column during analyze table with concurrent add/drop partition.
	I	3569503	9.2.0.6, 10.2.0.4	PQ may signal a false ORA-8103 under load
	II	13618170		ORA-8103 for create index online when the fix of bug 10027403 is installed
	I	3966709	9.2.0.7, 10.1.0.4, 10.2.0.1	Range/object reuse prematurely (ORA-8103)
	I	3868753	9.2.0.7, 10.1.0.5, 10.2.0.1	Concurrent export / INSERT of ASSM segment can fail with ORA-1410 / ORA-8103
+	III	5523799		Various OERI (eg kcbgtcr_12) using ASSM managed segments - superceded
P*	III	6047085		Linux x64-64: SGA corruption / crash following any ORA-7445
*	I	3785200	10.1.0.2, 9.2.0.6	Corruption possible in automatic space managed segments
	-	3083560	9.2.0.5, 10.1.0.2	ORA-1410 / ORA-8103 from direct path export if concurrent DML occurs
	-	2619867	9.2.0.3, 10.1.0.2	OERI:[KCBGTCR_12] / ORA-8103 / ORA-1410 SELECTing from bitmap managed segment
	-	2551000	10.1.0.2, 9.2.0.4	False ORA-1410 / ORA-8103 possible from ANALYZE COMPUTE/ESTIMATE STATISTICS
	-	2333731	9.2.0.2	ORA-8103 possible in PQ slave
	-	2105419	9.0.1.3, 9.2.0.1	ORA-8103 possible from PQ on bitmap managed segments with concurrent inserts
	-	1998455	8.1.7.3, 9.0.1.3, 9.2.0.1	OERI:KCBGTCR_4 possible from long running DDL if referenced object dropped/truncated
	-	1804299	9.0.1.1, 9.2.0.1	Rollback of Direct load can corrupt BITMAP managed segments / ORA-8103
	-	1698789	9.2.0.1	Wrong results, ORA-1410, ORA-8103, OERI:25012 on SELECT of UNSCOPED REF with ROWID
	-	1504967	9.2.0.1	ORA-8103 possible on READ ONLY standby after TRUNCATE on primary
	-	1400739	8.1.7.1, 9.0.1.0	Block corruption/OERI:2023 /ORA-8103 can occur if TRUNCATE is interrupted (Ctrl-C)
	-	1283521	8.1.7.0	ORA-8103 can occur on TRUNCATED cluster table
	-	589855	7.3.3.6, 7.3.4.1	ORA:1578 or ORA:8103 selecting invalid ROWID
P	-	1053863	8.0.5.2, 8.0.6.2	NCR: ORA-8103 / corrupt read possible using async IO