ORA-08103: object no longer exists 及 ora-00600 [2032]

Oracle 9.2.0.8   ,  RAC ,   2 Nodes,  x86-64bit  . 

 

透過trace檔案中的ORA-07445: exception encountered: core dump [pfrrun()+785]
[SIGSEGV] [Address not mapped  在oracle metalink針對9208版本查詢不到相關bug
資訊 。

下面是查詢 ORA-08103: object no longer exists 得出的一些資訊 。

symptom: Error performing a SELECT statement
symptom: ORA-08103: object no longer exists
symptom: Table is being truncated by other session
symptom: Analyze table validate structure cascade returns no errors

cause:
   This ORA-08103 occurs on the next block read after the truncate command.

The LOCK TABLE IN EXCLUSIVE MODE does not prevent the table from being
SELECTED from. Thus, when the query has started and while this query runs
and the truncate occurs, this ORA-08103 may surface on the next block read.
This is considered intended behavior.

When a TRUNCATE occurs the DATAOBJ# in OBJ$ gets increased by one and thus
may lead to this ORA-08103 'object no longer exists'

fix:
Possible solutions are:
- Use DELETE instead of TRUNCATE
- Use SELECT FOR UPDATE as this will try to lock the table

 

檢查及確認(1,2最好在非生產階段作業) :

1. analyze table  table_name  validate structure ; (正在操作而報錯的table)
2. $ dbv  file=xxxxx.dbf  blocksize=8192  feedback=200  (可能壞塊檢查)
3. 報錯時操作的這個表是否是臨時表
4. 是否是物化檢視(mv,因為全重新整理時會truncate表)
5. 是否是檢視(view), 檢視的基表被修改或刪除可能報錯
6. 是否有人為truncate這個正在被操作的表
7. 針對出現錯誤時操作的表，是否有大量併發的update或其他操作。

 

 

alert log 檔案中還有一個錯誤  ora-00600 [2032]  

 

ORA-600 [2032] "corrupt block during redo generation" [ID 105992.1]
		Modified 29-MAY-2008     Type REFERENCE     Status PUBLISHED

Note: For additional ORA-600 related information please read 

PURPOSE:
  This article represents a partially published OERI note.

  It has been published because the ORA-600 error has been 
  reported in at least one confirmed bug.

  Therefore, the SUGGESTIONS section of this article may help
  in terms of identifying the cause of the error.

  This specific ORA-600 error may be considered for full publication
  at a later date. If/when fully published, additional information 
  will be available here on the nature of this error.



SUGGESTIONS:        

  If the Known Issues section below does not help in terms of identifying
  a solution, please submit the trace files and alert.log to Oracle
  Support Services for further analysis.

  Known Issues:

  Bug# 3078613   See 
      Buffer cache corruption can occur when using different DB block sizes in the same database
      Fixed: 9.2.0.5, 10.1.0.2
 
  Bug# 1679690   See 
      Buffer cache in memory corruption (OERI:2032) can lead to permanent data/index mismatch (OERI:12700)
      Fixed: 8.1.7.2, 9.0.1.0
 


  References:

   
         ALERT: Apparent data corruptions involving Solaris 2.6, ISM 
         & DR on Starfire

   
        ALERT: Possible Corruption with 8.0.4.2 on Sequent PTX
 

Bug 1679690  Buffer cache in memory corruption (OERI:2032) can lead to permanent data/index mismatch (OERI:12700)
 This note gives a brief overview of bug 1679690. 
 The content was last updated on: 08-AUG-2003
 Click  for details of each of the sections below.
Affects:
Product (Component)
Oracle Server (Rdbms)
Range of versions believed to be affected
Versions < 9.0 
Versions confirmed as being affected
 
Platforms affected
Generic (all / most platforms affected)
Fixed:
This issue is fixed in
 
 

Symptoms:	Related To:
Internal Error May Occur (ORA-600)	(None Specified)

Description

A recoverable corruption of a data buffer in the cache can introduce a
permanent inconsistency between the table and the index.
Eg: An ORA-600 [2032] (in memory buffer corruption) can lead to 
    a permanent ORA-600 [12700] error.

Workaround:
  Once encountered, drop / recreate the index (do NOT use ALTER INDEX
  REBUILD to recreate the index).
  There is no preventative workaround, but this scenario is very rare
   as is requires there to be an in-memory corruption occuring.