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

Media Recovery Waiting for thread 1 sequence 921276 (intransit)

Recovery of Online Redo Log: Thread 1 Group 72 Seq 921276Reading 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 toMANUAL

The file should be manually created to continue.

MRP0: Background Media Recovery terminated with error1274

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 change15893497106246

Mon Apr 18 17:21:39 2018

……………….

Mon Apr 18 17:21:40 2018

Mon Apr 18 17:21:40 2018

 LMS 3: 0 GCSshadows cancelled, 0 closed, 0 Xw survived

 LMS 1: 0 GCSshadows cancelled, 0 closed, 0 Xw survived

Mon Apr 18 17:21:40 2018

 LMS 2: 0 GCSshadows cancelled, 0 closed, 0 Xw survived

 Set master nodeinfo

 Submitted allremote-enqueue requests

 Dwn-cvts replayed,VALBLKs dubious

 All grantableenqueues granted

Mon Apr 18 17:22:00 2018

 Submitted all GCSremote-cache requests

 Fix write in gcsresources

Mon Apr 18 17:22:01 2018

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

Mon Apr 18 17:22:01 2018

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

Mon Apr 18 17:22:01 2018

Archived Log entry 124723 added for thread 2 sequence83913 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 sequence921276 ID 0xffffffffeab48e3c dest 1:

Mon Apr 18 17:23:13 2018

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

Mon Apr 18 17:23:19 2018

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

Mon Apr 18 17:24:20 2018

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

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

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

为什么这样 原理如下：

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

因此若不处理 UNNAMED02172 这个数据文件的话，则备库在应用redo时就会出错，提示找到文件，就会出现不能应用日志的情况。要想能正常应用日志，先处理 UNNAMED02172 的文件，处理后备库先应用unname文件，然后才能按日志的顺序应用。

若数据库应用日志的先后顺序是这样：redo1->redo2->redo3……..，在添加数据文件时，当时redo用到了 

处理过程如下：

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=autoscope=both sid=’*’;

4.  启动恢复

SQL>  alter database recover managed standby database usingcurrent logfile 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 wherename='apply lag';