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

本文详细介绍了如何解决Oracle9.2.0.8 RAC环境下遇到的ORA-08103错误,该错误通常在执行SELECT语句时出现,表示所选对象已不存在。文章还探讨了错误原因,包括在执行TRUNCATE命令后的下一次块读取时可能出现的情况,并提供了可能的解决方案,如使用DELETE代替TRUNCATE,或者在SELECT中使用FOR UPDATE锁定表。此外,文章还提到了相关警报日志中的另一个错误ORA-00600[2032],表示在redo重做过程中遇到坏块。最后,文章提供了一些检查和确认步骤,帮助用户诊断并解决类似问题。

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 
 

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 affectedVersions < 9.0
Versions confirmed as being affected
  • 8.1.7.1
Platforms affectedGeneric (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

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/35489/viewspace-676576/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/35489/viewspace-676576/

<think>嗯,用户问的是在使用truncate table操作表分区时是否会引发ORA-08103错误,以及如何解决这个问题。我需要结合之前提供的解决方案和现在用户给出的引用来回答。首先,用户引用的内容中有提到Bug 19689979,这个Bug是在Oracle 11.2.0.4及以上版本中,在分区表执行truncate后可能引发ORA-8103或错误结果。解决方案是刷新共享池,这可能和元数据缓存有关。 接下来,我需要确认truncate表分区是否会导致ORA-08103。根据之前的回答,并发DDL操作是主要原因之一,而truncate属于DDL操作,如果在执行truncate时有其他会话在访问该分区,可能会引发错误。例如,用户可能在truncate一个分区时,另一个会话还在查询该分区的数据,导致对象元数据不一致。 另外,引用[3]提到执行alter system flush shared_pool可以解决,这说明问题可能与共享池中的缓存元数据未及时更新有关。在truncate分区后,如果Oracle的元数据缓存没有及时刷新,后续查询可能会访问到已经被删除或修改的分区对象,从而触发错误。 还需要考虑分区表的维护操作。比如,truncate分区后,可能需要进行元数据的同步,或者检查分区的有效性。用户提到的引用[4]中提到了使用dbms_space_admin.assm_tablespace_verify来验证表空间,这可能与存储结构有关,需要检查分区存储是否正确。 总结可能的原因:1. 并发访问导致元数据不一致;2. Oracle Bug(如19689979);3. 共享池中的旧元数据未刷新;4. 分区存储结构损坏。 解决方案方面,首先应该检查是否存在并发操作,确保truncate时没有其他会话在使用该分区。然后尝试刷新共享池和缓冲区缓存。如果问题由已知Bug引起,可能需要应用补丁或升级数据库版本。另外,验证分区的存储结构和元数据有效性,使用提供的PL/SQL包进行修复。 预防措施包括在维护窗口执行DDL操作,启用行移动,以及定期监控无效对象。这些都能减少ORA-08103的发生概率。同时,用户可能需要参考Oracle的官方文档或支持文档来处理特定的Bug情况。</think>#### 一、问题解答 **在使用`TRUNCATE TABLE`操作表分区时,确实可能引发ORA-08103错误**。该问题通常由以下原因导致: 1. **元数据缓存与物理存储不一致** - 分区表执行`TRUNCATE`后,Oracle的共享池可能仍缓存旧对象元数据(如数据字典信息),导致后续操作引用失效的块地址[^2][^3]。 - 典型场景: ```sql --会话1:执行TRUNCATE分区 ALTER TABLE sales TRUNCATE PARTITION p_2023; --会话2:在TRUNCATE完成前发起查询 SELECT COUNT(*) FROM sales PARTITION (p_2023); --可能触发ORA-08103 ``` 2. **Oracle已知Bug(如Bug 19689979)** - 在11.2.0.4及以上版本中,对分区表执行`TRUNCATE`后,若未及时刷新共享池,可能导致元数据与存储结构不同步。 3. **存储结构验证失败** - 分区使用的ASSM(自动段空间管理)位图损坏时,`TRUNCATE`操作可能遗留无效块标记[^4]。 --- #### 二、分步解决方案 **步骤1:验证分区状态与存储结构** ```sql --检查分区有效性 SELECT table_name, partition_name, high_value, status FROM dba_tab_partitions WHERE table_name = 'SALES'; --验证ASSM表空间位图 EXEC DBMS_SPACE_ADMIN.ASSM_TABLESPACE_VERIFY('&tablespace_name', DBMS_SPACE_ADMIN.TS_VERIFY_BITMAPS); ``` 若发现位图错误,需联系DBA修复表空间[^4]。 **步骤2:刷新共享池与元数据缓存** ```sql ALTER SYSTEM FLUSH SHARED_POOL; --清理SQL缓存 ALTER SYSTEM FLUSH BUFFER_CACHE; --清理数据块缓存 ``` 此操作可强制Oracle重新加载对象元数据[^3]。 **步骤3:处理Oracle Bug场景** -数据库版本为11.2.0.4或12.1,应用补丁`19689979`或升级到12.2及以上版本。 - 临时规避方案: ```sql --TRUNCATE后立即执行DDL同步 ALTER TABLE sales MODIFY PARTITION p_2023 UPDATE INDEXES; ``` **步骤4:隔离DDL操作** - 执行`TRUNCATE`前锁定表分区: ```sql LOCK TABLE sales PARTITION (p_2023) IN EXCLUSIVE MODE NOWAIT; ``` - 确保无活跃事务访问目标分区: ```sql SELECT sid, serial#, sql_text FROM v$session WHERE sql_text LIKE '%sales%PARTITION%p_2023%'; ``` --- #### 三、预防措施 1. **操作时序控制** - 避免在业务高峰期执行分区维护操作。 - 使用`DBMS_LOCK`包实现程序化锁控制。 2. **启用分区表闪回** ```sql ALTER TABLE sales ENABLE ROW MOVEMENT; --支持分区级闪回 ``` 3. **定期维护** ```sql ANALYZE TABLE sales VALIDATE STRUCTURE CASCADE; --检查表结构一致性 ``` --- #### 四、关联问题扩展 1. **ORA-08103ORA-04043的区别** - ORA-04043表示对象完全不存在(如被`DROP`),而ORA-08103表示对象存在但存储块已失效[^2]。 2. **分区表ORA-08103特殊处理** - 使用`ALTER TABLE ... TRUNCATE PARTITION`替代全表操作。 - 结合`UPDATE GLOBAL INDEXES`避免索引失效。 [^1]: TRUNCATE操作可能引发元数据不一致 [^2]: 块级失效是ORA-08103的核心特征 [^3]: 共享池刷新是已知Bug的临时解决方案 [^4]: ASSM表空间需定期验证存储结构
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值