ITPub博客

首页 > 数据库 > Oracle > 快速检查数据库一致性

快速检查数据库一致性

原创 Oracle 作者:sjw1933 时间:2020-09-04 21:28:41 0 删除 编辑

检查一:检查点时间和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 ;

4-7

查询最小一致性scn recover 即可解决

recover database untile scn 82419715478

总结

以上操作都检查完毕后一般就可以顺利打开数据库,不过在打开过程中我们需要关注数据库alert 日志,确认没有额外的报错,比如临时表空间问题。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23825935/viewspace-2717299/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 19c 增加mgmt
请登录后发表评论 登录
全部评论
ORACLE 、DB2、人大金仓 资深数据库专家 拥有超过8年以上的数据库领域从业经验,擅长数据库日常诊断,大型数据库(TB级)迁移,数据库故障修复。 拥有丰富的项目经验。 服务的行业包括电信运营商、通讯设备制造商、银行、金融业、医疗、政府等。

注册时间:2014-01-21

  • 博文量
    17
  • 访问量
    8920