如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com
在ORACLE中形成 数据块损坏/坏块诊断corruption多种多样,但其症状大致为如下几种:
- ORA-01578错误
- ORA-600[61xx]错误
- ORA-600[3339]或者ORA-600[3398]
- ORA-600[2130],ORA-600[2845],ORA-600[4147]错误等等
- SELECT 查询出讹误的数据
应当该类ORACLE数据块损坏/坏块诊断的问题 有这么几个三板斧的步骤:
1、如果数据库仍然是打开状态,则需要判断该块损坏/坏块所在的 数据文件号、块号 并定位到具体的对象(可能是表或者索引)。 结合ORA-1578错误或者ORA-600报出的变量信息,采取如下SQL来定位
SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents WHERE file_id = &fileid and &blockid between block_id AND block_id + blocks - 1;
2、取决于上一步获得的SEGMENT_TYPE, 如果是以下的SEGMENT_TYPE是可以重建的:
- index
- 数据可以重新获得的表,或者可以重建的表
- 回滚段,除了SYSTEM这个回滚段
- 排序段 , sort segment
- 临时表
3、 如果不属于步骤2中支出的任何一种,那么需要注意以下的信息:
- 数据库是否是归档模式
- 有无表的备份数据,包括export /sqlldr
- 是否该表上有基于 NOT NULL字段的索引?
- 如果有这样的索引,那么是否是UNIUQE的?
4、是否这套库从前已经有块损坏/坏块的情况? 这一点有经验的DBA可以从alert.log大致了解情况的, 如果以往有过此类问题则可以参考下文的后续建议
5、如果用户正使用归档模式,则应当建议保存一份归档redo和在线日志以便今后的后续诊断。如果不是,则要求用户备份所有的在线日志
6、在有条件的情况下做10210,10211和10212 event来捕捉错误源头。 如果现场工程师怀疑问题不是由于 ORACLE本身引起的,则建议dump 有问题的数据块并结合OS和存储、卷管理器的日志来分析。 如果怀疑是内存损坏则有必要考虑_db_block_cache_protect ,注意不是所有平台支持_db_block_cache_protect而且其损坏较多性能
7、在某些情况下,有必要要求用户启用归档模式来避免后续再次发生问题时无法有效恢复
必要收集的证据
1、 包括ORACLE TRACE和ALERT文件,这个是我们诊断此类问题的源头, 并分析这些报告中是否有其他数据块被报告存在损坏
2、从OS角度转储坏的数据块
Unix: dd if=badfile.dbf count=5 bs=2048 skip=75
后续建议
1、当我们在分析trace或redo日志转储时 有必要调整用户的预期,要表达给用户这些信息:
- 我们在帮助判断原因,而不是判断如何修复这些坏块
- 我们在研究这些证据,但这些证据未必能让我们下决定性的结论
2、有时候数据块是在内存中损坏了 例如ORA-600[3398],为了验证这些情况可以:
- analyze table X validate structure cascade;
- alter system flush buffer_cache;
- 从OS角度转储该数据块并分析
后续措施
1、寻找本质, 例如:
- 所有的损坏都只发生在某个裸设备或者设备或者控制器上
- 每数4个块出现一个坏块
- 数据块本身没问题,但是出现的位置不对
- 数据块的部分是健康的,但其他地方不正确
2、 通过绕过存在 损坏/坏块的数据块来重建表:
使用10231 level 10事件来执行一个全表扫描的CTAS
通过构建ROWID来避免访问损坏的数据块 【数据恢复】利用构造ROWID实现无备份情况下绕过ORA-1578、ORA-8103、ORA-1410等逻辑/物理坏块问题
3、 启用10210、10211和10212并更新数据块来进一步定位坏块的细节,并考虑使用10231 event
其他工具
其他可选的工具包括dul、oranum、orapatch、bbed等,这些都是ORACLE内部工具。
Comment