oracle 8103错误,[数据恢复]详解ORA-8103错误

ORA-8103错误通常由于数据块类型无效或数据对象ID不匹配引起。解决策略包括生成错误堆栈跟踪、分析验证表结构、使用ASSM_TABLESPACE_VERIFY等。通过分析analyze validate structure的结果,可以判断是否为LostWrite问题或extent逻辑不一致,进而采取相应的修复措施。
摘要由CSDN通过智能技术生成

ORA-8103是我们Database Consultant 经常要遇到的一个问题,了解ORA-8103的成因非常重要。

简单来说ORA-8103 的主要成因有2类:

数据块的 block type 类型 是 无效的 或者读出来的块类型与Oracle期望的不一致。  例如 Oracle 认为该数据块的类型为data(type=6),但实际却不是。

数据块中的data_object_id 和 数据字典中的data_object_id不匹配

针对ORA-8103问题 我们优先推荐一些措施:

ORA-08103问题的诊断最好是能生成8103错误的ERROR STACK TRACE, 在TRACE中会记录具体引发8103的对象的OBJ和OBJD,这便于我们定位可能存在corruption的对象。

问题在于往往前台进程遇到ORA-08103错误不会在后台生成TRACE文件,这需要我们手动设置8103 触发ERRORSTACK的EVENTS:

ALTER SYSTEM SET EVENTS ’8103 TRACE NAME ERRORSTACK LEVEL 3′;

解决思路包括:

1. 通过OBJD和DBA定位到具体的表名和块号

2. 有条件的情况下对该表做一个analyze .. validate structure

3. 有条件的情况下对该表所在tablespace做一个 dbms_space_admin.ASSM_TABLESPACE_VERIFY

4. 有条件的情况下move这张表或者相关的分区,尝试绕过该问题

5. 有条件的情况下降该表或分区移动到MSSM表空间上,绕过该问题 www.it165.net

execute dbms_space_admin.tablespace_verify(‘&tablespace_name’)

oradebug setmypid

oradebug tracefile_name

execute dbms_space_admin.assm_tablespace_verify(‘&tablespace_name’,dbms_space_admin.TS_VERIFY_BITMAPS)

oradebug setmypid

oradebug tracefile_name

针对不同的 analyze validate structure 后得到的结果 , 我们可以得到一些初步的结论:

如果执行 flush buffer cache之后再次analyze validate structure不再报ORA-8103错误则说明:

可能是完全正常的现象,之前的ORA-8103正是也因为对象正在被DROP/TRUNCATE而导致SELECT报ORA-8103。一般来说Call Stack会显示进程正尝试访问该段的segment header。 更多信息可以参考BUG 7441661

也可能该问题仅仅发生在buffer cache层,而没有发生在DISK上。通过flush buffer_cache若能解决,则一般是这种情况,往往是Buffer Cache管理的BUG 。

如果执行 flush buffer cache之后再次analyze validate structure再次报ORA-8103错误则说明:

如果dump对应的数据块发现 该块在逻辑上是完整一致的(也可以用bbed/dbv工具验证), 则有可能是Lost Write,则不是被其他对象重格式化使用了。

这里判断Lost Write的一个重要手段是 对块做recover/blockrecover,如果recover能修复该块,则说明是因为Lost Write引起了本ORA-8103问题,如果不是则说明99%的可能性是BUG引起的。

常见的一种现象是 使用第三方工具在数据库打开的情况下copy 数据库,这些工具的BUG可能导致copy 老的版本的block到目标新库中。

另一种可能是 extent盘区级别的不一致。 同一个数据块/extent 可能 同时属于 2个数据段segment,这导致其中的一个被后者覆盖。 通过recover的方式是无法修复这种场景的, 因为这种逻辑的讹误发生在表空间级别的extent信息上。 可以检查dba_extents/dba_segments/dba_free_space这些视图来确定问题数据块到底是否同时属于多个对象, 或者 一个数据块 同时出现在dba_extents/dba_segments/dba_free_space 三个视图中, 因为 used extent 不该出现在dba_free_space中,而free extent不该在dba_extents,当然要排除recyclebin中对象的影响。 绝大多数情况下这种extent逻辑不一致的现象, 被称作extent overlap , 通常是Oracle Space Management空间管理层面的BUG。

出处:http://www.askmaclean.com/archives/ora-8103.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值