« 恩墨科技第二次 备份与恢复 培训筹划募集中 | Blog首页 | DBID的获取 与 控制文件中有什么？ »

Oracle数据恢复:格式化、ASM及字典损坏案例三则

最近一周以来，恩墨科技帮助多家用户进行了数据恢复，挽救了多个危难之中的数据库。

案例一：用户在进行存储维护时，误操作，格式化了一块正在使用中的硬盘，导致数据库崩溃。
用户在格式化之后，还建立了ext3的文件系统，这导致情况变得更加复杂。

客户原系统使用的是ASM存储管理，两块硬盘组成的大约2T的存储设备，这样在恢复时，我们必须通过两块硬盘来进行数据重组，ASM缺省的AU大小是1M，在两块磁盘之间进行均衡（Balance）,存储均衡是Oracle的一项性能提升技术，然而在故障时，你会发现这一技术让人倍感折磨，通常使用文件系统，一个文件会在单个系统上存储，而ASM是分散的，这就导致哪怕是最早创建的SYSTEM表空间，也必然在两个磁盘之间跨越交替存储。

好了，那么我们应该学习的是：在做磁盘维护时一定要小心谨慎，必要时使用工具对磁盘分区进行比较，我习惯用UE来比较。

案例二：用户的Raid 5盘阵中，瞬间损失了两块硬盘，强制上线后导致数据不一致，数据库无法启动。
最初的错误提示是Redo日志的损坏，ASM进一步无法正常挂接，后台的RBAL进程有时表现为死锁。

在最后的校验中，我们发现多个数据文件都存在损坏，也就是说磁盘的损坏和加载使得多个文件损坏，数据库是非归档、无备份的，由于数据量在TB级别，恢复起来较为麻烦。

在这个案例的处理过程中，我的判断中有几个环节值得商榷，虽然不改变最后结果，但是我总结了一些新的DBA守则，也写了一个PPT，"DBA的误判"，以后有机会在ACOUG上分享一下。

最后我们指导用户通过工具对数据进行了抽取恢复。

案例三：客户在频繁的创建表空间和删除表空间后，导致数据字典不一致，数据库无法正常运行。
我认为这是Oracle的一个Bug，虽然Metalink上没有标记，但是属于Oracle的自身问题。故障的最后体现是，两个表空间文件显示的是正常的，但是删除时提示不存在，而且影响了其他操作。
最初的表空间DROP操作导致如下错误：

Thu Jun 24 20:00:04 2010
DROP TABLESPACE FMI
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], [], [], [], []

4348 号错误在Metalink上没有记录，在本案例中，是指相应的229表空间无法删除。

客户在进一步的修复中，数据库出现了ora-00600的25015及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], [], [], [], []

在正常情况下，这个问题应该可以通过表空间文件的OFFLINE/DROP等操作来修正，可是客户尝试了很多恢复手段，最后导致数据库无法启动。
重建控制文件，清除了相应文件后，数据库以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 event可以强制打开数据库：
alter session set events '10015 trace name adjust_scn level ';
当然这种情况可能会导致数据损失。

通过这些手段强制打开数据库之后，可以手工对表空间信息，file$错误记录进行修正，恢复数据库正常运行。

似乎又进入了一个数据库故障的多发期，所以请DBA们做好及时有效地备份，并且应当谨慎的执行任何数据库操作。

By eygle on 2010-06-28 23:20 | Comments (8) | Backup&Recovery | Life | 2563 |

Recovery