1. 案例背景
很多时候,我们需要通过rman备份恢复的形式去创建生产数据库的测试库,那么在测试库打开之前我们要确认最小恢复量是多少?执行RESTORE/RECOVER后,我们需要快速验证确保数据库是一致的,并准备OPEN RESETLOGS。
对于冷/离线备份,不需要归档日志/恢复。可以顺利使用resetlogs打开数据库。但是,对于HOT / ONLINE备份,必须先应用从备份开始到备份结束的所有归档日志,然后才能打开数据库。
2. 具体步骤
检查一:检查点时间和Fuzziness
目的:确认数据库文件都恢复到预期时间点(PIT)并且他们是一致性(FUZZY=NO)。
SQL> select fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*) from v$datafile_header group by fuzzy, status, error, recover, checkpoint_change#, checkpoint_time ;
FUZ STATUS ERROR REC CHECKPOINT_CHANGE# CHECKPOINT_TIME COUNT(*)
--- ------- --------------- --- ------------------ -------------------- ----------
NO ONLINE 5311260 31-AUG-2011 23:10:14 6
YES ONLINE 5311260 31-AUG-2011 23:10:14 1
a)确认checkpoint_time / checkpoint_change#与预期的UNTIL TIME / SCN一致。如果不一致且有更多可用的归档日志,请进一步恢复数据库。
b)如果一些数据文件FUZZY=YES,这意味着我们进一步的恢复
检查二:数据文件状态
目的:确认需要recover的文件不是offline状态
SQL> select status, enabled, count(*) from v$datafile group by status, enabled ;
STATUS ENABLED COUNT(*)
------- ---------- ----------
SYSTEM DISABLED 1
ONLINE READ WRITE 4
RECOVER DISABLED 2
检查三:Fuzzy
目的: Fuzzy检查
有时,对于所有恢复的数据文件,可以看到Fuzzy = NO和相同的checkpoint_change#,但OPEN RESETLOGS仍然失败。例如以下信息:
SQL> select fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*) from v$datafile_header group by fuzzy, status, error, recover, checkpoint_change#, checkpoint_time ;
FUZ STATUS ERROR REC CHECKPOINT_CHANGE# CHECKPOINT_TIME COUNT(*)
--- ------- --------------- --- ------------------ -------------------- ----------
NO ONLINE 5311260 31-AUG-2011 23:10:14 7
SQL> ALTER DATABASE OPEN RESETLOGS ;
ORA-01194: file 4 needs more recovery to be consistent
ORA-01110: data file 3: '/<path>/undotbs02.dbf'
因此我们要执行附加的fuzzy检查:
那什么情形下可以通过检查?
a)以上查询没有返回结果
b) Min_PIT_SCN 的返回值小于 Checkpoint_Change#
真实案例如下:
select hxfil file#, substr(hxfnm, 1, 50) name, fhscn checkpoint_change#, fhafs Absolute_Fuzzy_SCN, max(fhafs) over () Min_PIT_SCN from x$kcvfh where fhafs!=0 ;
查询最小一致性scn,recover即可解决
recover database untile scn 82419715478
3. 案例总结
以上操作都检查完毕后一般就可以顺利打开数据库,不过在打开过程中我们需要关注数据库alert日志,确认没有额外的报错,比如临时表空间问题。