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]  

Note: For additional ORA-600 related information please read Note:146580.1

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 Note:3078613.8
      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 Note:1679690.8
      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:

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

   Note:64632.1
        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 here 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
8.1.7.1 
Platforms affected
Generic (all / most platforms affected)
Fixed:
This issue is fixed in
8.1.7.2 (Server Patch Set) 
9.0.1.0 (Base Release) 
Symptoms:
Related To:
Internal Error May Occur (ORA-600) 
Corruption (Index) 
Memory Corruption 
ORA-600 [12700] 
ORA-600 [2032] 
(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.