公司生产库崩溃，没有备份和归档，想碰碰运气在mount下利用没有覆盖的redo来recover database，其实还算运气好刚好可以recover然后顺利open db，下面的警告日志中提到了我们经常说的db如何会恢复，db找到corrupted block然后不停的利用redo来恢复，从下面的recover记录中可以看出来Media Recovery Start parallel recovery started with 7 processes

并行recovery以及利用redo和archivelog具体恢复信息。

SQL> recover database;

Media recovery complete.

SQL> alter database open;

Database altered.

警告日志记录：

Thu Apr 12 08:54:18 2012

ALTER DATABASE RECOVER database

Media Recovery Start

parallel recovery started with 7 processes

Thu Apr 12 08:54:19 2012

Recovery of Online Redo Log: Thread 1 Group 3 Seq 42178 Reading mem 0

Mem# 0 errs 0: /db/oracle10g/oradata/benguo/redo03.log

Thu Apr 12 08:54:32 2012

Hex dump of (file 2, block 8337) in trace file /db/oracle10g/admin/benguo/bdump/benguo_p002_30981.trc

Corrupt block relative dba: 0x00802091 (file 2, block 8337)

Fractured block found during media recovery

Data in bad block:

type: 2 format: 2 rdba: 0x00802091

last change scn: 0x0000.615fa3f6 seq: 0x6 flg: 0x04

spare1: 0x0 spare2: 0x0 spare3: 0x0

consistency value in tail: 0xe0020202

check value in block header: 0xb288

computed block checksum: 0x5553

Reread of rdba: 0x00802091 (file 2, block 8337) found same corrupted data

Hex dump of (file 2, block 8345) in trace file /db/oracle10g/admin/benguo/bdump/benguo_p002_30981.trc

Corrupt block relative dba: 0x00802099 (file 2, block 8345)

Fractured block found during media recovery

Data in bad block:

type: 2 format: 2 rdba: 0x00802099

last change scn: 0x0000.615fe005 seq: 0x16 flg: 0x04

spare1: 0x0 spare2: 0x0 spare3: 0x0

consistency value in tail: 0xb1b20201

check value in block header: 0x492b

computed block checksum: 0x1f3f

Reread of rdba: 0x00802099 (file 2, block 8345) found same corrupted data

Hex dump of (file 2, block 8329) in trace file /db/oracle10g/admin/benguo/bdump/benguo_p002_30981.trc

Corrupt block relative dba: 0x00802089 (file 2, block 8329)

Fractured block found during media recovery

Data in bad block:

type: 2 format: 2 rdba: 0x00802089

last change scn: 0x0000.615fdffd seq: 0x2 flg: 0x04

spare1: 0x0 spare2: 0x0 spare3: 0x0

consistency value in tail: 0x97870233

check value in block header: 0x7a22

computed block checksum: 0xdeee

Reread of rdba: 0x00802089 (file 2, block 8329) found same corrupted data

……省略了中间部分block的介质恢复

Thu Apr 12 08:54:34 2012

Hex dump of (file 2, block 9069) in trace file /db/oracle10g/admin/benguo/bdump/benguo_p001_30979.trc

Corrupt block relative dba: 0x0080236d (file 2, block 9069)

Fractured block found during media recovery

Data in bad block:

type: 2 format: 2 rdba: 0x0080236d

last change scn: 0x0000.615fe2f8 seq: 0x3 flg: 0x04

spare1: 0x0 spare2: 0x0 spare3: 0x0

consistency value in tail: 0x00320209

check value in block header: 0xfad

computed block checksum: 0xad65

Reread of rdba: 0x0080236d (file 2, block 9069) found same corrupted data

Thu Apr 12 08:54:34 2012

Media Recovery Complete (benguo)

Thu Apr 12 08:54:37 2012

Completed: ALTER DATABASE RECOVER database

其实自己想展示的是如何用下列办法来恢复db：

生产库服务器意外断电，导致db无法open，一般意外断电，redo和undo都可能损坏，如果没有备份此时自己想到是什么allow_resetlogs_corruption和corrupted_rollback_segment隐含参数来打开db，注意用allow_resetlogs_corruption打开时最可能出现的ora-000600的2662

的错误，根据第三个参数和第五个参数差别来推进scn。

此时可以使用oracle内部事件10015来推进scn

alter session set events ‘10015 trace name adjust_scn,level x’, 推进scn

不过对于10g下有个错误就是使用10015事件推进scn时需要手动设置隐含参数_allow_error_simulation,该参数在10g下默认是false，也就是推进scn没有实际效果，需要注意的是即使不设置_allow_error_simulation为true，该命令依然显示执行，其实oracle内部的scn并没有推荐。

此时又可能出现新的错误，ora-00600 internal error code argument [4193]…

600中如果出现错误4193很可能是回滚段的问题，此时需要我们设置corrupted_rollback_segment该参数来使错误的回滚段不检查，修改undo_management=manual手动管理undo，然后就是重复几次recover database until cancel然后open resetlogs，这种办法一般是可以打开大多数db的，如果实在不行可能需要额外的办法和工具来处理。上次一个实际的db解决了但是没有记录相应的恢复步骤，后续碰见合适机会的补一个blog的恢复流程。

[@more@]