如果生产库出问题坏了，这时候如果数据库有rman备份是十分幸运的，起码可以通过备份集恢复数据。可是往往这时候备份集又会和我们较劲。由于日常时候我们对数据库备份不够重视，在恢复数据的时候经常会发现备份集有问题了，无法正常恢复。如果备份集损坏，而这个备份集又是我们唯一的备份集。这个时候我们的想法可能是能恢复多少数据就恢复多少数据了。这时候我们就想到，不管数据文件是不是有问题，能恢复多少就恢复多少吧。但是不够幸运的是，RMAN恢复对数据的校验十分严格，我们可能碰到下面的错误：
RMAN-00571:===========================================================
RMAN-00569:=============== ERROR MESSAGE STACK FOLLOWS===============
RMAN-00571:===========================================================
RMAN-03002: failure during compilation of command
RMAN-03013:command type: restore
RMAN-03007:retryable error occurred during execution ofcommand: IRESTORE
RMAN-07004:unhandled exception during command executionon channel t1
RMAN-10035:exception raised in RPC: ORA-27192: skgfcls:sbtclose2 returned
error -failed to close file
ORA-19511:sbtclose2: Failed to process backup file.
ORA-19612:datafile 84 not restored due to missing orcorrupt data
RMAN-10031:ORA-19624 occurred during call toDBMS_BACKUP_RESTORE.
RESTOREBACKUPPIECE
这个时候怎么办呢？为了解决这个问题，Oracle提供了两个EVENT 19548,19549。
EVENT 19548：忽略备份集中的坏块，这是一个很危险的事件，建议慎重使用。因为在不设置这个事件的时候，如果RMAN恢复数据文件的时候发现备份集有坏块，就会在坏块的位置写入一个空块。而设置了这个事件，不管怎样，都会将这个块写入数据文件，这可能导致不一致的产生。不过设置了这个事件也不一定能够跳过坏块恢复文件，因为一个备份集往往有多个文件，如果标志哪个块属于哪个文件的数据块坏了，那么恢复数据将变得不可能。
EVENT 19549：如果在恢复的时候还没有恢复到所需要的所有数据块，就碰到文件结束了，这个时候会报 ORA-19612,如果设置了这个事件就会忽略这个错误。
这两个事件可以作为最后的解决方案来使用，不过使用的时候要慎重。
另外要注意的是，这两个事件必须在以下版本使用：
ORACLE 8.1.7.4：必须打了PATCH 2973616,这个补丁目前只支持SUNSPARC 64位和AIX 32位，其他平台无补丁包。
ORACLE 9.2.0.4或者以后版本。
使用方法：
event = "19548 trace name context forever"
event = "19549 trace name context forever"
设置了EVENT后，我们继续执行RMAN恢复操作，rman就不会报错了。不过此时我们恢复出来的数据库可能存在以下几个问题：
1、数据中存在坏块，当访问到某些数据的时候会报错，这种情况可以采用跳过坏块的方式导出数据，然后重建这张表。
2、数据库无法打开，这种情况可以通过强制打开数据库的方式。下面这个例子是十分常见的强制打开数据库的方案：
（1）在原先的参数文件中增加以下行：
（2）启动数据库到mount状态：
SQL> startup mount pfile=/oracle/init0819.ora;
（3）如果出现ORA-600 [4XXX]报错，则需要把有问题的回滚段OFFLINE
（5）恢复数据库：
SQL> recover database using backup controlfile until cancel;
执行恢复后敲cancel
（6）强制打开数据库：
SQL> alter database open resetlogs;
数据库成功打开，但随即又宕掉，alert日志中出现很多如下报错：
ORA-00600: internal error code, arguments: [4193],
这是由于undo记录和redo中的记录不匹配导致
（7）继续在init0819.ora中设置如下参数：
undo_management=manual
event='10513 trace name context forever, level 2'
event='10512 trace name context forever, level 1'
event='10511 trace name context forever, level 2'
event='10510 trace name context forever, level 1'
随后正常打开数据库，打开成功。
因为数据库强行打开后，存在很多不一致的地方，已经无法正常使用，唯一的办法就是将必要的数据导出，重建新的数据库，然后再导入。
3、如果第二种方法无法打开数据库，那么就只能通过工具从文件直接抽取数据了。可以使用Oracle公司的DUL，或者国内一些厂家自己开发的类似工具来完成。
