当前位置：首页 > 数据库 > Oracle教程 > 记一次DG修复后无法打开小乌龙 > 正文

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

来源：这里教程网 时间：2026-03-03 18:20:27 作者：

描述： 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。
切记：打开备份模式后，一定要记得关闭，不然数据库重启后将无法打开。

编辑推荐：

相关推荐

最新软件资讯

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

热文推荐

天极热推