时间:2021-07-01 10:21:17 帮助过:279人阅读
造成Oracle数据库打不开,无法打开的情况大致有几种: 参数设置不当 控制文件损坏 日志文件损坏 数据文件头损坏 数据字典损坏 UNDO损坏 SMON回滚事务时遇到问题 如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复
造成Oracle数据库打不开,无法打开的情况大致有几种:
针对不同的报错ORA-00600/ORA-07445等,可以有不同的应对方法:
在ORACLE中形成 数据块损坏/坏块诊断corruption多种多样,但其症状大致为如下几种:
应当该类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是可以重建的:
3、 如果不属于步骤2中支出的任何一种,那么需要注意以下的信息:
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],为了验证这些情况可以:
后续措施
1、寻找本质, 例如:
2、 通过绕过存在 损坏/坏块的数据块来重建表:
使用10231 level 10事件来执行一个全表扫描的CTAS
通过构建ROWID来避免访问损坏的数据块 【数据恢复】利用构造ROWID实现无备份情况下绕过ORA-1578、ORA-8103、ORA-1410等逻辑/物理坏块问题
3、 启用10210、10211和10212并更新数据块来进一步定位坏块的细节,并考虑使用10231 event
其他工具
其他可选的工具包括dul、oranum、orapatch、bbed等,这些都是ORACLE内部工具。
Related posts:
原文地址:Oracle数据库打不开的解决, 感谢原作者分享。