最近在加主库添加数据文件时导致备库无法被应用，警告日志报如下错误：

Media Recovery Waiting for thread 1 sequence 921276 (in transit)

Recovery of Online Redo Log: Thread 1 Group 72 Seq 921276 Reading mem 0

  Mem# 0: +DATA/ractd/onlinelog/group_72.393.965631001

File #2172 added to control file as 'UNNAMED02172' because

the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL

The file should be manually created to continue.

MRP0: Background Media Recovery terminated with error 1274

Errors in file /u01/app/oracle/diag/rdbms/ractd/racdb1/trace/racdb1_pr00_8585508.trc:

ORA-01274: cannot add datafile '+ /data/tb01' - file could not be created

Mon Apr 18 17:21:10 2018

Managed Standby Recovery not using Real Time Apply

Mon Apr 18 17:21:17 2018

Recovery interrupted!

Mon Apr 18 17:21:39 2018

Recovered data files to a consistent state at change 15893497106246

Mon Apr 18 17:21:39 2018

……………….

Mon Apr 18 17:21:40 2018

Mon Apr 18 17:21:40 2018

 LMS 3: 0 GCS shadows cancelled, 0 closed, 0 Xw survived

 LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived

Mon Apr 18 17:21:40 2018

 LMS 2: 0 GCS shadows cancelled, 0 closed, 0 Xw survived

 Set master node info

 Submitted all remote-enqueue requests

 Dwn-cvts replayed, VALBLKs dubious

 All grantable enqueues granted

Mon Apr 18 17:22:00 2018

 Submitted all GCS remote-cache requests

 Fix write in gcs resources

Mon Apr 18 17:22:01 2018

RFS[233]: Selected log 71 for thread 1 sequence 921277 dbid -357299396 branch 822617764

Mon Apr 18 17:22:01 2018

RFS[218]: Selected log 108 for thread 2 sequence 83914 dbid -357299396 branch 822617764

Mon Apr 18 17:22:01 2018

Archived Log entry 124723 added for thread 2 sequence 83913 ID 0xffffffffeab48e3c dest 1:

Reconfiguration complete

Mon Apr 18 17:22:02 2018

Block change tracking service stopping.

Mon Apr 18 17:22:02 2018

Stopping background process CTWR

Mon Apr 18 17:22:03 2018

MRP0: Background Media Recovery process shutdown (racdb1)

Mon Apr 18 17:22:06 2018

Archived Log entry 124724 added for thread 1 sequence 921276 ID 0xffffffffeab48e3c dest 1:

Mon Apr 18 17:23:13 2018

RFS[233]: Selected log 72 for thread 1 sequence 921278 dbid -357299396 branch 822617764

Mon Apr 18 17:23:19 2018

Archived Log entry 124725 added for thread 1 sequence 921277 ID 0xffffffffeab48e3c dest 1:

Mon Apr 18 17:24:20 2018

RFS[233]: Selected log 71 for thread 1 sequence 921279 dbid -357299396 branch

从警告日志 看，备库中一些归档日志无法被应用。原本以为是添加数据文件加到本地（asm），查看主库时添加的数据文件，一切正常，查看从备库的日志来看，File #2172 added to control file as 'UNNAMED02172' because

the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL 原来是参数STANDBY_FILE_MANAGEMENT设置了手动，导致MRP0进程无法启动。

为什么这样 原理如下：

以上问题主要是因为：Standby_file_management参数为STANDBY_FILE_MANAGEMENT =MANUAL造成不会自动管理数据文件，主库增加了数据文件，备库不会自动增加，

正常备库应用的是归档文件，但主库添加数据文件时，，此时会有一部分数据不在归档日志中，但这部分数据会等主数据库恢复完后 'UNNAMED02172' 等这样的文件命名保存此数据，此文件保存在DBS中，从操作系统中进去查看却看不到这个文件。同时这个数据也会传到备库对应的目录中。

若数据库应用日志的先后顺序是这样：redo1->redo2->redo3 ……..，在添加数据文件时，当时redo用到了                                                 因此若不处理UNNAMED02172这个数据文件的话，则备库在应用redo时就会出错，提示找到文件，就会出现不能应用日志的情况。要想能正常应用日志，先处理UNNAMED02172的文件，处理后备库先应用unname文件，然后才能按日志的顺序应用。

处理过程如下：

1. 调整standby_file_management参数为 manual

alter system set standby_file_management= manual scope=both sid=’*’;

2. 通过 control file 手工创建数据文件

SQL>  alter database create datafile
' /u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED02162 ' as '+data/datafile/';

 3. 将 standby_file_management 设置为 auto

SQL>  alter system set standby_file_management=auto scope=both sid=’*’;

4.  启动恢复

SQL>  alter database recover managed standby database disconnect from session;

5. 检查一下是否同步

SQL> select to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') from v$datafile;

结论：

一般在添加数据文件时需要主要如下参数：

备库

standby_file_management

db_FILES

DB_FILE_NAME_convert

LOG_FILE_NAME_CONVERT

查看应用日志状态：

select value from v$dataguard_stats where name='apply lag';