描述：

DG修复后，只能打开到MOUNT状态，可以正常应用standby redo log，但是无法启动到read only状态，命令卡住，alert日志输出如下：

DG库检查控制文件中scn和文件头如下：

SQL> select to_char(checkpoint_change#) from v$database;

TO_CHAR(CHECKPOINT_CHANGE#)

----------------------------------------

72206402973

SQL> select file#,status,to_char(checkpoint_change#) from v$datafile;

FILE# STATUS TO_CHAR(CHECKPOINT_CHANGE#)

---------- ------- ----------------------------------------

1 SYSTEM 72364895289

2 ONLINE 72364895289

3 ONLINE 72364895289

4 ONLINE 72364895289

……省略

SQL> select file#,to_char(checkpoint_change#) from v$datafile_header;

FILE# TO_CHAR(CHECKPOINT_CHANGE#)

---------- ----------------------------------------

1 72364895289

2 72364895289

3 72364895289

4 72364895289

……省略

发现控制文件中记录的checkpoint_change#比数据文件头中的checkpoint_change#要小，这种情况是不能打开数据库的，但数据可以启动到mount状态。

控制文件是刚从生产standby出来的，理论上不应该，进一步检查生产的各scn号情况

SQL> select to_char(checkpoint_change#) from v$database;

TO_CHAR(CHECKPOINT_CHANGE#)

----------------------------------------

72365504792

SQL> select file#,name,status,to_char(checkpoint_change#) from v$datafile;

FILE# NAME STATUS TO_CHAR(CHECKPOINT_CHANGE#)

---------- ------------------------------ ------- ----------------------------------------

1 /oradata/EMR/system01.dbf SYSTEM 72208371152

2 /oradata/EMR/htcpp01.dbf ONLINE 72208371152

3 /oradata/EMR/sysaux01.dbf ONLINE 72208371152

4 /oradata/EMR/undotbs01.dbf ONLINE 72208371152

SQL> select file#,to_char(checkpoint_change#) from v$datafile_header;

FILE# TO_CHAR(CHECKPOINT_CHANGE#)

---------- ----------------------------------------

1 72208371152

2 72208371152

3 72208371152

生产端做了几个checkpoint后，控制文件的改变了，但是数据文件头中的还是没有变更，奇怪。

SQL> alter system checkpoint;

生产数据文件头的scn看起来像是被锁住了

查看scn对应时间点

SQL> select to_char(scn_to_timestamp(72365504792), 'yyyy-mm-dd hh24:mi:ss') chr,timestamp_to_scn(scn_to_timestamp(72365504792)) dt from dual;

CHR DT

------------------- ----------

2022-10-08 14:46:35 7.2366E+10

SQL> select to_char(scn_to_timestamp(72208371152), 'yyyy-mm-dd hh24:mi:ss') chr,timestamp_to_scn(scn_to_timestamp(72208371152)) dt from dual;

CHR DT

------------------- ----------

2022-10-07 20:58:37 7.2208E+10

控制文件中的scn对应的是当前时间，数据文件头中对应的是前一天晚上的时间。

突然想到昨天这个时间点工程师在做dg恢复，使用了命令

SQL> alter database begin backup;

可能是忘记end backup了！！！

关闭数据库备份模式

SQL> alter database end backup

再次检查各scn，恢复正常。

进一步恢复DG。

注意：alter database begin backup只是锁住了数据文件头块的scn号，但是数据还是会继续写入数据文件，当执行alter database end backup的时候，数据库就会用控制文件中最新的scn去更新每个数据文件头部块的scn。

切记：打开备份模式后，一定要记得关闭，不然数据库重启后将无法打开。

ITPub博客

记一次DG修复后无法打开小乌龙

最新文章