Oracle数据恢复:格式化、ASM及字典损坏案例三则
2010-06-29 18:52
633 查看
链接:http://www.eygle.com/archives/2010/06/asm_format_dictionary.html
最近一周以来,我帮助多家用户进行了数据恢复,挽救了多个危难之中的数据库。以下和大家分享一下这些案例:
案例一:用户在进行存储维护时,误操作,格式化
了一块正在使用中的硬盘,导致数据库崩溃
。
用户在格式化之后,还建立了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们做好及时有效地备份,并且应当谨慎的执行任何数据库操作。
站内相关文章|Related Articles
ORA-00600
kcratr_nab_less_than_odr案例一则
SMON:
recover undo segment 与 事务恢复
ORA-600
kcbzpbuf_1 坏块的恢复案例一则
使用
ora_rowscn识别误操作数据时间点
断
电故障导致 ASM DiskGroup 故障及恢复案例
最近一周以来,我帮助多家用户进行了数据恢复,挽救了多个危难之中的数据库。以下和大家分享一下这些案例:
案例一:用户在进行存储维护时,误操作,格式化
了一块正在使用中的硬盘,导致数据库崩溃
。
用户在格式化之后,还建立了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们做好及时有效地备份,并且应当谨慎的执行任何数据库操作。
站内相关文章|Related Articles
ORA-00600
kcratr_nab_less_than_odr案例一则
SMON:
recover undo segment 与 事务恢复
ORA-600
kcbzpbuf_1 坏块的恢复案例一则
使用
ora_rowscn识别误操作数据时间点
断
电故障导致 ASM DiskGroup 故障及恢复案例
相关文章推荐
- Oracle案例:损坏数据文件的恢复方法
- oracle数据恢复案例 - 控制文件损坏,无备份
- 南京李先森硬盘磁头损坏数据恢复案例
- Oracle ASM 相关的 视图(V$) 和 数据字典(X$)
- Oracle dmp文件损坏恢复案例
- Oracle 11G Rman备份ASM数据恢复到本地磁盘
- Oracle ASM 相关的 视图(V$) 和 数据字典(X$)
- Oracle dmp文件损坏恢复案例
- V7000数据恢复案例_存储文件系统损坏
- Oracle ASM 相关的 视图(V$) 和 数据字典(X$)
- Oracle dmp文件损坏恢复案例
- Oracle ASM 相关的 视图(V$) 和 数据字典(X$)
- windows 2000 advance server +oracle 9i系统崩溃后的数据恢复案例
- 南京鼓楼oracle旧数据库还原出错,数据恢复成功案例
- AUL(MyDUL) Oracle及Oracle ASM数据恢复
- Oracle ASM 相关的 视图(V$) 和 数据字典(X$)
- Oracle的学习四:数据库管理员、逻辑备份与恢复、数据字典、动态性能视图、管理表空间与数据文件
- oracle 恢复学习 案例1 一个数据文件丢失 完全恢复数据库
- Oracle ASM 相关的 视图(V$) 和 数据字典(X$)
- Oracle 数据库模拟数据文件损坏恢复