最近在加主库添加数据文件时导致备库无法被应用，警告日志报如下错误：
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';
