ORA-08103: object no longer exists tips Oracle Error Tips by Stephanie F.

 

The Oracle docs note this on the ora-08103 error:

 

Internet sources show that there are many bugs associated with ORA-08103.  A description of the error per the documents is as follows:

This error can occur, if the header block has an invalid block type or data_object_id (seg/obj) stored in the block is different than the data_object_id stored in the segment header. This error can be treated as a block corruption.

Below are the twelve bugs which contain ORA-08103 in Oracle Enterprise Edition; versions 8.1 to 10.2

• Bug 2551000
  Abstract: False ORA-1410 / ORA-8103 possible from ANALYZE COMPUTE/ESTIMATE STATISTICS
  Versions affected: 8.1.7.4 & 9.2.0.3
  Fixed in version: 8.1.7.5, 9.2.0.4 & 10.0
  Symptoms:
  To be seeing this problem the following must be true :
  1) ANALYZE fails with an Ora-1403 or Ora-8103
  2) The object being analyzed has a large number of extents
  3) The analyze object has chained or migrated rows
  4) Setting db_file_multiblock_read_count to 1 resolves the problem.
  Details:
  ANALYZE may report a false ORA-1410 or ORA-8103 for objects with migrated/chained rows.
  Workaround:
  Set db_file_multiblock_read_count=1
  Patch details:
  One-off patch available for few platforms on top of 8.1.7.3, 8.1.7.4, 9.0.1.3 & 9.2.0.3
  Check the MOSC for Patch 2551000 availability.

 

• Bug 2105419 (Unpublished)
  Abstract: ORA-8103 possible from PQ on bitmap managed segments with concurrent inserts
  Versions affected: 9.0.1.2
  Fixed in version: 9.0.1.3 & 9.2.0.1
  Symptoms:
  Concurrent insert against the bitmap managed segments can lead ORA-08103 error from PQ process.
  Details:
  ORA-8103 possible from PQ on bitmap managed segments with concurrent inserts.
  Workaround:
  None
  Patch details:
  Fix included in Base version of 9.2 RDBMS version and no one-off patch available for lower versions.

 

• Bug 1504967
  Abstract: ORA-8103 possible on READ ONLY standby after TRUNCATE on primary
  Versions affected: 8.1.6
  Fixed in version: 9.2.0
  Symptoms:
  Stale data(ora-8103) on a standby database after recovery is applied to a open read only standby.
  Details:
  TRUNCATE on the primary may lead to ORA-8103 on the standby if it is opened read only
  Workaround:
  None
  Patch details:
  Fix included in Base version of 9.2 RDBMS version and no one-off patch available for lower versions .

 

• Bug 2333731 (Unpublished)
  Abstract: ORA-8103 possible in PQ slave
  Versions affected: 9.2.0.1
  Fixed in version: 9.2.0.2
  Symptoms
  If the application uses pq slave and there is ORA-8103 due to unflushed buffers, then the database is hitting this bug.
  Details:
  PQ slave may get ORA-8103 error
  Workaround:
  None
  Patch details:
  No one-off patch available for this bug

 

• Bug 2619867
  Abstract:OERI:[KCBGTCR_12] / ORA-8103 / ORA-1410 SELECTing from bitmap managedBug 2619867
  Abstract:OERI:[KCBGTCR_12] / ORA-8103 / ORA-1410 SELECTing from bitmap managed segment
  Versions affected: 9.2.0.2
  Fixed in version: 9.2.0.3 & 10.0
  Symptoms:
  A select from a table may fail with one of these errors
  ORA-08103 or ORA-00600 [kcbgtcr_12] or ORA-01410
  Details:
  With a local-managed tablespace and auto-managed segment, a select from a table may fail with one of these errors:
  1) ORA-08103: object no longer exists
  2) ORA-00600: internal error code, arguments: [kcbgtcr_12], [1]
  3) ORA-01410: invalid ROWID
  Workaround:
  Do not use the combination of local-managed tablespace and auto-managed segments
  Patch details:
  One-off patch available for few platforms on top of 9.0.1.4 & 9.2.0.2
  Check the MOSC for Patch 2619867 availability.

 

• Bug 3083560
  Abstract:ORA-1410 / ORA-8103 from direct path export if concurrent DML occurs
  Versions affected: 8.1.7.4 & 9.2.0.4
  Fixed in version: 9.2.0.5 & 10.1
  Symptoms:
  If the following conditions are met, then the database is hitting this bug
  1) Direct exoprt gets ORA-8103 or ORA-1410
  2) The table data is updated by the other process.
  Details:
  While exporting a table in direct mode, the export process could get ORA-1410 or ORA-8103 if another other session inserts/updates the table.
  Workaround:
  Use conventional export
  or
  Don't access the table during export
  Patch details:
  One-off patch available for few platforms on top of 8.1.7.4 & 9.2.0.4
  Check the MOSC for Patch 3083560 availability.

 

• Bug 3569503
  Abstract: PQ may signal a false ORA-8103 under load
  Versions affected: 9.2.0.5
  Fixed in version: 9.2.0.6, 10.1.0.6, 10.2.0.4 & 11.1
  Symptoms:
  PQ slaves sporadically raise ORA-8103 for a block that was read direct (ie. bypassing the buffer cache) from disk.
  To find the block,look for "last wait for 'direct path read'" in the trace. Example:
  last wait for 'direct path read' blocking sess=0x0 seq=14300 wait_time=20
  ----> file number=28b, first dba=166fb9, block cnt=10
  Details:
  Under heavy load, parallel query slaves could raise a false ORA-8103 (object does not exist) error giving a false indication of a corruption.
  Workaround:
  None
  Patch details:
  One-off patch available for few platforms on top of 9.2.0.5 & 10.2.0.3
  Check the MOSC for Patch 3569503 availability.

 

• Bug 3966709 (Unpublished)
  Abstract: Range/object reuse prematurely (ORA-8103)
  Versions affected: 9.2.0.5 & 10.1.0.3
  Fixed in version: 9.2.0.7, 10.1.0.4 & 10.2
  Symptoms:
  One symptom of this bug was ORA-1803 (object no longer exists) during CTAS. The re-use range call completed and the block was reused but there was still a buffer on the reuse-write list that needed to be written to disk. Because the re-use call had completed, the block was re-used for another object. When the buffer on the list was eventually written to disk, it was for the old version of the block and when the pq slave did a direct read during CTAS, it detected this and raised ORA-8103.
  Details:
  When a block in the database is reused for a different object it is possible for the block to be re-used before all blocks referencing the old object id / range have completed their use. This can lead to ORA-8103 type errors during CREATE TABLE as SELECT type operations.
  Workaround:
  None
  Patch details:
  One-off patch available for few platforms on top of 9.2.0.4, 9.2.0.5 & 9.2.0.6
  Check the MOSC for Patch 3966709 availability.

 

• Bug 3868753
  Abstract: Concurrent export / INSERT of ASSM segment can fail with ORA-1410 / ORA-8103
  Versions affected: 9.2.0.5 & 9.2.0.6
  Fixed in version: 9.2.0.7, 10.1.0.5 & 10.2
  Symptoms:
  Concurrent inserts and exports on ASSM bles may generate ORA-8103/ORA-1410 errors.
  Details:
  Concurrent INSERTS and direct path EXPORT against ASSM tables can fail with ORA-8103 and ORA-1410 errors.
  Workaround:
  Do not use direct path EXPORT against ASSM tables
  Patch details:
  One-off patch available for few platforms on top of 9.2.0.5, 9.2.0.6 & 10.1.0.3, 10.1.0.4
  Check the MOSC for Patch 3868753 availability.

 

• Bug 4925342 (Unpublished)
  Abstract:OERI [25027] / OERI [25012] on IOT analyze estimate statistics
  Versions affected: 9.2.0.6, 9.2.0.7 & 10.1.0.5, 10.2.0.2
  Fixed in version: 9.2.0.8, 10.1.0.6, 10.2.0.3 & 11.0
  Symptoms:
  ORA-600 [25027] or ORA-600 [25012] or (very rarely) ORA-8103 during an "analyze table <iot> estimate statistics sample ..." for an IOT that is almost empty and was subsequently coalesced.
  Details:
  Sampling analyze of sparely populated IOT (or AQ queue tables that have been almost completely drained) can lead to internal errors such as ORA-600 [25027] or ORA-600 [25012].
  Workaround:
  Rebuild the underlying tables (alter table <iot> move), or use a "compute statistics" analyze rather than an "estimate statistics" analyze.
  Patch details:
  One-off patch available for few platforms on top of 9.2.0.6 & 9.2.0.7
  Check the MOSC for Patch 4925342 availability.

 

• Bug 5523799
  Abstract: Various OERI (eg kcbgtcr_12) using ASSM managed segments
  Versions affected: 9.2.0.8 & 10.1.0.5
  Fixed in version: 10.1.0.6
  Symptoms:
  Operations such as TRUNCATE on ASSM segments can lead to subsequent ORA-600 kcb* errors such as ORA-600 [kcbnew_3], ORA-600 [kcbgtcr_3], ORA-600 [kcbgtcr_12]
  Details:
  This problem is introduced in the 9.2.0.8 and 10.1.0.5 patch sets by the fix for bug 3279497
  Operations such as TRUNCATE on ASSM segments can lead to subsequent ORA-600 kcb* errors such as ORA-600 [kcbnew_3], ORA-600 [kcbgtcr_3], ORA-600 [kcbgtcr_12] .
  Workaround:
  Avoid TRUNCATE operations on ASSM managed segments, or use TRUNCATE with a KEEP STORAGE option. Once the issue has occurred then the problem is that there is a CURRENT block image in the cache which should not be there. In 10g flush the buffer cache to remove the problem block image/s from the cache. (In 9.2 there is no SQL to flush the buffer cache)
  Patch details:
  One-off patch available for few platforms on top of 9.2.0.8 & 10.1.0.5
  Check the MOSC for Patch 5523799 availability.

 

• Bug 5637976
  Abstract: ORA-8103 EVEN WITH THE WORKAROUND FROM Bug 3569503
  Versions affected: 10.2.0.2
  Fixed in version: 11.1
  Symptoms:
  1) Concurrent inserts and exports on ASSM tables
  2) ORA-8103/ORA-1410
  3) Redo dump shows 'ktspbfredo - Format Pagetable Datablock' for that rdba
  Details:
  Concurrent inserts and exports on ASSM tables can lead ORA-08103 error
  Workaround:
  None
  Patch details:
  One-off patch available for few platforms on top of 10.2.0.3
  Check the MOSC for Patch 5637976 availability.