一 问题描述
在客户使用RAC环境，增加数据文件时候，错误的将datafile加到了本地磁盘，而发现错误后，又执行了offline datafile操作，数据文件状态变成为recover，非online。之后没及时发现，归档日志被删除。

在执行如下恢复sql

恢复数据库的时候报错如下：

二 问题排查
排查下这个数据文件的状态，看到是RECOVER，不是正常的ONLINE：

set line222
col name for a60
SQL> SELECT a.FILE#,a.NAME,a.RECOVER,a.CHECKPOINT_CHANGE#,status  FROM v$datafile_header a;FILE# NAME                                                         REC CHECKPOINT_CHANGE# STATUS
---------- ------------------------------------------------------------ --- ------------------ -------34 /u01/app/oracle/oradata/orcl/iemr_df04.dbf                               1.2727E+13 ONLINE35 /u01/app/oracle/oradata/orcl/system01.dbf                                1.2707E+13 RECOVERSQL> select file#,name,status  from v$datafile;FILE# NAME                                                         STATUS
---------- ------------------------------------------------------------ -------34 /u01/app/
oracle/oradata/orcl/iemr_df04.dbf                   ONLINE35 /u01/app/oracle/oradata/orcl/system01.dbf                    RECOVER

推测是这个问题导致的。

原因是源库上有数据文件状态为RECOVER

SQL> select file#,name,status  from v$datafile;FILE# NAME                                                         STATUS
---------- ------------------------------------------------------------ -------34 /u01/app/oracle/oradata/orcl/iemr_df04.dbf                   ONLINE35 /u01/app/oracle/oradata/orcl/system01.dbf                    RECOVER

在源库执行offline datafile 操作：

alter database datafile 35 offline drop;

提升成功，但是并没有起到作用

查询这个数据文件是否有数据，确定数据文件是否为空

SELECT distinct b.owner, b.segment_name
FROM dba_data_files a,dba_extents b
WHERE a.file_id = b.file_id
AND a.tablespace_name ='SYSTEM'
AND a.file_name ='+DATA/orcl/datafile/system01.dbf';

发现是空的。

删除数据文件命令（建议不要删）

alter tablespace system drop datafile '+DATA/orcl/datafile/system01.dbf';

如果一定要处理的话，可以通过bbed的方式去修复后删除。
三 解决办法
rman备份需要加skip，例如 backup database skip inaccessible;

rman恢复的时候执行offline datafile 操作。

SQL> alter database datafile 35 offline drop;Database altered.SQL> set line222
SQL> col name for a60
SQL> SELECT a.FILE#,a.NAME,a.RECOVER,a.CHECKPOINT_CHANGE#,status  FROM v$datafile_header a;FILE# NAME                                                         REC CHECKPOINT_CHANGE# STATUS
---------- ------------------------------------------------------------ --- ------------------ -------34 /u01/app/oracle/oradata/orcl/iemr_df04.dbf                               1.2727E+13 ONLINE35 /u01/app/oracle/oradata/orcl/system01.dbf                                1.2707E+13 RECOVERSQL> recover database using backup controlfile until cancel;
ORA-00279: change 4593921 generated at 07/09/2022 12:48:34 needed for thread 1
ORA-00289: suggestion : /home/oracle/1_41_1104664055.dbf
ORA-00280: change 4593921 for thread 1 is in sequence #41Specify log: {=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00279: change 4593946 generated at 07/09/2022 12:48:50 needed for thread 1
ORA-00289: suggestion : /home/oracle/1_42_1104664055.dbf
ORA-00280: change 4593946 for thread 1 is in sequence #42
ORA-00278: log file '/home/oracle/1_41_1104664055.dbf' no longer needed for
this recoveryORA-00308: cannot open archived log '/home/oracle/1_42_1104664055.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

结论：recover不在需要35号已经被删除的archive log，正常完成recover 操作。
四 总结
我们在一些恢复案例中，会经常遇到一些奇怪的问题，其中有的是源端数据文件不规范而导致恢复过程出错，比较常见的错误就是数据文件状态为recover，非online状态，要在备份的时候仔细查看源库的状态。还有要多看恢复日志，有些看起来不像报错的，也得注意。