对于DATA GUARD环境的数据库，STANDBY_FILE_MANAGEMENT 参数决定当主库创建或添加数据文件时，备库是否自动创建，最近遇到STANDBY_FILE_MANAGEMENT 参数设置为MANUAL，导致主库表空间正常添加数据文件后，备库无法真正创建数据文件，而是在控制文件中加入了UNNAMED00024的记录，而且应用归档进程MRP0终止，以下是告警日志信息：

Thu Sep 20 14:25:04 2012
Media Recovery Log +ARCH/dg2/archivelog/2012_09_20/thread_1_seq_18291.9213.794497155
File #24 added to control file as 'UNNAMED00024' because
the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL
The file should be manually created to continue.
Errors with log +ARCH/dg2/archivelog/2012_09_20/thread_1_seq_18291.9213.794497155
MRP0: Background Media Recovery terminated with error 1274
Errors in file /u01/app/oracle/diag/rdbms/dg2/fhacdb/trace/fhacdb_pr00_8266.trc:
ORA-01274: cannot add datafile '+DATA/fhacdb/datafile/authsystem02.dbf' - file could not
be created
Recovery interrupted!
Recovered data files to a consistent state at change 1613003482
Thu Sep 20 14:25:10 2012
MRP0: Background Media Recovery process shutdown (fhacdb)

告警日志很清楚的显示，由于STANDBY_FILE_MANAGEMENT 参数设置为MANUAL，备库不能创建authsystem02.dbf数据文件，而是向控制文件中加入名字为UNNAMED00024的记录，然后提示应用日志失败，后天进程MRP0终止，下面看下控制文件中记录的数据文件信息。

SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
+DATA/fhacdb/datafile/application01.dbf
+DATA/fhacdb/datafile/authsystem01.dbf
... ...
/u01/app/oracle/product/11.2.0/dbhome_1/dbs/UNNAMED00024

控制文件中并没有authsystem02.dbf记录，而是多了条UNNAMED00024的记录，可以用以下方法重新构建数据文件来解决这个问题。

SQL> alter database create datafile '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/
UNNAMED00024' as '+DATA/fhacdb/datafile/authsystem02.dbf';
Database altered.

再次查看控制文件，错误的数据文件已经被改正。

SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
+DATA/fhacdb/datafile/application01.dbf
+DATA/fhacdb/datafile/authsystem01.dbf
... ...
+DATA/fhacdb/datafile/authsystem02.dbf

此时备库可以正常应用归档，问题解决。

SQL> alter database recover managed standby database disconnect from session;
Database altered.

在执行应用归档命令是，一定要记得看告警日志（个人认为在对数据库做操作时，监控告警日志是个很好的习惯），很多情况下，这个命令在前端是可以正确执行，而不报任何错误，但是告警日志会告诉你这个命令由于某某原因根本就没成功运行，一般这种情况只要解决了这些某某原因，ORACLE就会自动应用日志，而不需要再次运行了（如果是MRP0进程没有挂掉的情况），下面看下应用归档命令时，告警日志的部分内容。

Thu Sep 20 15:23:52 2012
alter database recover managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (fhacdb)
Thu Sep 20 15:23:52 2012
MRP0 started with pid=25, OS id=14349
MRP0: Background Managed Standby Recovery process started (fhacdb)
 started logmerger process
Thu Sep 20 15:23:57 2012
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 24 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Clearing online redo logfile 4 +DATA/fhacdb/redo04.log
Clearing online log 4 of thread 1 sequence number 18322
Clearing online redo logfile 4 complete
Clearing online redo logfile 5 +DATA/fhacdb/redo05.log
Clearing online log 5 of thread 1 sequence number 18323
Clearing online redo logfile 5 complete
Clearing online redo logfile 6 +DATA/fhacdb/redo06.log
Clearing online log 6 of thread 1 sequence number 18324
Clearing online redo logfile 6 complete
Media Recovery Log +ARCH/dg2/archivelog/2012_09_20/thread_1_seq_18291.9213.794497155
Completed: alter database recover managed standby database disconnect from session
Thu Sep 20 15:24:09 2012
Media Recovery Log +ARCH/dg2/archivelog/2012_09_20/thread_1_seq_18292.9214.794499901
Media Recovery Log +ARCH/dg2/archivelog/2012_09_20/thread_1_seq_18293.9215.794499971

本文固定链接: http://www.dbdream.com.cn/2012/09/standby_file_management%e5%8f%82%e6%95%b0%e4%b8%bamanual%e5%af%bc%e8%87%b4%e7%89%a9%e7%90%86%e5%a4%87%e5%ba%93%e6%97%a0%e6%b3%95%e6%b7%bb%e5%8a%a0%e6%95%b0%e6%8d%ae%e6%96%87%e4%bb%b6/ | 信春哥，系统稳，闭眼上线不回滚！