主库resize datafile操作导致DG同步报错

主库resize datafile操作导致DG同步报错

[TOC]

一、问题描述

应用人员反馈ADG库，报表查询数据延迟。

二、原因排查

1. 检查DG同步状态

SQL> set line222
SQL> select process,status,thread#,sequence# from v$managed_standby;

PROCESS   STATUS	  THREAD#  SEQUENCE#
--------- ------------ ---------- ----------
ARCH	  CLOSING		1      613912
ARCH	  CLOSING		2      653575
ARCH	  CONNECTED		0	   0
ARCH	  CLOSING		1      613913
RFS	      IDLE		0	   0
RFS	      IDLE		0	   0
RFS	      IDLE		0	   0
RFS	      IDLE		2      653575
RFS	      IDLE		0	   0
RFS	      IDLE		0	   0
RFS	      IDLE		0	   0
RFS	      IDLE	        1      613914

12 rows selected.

结论： 没有RMP进程，同步异常停止了。

2. 检查备库alert日志，查看MRP进程停止原因

Media Recovery Waiting for thread 2 sequence 653569 (in transit)
Recovery of Online Redo Log: Thread 2 Group 70 Seq 653569 Reading mem 0
  Mem# 0: /oradata7/xxx/xxx/redo/redo70.log
MRP0: Background Media Recovery terminated with error 1237
Errors in file /u01/app/oracle/diag/rdbms/xxx/xxx/trace/xxx_pr00_7011.trc:
ORA-01237: cannot extend datafile 1502
ORA-01110: data file 1502: '/oradata5/xxx/xxx/datafile/xxx.318.1020330909'
ORA-19502: write error on file "/oradata5/xxx/xxx/datafile/xxx.318.1020330909", block number 1003648 (block size=8192)
ORA-27072: File I/O error

结论：ORA-27072: File I/O error报错导致MRP进程中断，检查发现是/oradata5磁盘空不足，使用率已达到100%，经过检查，发现是因为主库执行了resize datafile 30G，而相对应的备库数据文件，所在的/oradata5数据盘空间不足，不够resize 到30G，导致MRP进程中断。 

三、解决办法

1. 停止备库

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

2. 移动数据文件到其他盘符

mv /oradata5/xxx/xxx/datafile/xxx.318.1020330909 /oradata7/xxx/xxx/datafile/xxx.318.1020330909

3. 修改控制文件信息

SQL> startup mount
ORACLE instance started.

Total System Global Area 1068937216 bytes
Fixed Size                  2260088 bytes
Variable Size             864027528 bytes
Database Buffers          197132288 bytes
Redo Buffers                5517312 bytes
Database mounted.


SQL> alter system set standby_file_management=manual;

System altered.

SQL> alter database rename file '/oradata5/xxx/xxx/datafile/xxx.318.1020330909' to '/oradata7/xxx/xxx/datafile/xxx.318.1020330909';

Database altered.

SQL> alter system set standby_file_management=AUTO;

System altered.

4. 启动同步

SQL> alter database open;

Database altered.

SQL> alter database recover managed standby database using current logfile disconnect;

Database altered.

5. 再次检查同步

SQL> set line222
SQL> select process,status,thread#,sequence# from v$managed_standby;

PROCESS   STATUS	  THREAD#  SEQUENCE#
--------- ------------ ---------- ----------
ARCH	  CLOSING		2     653591
ARCH	  CLOSING		2     653590
ARCH	  CONNECTED		0	   0
ARCH	  CLOSING		1     613928
RFS	      IDLE		0	   0
RFS	      IDLE		0	   0
RFS	      IDLE		0	   0
RFS	      IDLE		0	   0
RFS	      IDLE		0	   0
RFS	      IDLE		0	   0
RFS	      WRITING		1     613929
RFS	      WRITING		2     653592
MRP0	  APPLYING_LOG		1     613916

13 rows selected.

结论： DG同步恢复正常。

四、其他报错

最开始是想通过offline datafile 方式，在不关库的情况下移动报错的数据文件，但是执行过程中有报错。具体如下：

1. 执行datafile 1052 offline drop 没有报错。(备库必须加drop，否则也报错)
2. 移动数据文件到其他盘符，没有报错。
3. rename datafile 操作开始报错。具体报错信息如下：

1. 报错信息

1. 执行alter database rename file …命令，报错如下：

SQL> alter database rename file '/oradata5/xxx/xxx/datafile/xxx.318.1020330909' to '/oradata7/xxx/xxx/datafile/xxx.318.1020330909';

ORA-01124: cannot recover data file 1052 - file is in use or recovery

2. 重新online datafile，先执行recover datafile，但是执行报错：

SQL> recover datafile 1052;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

SQL> recover datafile 1052 using backup controlfile;
ORA-00274: illegal recovery option USING

 所以，又将数据库重启至mount状态，rename datafile后，再open database。

2. 解决办法

在open状态下，直接执行online操作，并没有报错

SQL> alter database datafile 1052 online;

Database altered.

SQL> select status from v$datafile where file#=1052;

STATUS
--------------
RECOVER

SYS@ORCLCDB> SELECT FILE#,status  FROM v$datafile_header  where FILE#=1052;

     FILE# STATUS
---------- --------------
      1052 ONLINE

结论：

1.直接执行online datafile 无报错，但是查询v$datafile中status仍然为recover状态，查询v$datafile_header 中status为online状态。

 2.本来想着如果datafile 1052 一直是recover状态的话，就从主库重新备份控制文件，更换备库的，但是经过观察后，在MRP应用一段时间后，datafile 1052状态从recover变为online。

SQL> alter database recover managed standby database using current logfile disconnect;

Database altered.

SQL> select status from v$datafile where file#=1052;

STATUS
--------------
ONLINE