Oracle数据恢复:文件系统格式化,ASM和字典损坏 3个案例

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638    QQ号:47079569    邮箱:[email protected]

 

上周以来,我帮助许多用户进行数据恢复,解救了数据库的多重危险。下面和大家分享一下这些案例:
案例一:存储维护时,误用、格式化正在使用中的硬盘,导致数据库崩溃。

 

用户格式化ext3文件系统后,导致情况变得更加复杂。

 

客户原有系统使用ASM存储管理,约2T存储设备的两个硬盘得以恢复,我们有两个硬盘数据重组ASM默认AU大小为1M,在两个磁盘之间保持平衡(平衡)。存储平衡是Oracle技术的性能改进,但是,在发生故障的情况下,你会发现这个技术折磨人,通常使用文件系统,文件将被存储在单个系统上,ASM被分散,从而导致即使是第一次创建系统表空间,也必然在两个磁盘之间交替存储。

 

好了,那么我们应该明白:做磁盘维护一定要小心,如果有必要,使用工具来比较磁盘分区,我以前常用UE来比较。

案例二:使用Raid 5磁盘阵列,瞬间失去了两个硬盘驱动器。强制上线,导致数据不一致,数据库无法启动。

 

最初的错误信息Redo日志进一步损坏ASM,正确安装后台RBAL进程有时陷于僵局。

最后检查时,我们发现多个数据文件存在损坏,这就意味着损坏磁盘并加载,使得多个文件被损坏。该数据库是一个非存档备份,比较麻烦,因为数据的量是在TB级进行恢复。

在我看来,这种情况下的进程,有几个方面值得商榷,但不改变最终的结果,但是我总结了一些新的DBA代码,还做了个PPT关于“DBA误判”,有机会后共享ACOUG。

最后,我们指导用户通过工具进行数据提取恢复

 

案例三:客户经常创建表空间,并删除表空间,从而导致不一致的数据字典,数据库无法正常运行。

我觉得这是Oracle Metalink的错误,虽然没有标记,但属于Oracle自己的问题。出错的最后表现是,两个表空间文件正常,但删除提示不存在,也影响其他操作。

第一个表空间DROP操作会导致以下错误:

Thu Jun 24 20:00:04 2010
DROP TABLESPACE FMI is
Thu Jun 24 20:00:04 2010
ORA-959 signalled during: DROP TABLESPACE FMI

然后就是以下ORA-00600错误:

Thu Jun 24 20:03:59 2010
Errors in file / oracle/admin/cgk/udump/cgk_ora_25919.trc:
ORA-00600: internal error code, arguments: [4348], [U], [0], [229], [], [], [], []

MetaLink上的4348错误,在这种情况下没有记录,提到229表空间不能被删除。

客户进一步修复数据库错误ORA-00600,2501以及25015,以及表空间文件的备份。

Fri Jun 25 09:18:40 2010
Errors in file / oracle/admin/cwg/udump/cwg1_ora_20031.trc:
ORA-00600: internal error code, arguments: [25013], [0], [229], [FEEN2], [FEEk], [184], [179], []
Fri Jun 25 09:18:45 2010
Errors in file / oracle/admin/cwg/bdump/cwg1_pmon_4050.trc:
ORA-00600: internal error code, arguments: [25015], [229], [179], [184], [], [], [], []
Fri Jun 25 09:18:47 2010
Trace dumping is performing id = [cdmp_20100625091847]
Fri Jun 25 09:18:47 2010
Errors in file / oracle/admin/cwg/bdump/cwg1_pmon_4050.trc:
ORA-00600: internal error code, arguments: [kccocx_01], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [25015], [229], [179], [184], [], [], [], []

正常情况下,这个问题应该可以用表空间文件离线/掉线的操作予以纠正,但客户尝试了很多方法进行恢复,导致数据库无法启动。
重建控制文件,明确相应的文件,故障状态下的数据库错误为2662和2663:

Sat Jun 26 22:28:49 2010
Errors in file / oracle/admin/cwg/udump/cwg1_ora_23293.trc:
ORA-00600: internal error code, arguments: [2662], [0], [487169572], [0], [487170770], [4194313], [], []
Sat Jun 26 22:28:51 2010
Errors in file / oracle/admin/cwg/udump/cwg1_ora_23293.trc:
ORA-00600: internal error code, arguments: [2662], [0], [487169572], [0], [487170770], [4194313], [], []

Sun Jun 27 21:21:52 2010
Errors in file / oracle/admin/cwg/udump/cwg1_ora_3887.trc:
ORA-00600: internal error code, arguments: [2663], [0], [487192946], [0], [487202512], [], [], []
Sun Jun 27 21:21:57 2010
Errors in file / oracle/admin/cwg/udump/cwg1_ora_3887.trc:
ORA-00600: internal error code, arguments: [2663], [0], [487192946], [0], [487202512], [], [], []

利用_allow_resetlogs_corruption参数和10015事件可以强制打开数据库:

更改会话组事件’10015 trace name adjust_scn level ‘;

当然,这种情况可能会导致数据丢失。

用这些手段强行打开数据库,你可以手动进行表空间信息文件$错误日志的修正,以恢复数据库的正常运行。

似乎进入了一个数据库故障多发期,所以请DBA进行及时、有效的备份,而且执行任何数据库操作时都应谨慎。

 

 


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *