一 环境： data gurad 主备机之间使用物理standby，数据库版本 11.2.0.1.0，aix 平台
二 故障描述：主库使用以下语句添加表空间的数据文件后，备库没有同步创建对应数据文件：
ALTER TABLESPACE OCR ADD DATAFILE '/orcldata/ocr7.dbf' SIZE 30000M
备库查询日志使用情况：SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#，
发现日志从80929到80947都没有应用
检查进程：SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY; 结果结果无MRP0进程
检查备库是否有没有传递过来的日志：SELECT * FROM V$ARCHIVE_GAP; 结果为no rows 即所有主库产生的日志
都传递到备库， 在主备库之间使用archive log list 和在归档目录下ls -l检查两边日志都一样
select DEST_ID,DEST_NAME,error from v$archive_dest;--无结果
以上情况说明：归档传输没有问题，在备库端无法应用日志。
三 解决过程：
检查参数
主库：show parameter standby_file_management
standby_file_management=auto
备库：show parameter standby_file_management
standby_file_management=manual
修改备库参数standby_file_management为auto，重启备库。
vi /orcldata/initorcl.int
standby_file_management=auto
startup pfile='/orcldata/initorcl.int' mount;
试图重新启动日志应用：
alter database recover managed standby database disconnect from session;
执行成功：database altered
但是在检查进程，和日志应用情况，发现依然没有应用
SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
---APPLIED为no的日志依然从80929开始。
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;-- 无MRP0进程
启动数据库到open状态，alter database open，报错如下：
Beginning standby crash recovery.
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
Standby crash recovery aborted due to error 1111.
Errors in file /oracle/diag/rdbms/orcl2/orcl/trace/orcl_ora_16515082.t
ORA-01111: name for data file 11 is unknown - rename to correct file
ORA-01110: data file 11: '/oracle/db/dbs/UNNAMED00011'
ORA-01157: cannot identify/lock data file 11 - see DBWR trace file
ORA-01111: name for data file 11 is unknown - rename to correct file
ORA-01110: data file 11: '/oracle/db/dbs/UNNAMED00011'
Completed standby crash recovery.
发现出现异常文件：/oracle/db/dbs/UNNAMED00011，ls该文件又没有结果
$ ls -l /oracle/db/dbs/UNNAMED00011
ls: 0653-341 The file /oracle/db/dbs/UNNAMED00011 does not exist.
根据报错：ORA-01111提示，在主库检查数据文件
select name,file# from v$datafile;
发现11号文件对应的就是刚才添加的数据文件：/orcldata/ocr7.dbf
在备库同样检查：select name,file# from v$datafile;
发现11好文件对应的是：/oracle/db/dbs/UNNAMED00011
由此判断：主库添加的数据文件/orcldata/ocr7.dbf在备库被应用错误，产生了/oracle/db/dbs/UNNAMED00011文件。
根据以上情况，初步判断主库无法应用日志是因为在备库没有产生正确的文件名，视图通过rename文件名，修改正确，
重新启动备库日志应用应该没有问题，详见以下步骤：
alter system set STANDBY_FILE_MANAGEMENT=AUTO;
rename 不正常的文件/oracle/db/dbs/UNNAMED00011到正确的文件：
ALTER DATABASE RENAME FILE '/oracle/db/dbs/UNNAMED00011' TO '/orcldata/ocr7.dbf';
执行不成功：oracle提示无法找到/orcldata/ocr7.dbf，这是由于系统上没有/orcldata/ocr7.dbf文件。
在操作系统touch一个文件 /orcldata/ocr7.dbf
再次执行ALTER DATABASE RENAME FILE '/oracle/db/dbs/UNNAMED00011' TO '/orcldata/ocr7.dbf';
修改成功，再次尝试开始启动日志应用：
alter database recover managed standby database disconnect from session;
执行不成功：提示11号数据文件需要恢复。
但是在检查进程，和日志应用情况，发现依然没有应用
SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
---APPLIED为no的日志依然从80929开始。
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;-- 无MRP0进程
至此，陷入僵局，根据提示使用以下命令恢复数据库 recover database，recover datafile 11都失败。
后根据错误号查询metlink，根据oracle官网提示，出现这种情况的解决方案是：当备库日志应用出现异常文件
/oracle/db/dbs/UNNAMED00011
应该通过以下方法解决
-----------------------------------------------------------------------------------------------------------------------------------
ALTER SYSTEM SET standby_file_management='MANUAL' SCOPE=BOTH;
alter database create datafile '/oracle/db/dbs/UNNAMED00011' as '/orcldata/ocr7.dbf';
--即通过异常文件创建出需要应用的正确文件名。
ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH;
ALTER DATABASE RECOVER managed standby database disconnect from session
-----------------------------------------------------------------------------------------------------------------------------------
由于之前通过rename数据文件名：
ALTER DATABASE RENAME FILE '/oracle/db/dbs/UNNAMED00011' TO '/orcldata/ocr7.dbf';
再次检查，select name,file# from v$datafile;
发现11好文件对应已经是正常的文件：/orcldata/ocr7.dbf，即无法通过官网提示的解决方案操作。
试图通过rename 操作复用以前的情况：ALTER DATABASE RENAME FILE '/orcldata/ocr7.dbf'
TO ' /oracle/db/dbs/UNNAMED00011';
提示不成功，因为没有文件/oracle/db/dbs/UNNAMED00011，该文件在操作系统下本来不存在。
再尝试将/oracle/db/dbs/UNNAMED00011 rename 到另外一个文件 /orcldata/ocr8.dbf，然后
将/orcldata/ocr8.dbf rename 到 /orcldata/ocr7.dbf，方案依然失败，如下：
ALTER DATABASE RENAME FILE '/oracle/db/dbs/UNNAMED00011' TO '/orcldata/ocr8.dbf';
ALTER DATABASE RENAME FILE '/orcldata/ocr7.dbf' TO '/orcldata/ocr8.dbf';
最终解决办法，见（四 解决方案 2）
四 最终解决方案
1 当主库添加数据文件，备库无法应用，在$ORACLE_HOME/dbs目录下产生UNNAMED000N文件时候，参考以下解决方案：
启动备库到日志应用状态报错：
Sun Jul 5 23:28:23 2009
Media Recovery Log /opt/oracle/archivelog/1_47_689973859.dbf
Media Recovery Log /opt/oracle/archivelog/1_48_689973859.dbf
Media Recovery Log /opt/oracle/archivelog/1_49_689973859.dbf
WARNING: File being created with same name as in Primary
Existing file may be overwritten
File #5 added to control file as 'UNNAMED00005'.
Originally created as:
'/opt/oracle/oradata/mmstest/test01.dbf'
Recovery was unable to create the file as:
'/opt/oracle/oradata/mmstest/test01.dbf'
Errors with log /opt/oracle/archivelog/1_49_689973859.dbf
出现此种情况，进一步的告警日志可能会报出如下错误：
Sun Jul 5 23:28:28 2009
Errors in file /opt/oracle/admin/mmstest/bdump/mmstest_mrp0_32062.trc:
ORA-19502: write error on file "/opt/oracle/oradata/mmstest/test01.dbf", blockno 1024 (blocksize=8192)
ORA-27072: File I/O error
Linux Error: 9: Bad file descriptor
Additional information: 4
Additional information: 1024
Additional information: 397312
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Sun Jul 5 23:28:29 2009
Errors in file /opt/oracle/admin/mmstest/bdump/mmstest_mrp0_32062.trc:
ORA-19502: write error on file "/opt/oracle/oradata/mmstest/test01.dbf", blockno 1024 (blocksize=8192)
ORA-27072: File I/O error
Linux Error: 9: Bad file descriptor
Additional information: 4
Additional information: 1024
Additional information: 397312
以及尝试recover时可能再次出现：
Mon Jul 6 01:36:30 2009
Errors in file /opt/oracle/admin/mmstest/bdump/mmstest_mrp0_32589.trc:
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/opt/oracle/product/10.2.0/dbs/UNNAMED00005'
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/opt/oracle/product/10.2.0/dbs/UNNAMED00005'
出现这些错误时MRP进程会停止工作，恢复中断：
Mon Jul 6 01:36:30 2009
MRP0: Background Media Recovery process shutdown (mmstest)
在修正相关的问题之后，我们可以进行如下一系列的操作来恢复这些错误：
SQL> alter system set standby_file_management=manual;
System altered.
SQL> alter database create datafile
2 '/opt/oracle/product/10.2.0/dbs/UNNAMED00005' as '/opt/oracle/oradata/mmstest/test01.dbf';
Database altered.
SQL> alter system set standby_file_management=auto;
System altered.
SQL> recover managed standby database disconnect from session;
Media recovery complete.
此时备库的恢复得以继续：
Mon Jul 6 01:41:14 2009
ALTER SYSTEM SET standby_file_management='MANUAL' SCOPE=MEMORY;
Mon Jul 6 01:42:13 2009
alter database create datafile
'/opt/oracle/product/10.2.0/dbs/UNNAMED00005' as '/opt/oracle/oradata/mmstest/test01.dbf'
Mon Jul 6 01:42:14 2009
Completed: alter database create datafile
'/opt/oracle/product/10.2.0/dbs/UNNAMED00005' as '/opt/oracle/oradata/mmstest/test01.dbf'
Mon Jul 6 01:42:26 2009
ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=MEMORY;
Mon Jul 6 01:42:40 2009
ALTER DATABASE RECOVER managed standby database disconnect from session
Mon Jul 6 01:42:40 2009
Attempt to start background Managed Standby Recovery process (mmstest)
MRP0 started with pid=16, OS id=32607
Mon Jul 6 01:42:41 2009
MRP0: Background Managed Standby Recovery process started (mmstest)
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 3 processes
Media Recovery Log /opt/oracle/archivelog/1_49_689973859.dbf
Mon Jul 6 01:42:47 2009
Completed: ALTER DATABASE RECOVER managed standby database disconnect from session
Mon Jul 6 01:43:02 2009
Media Recovery Log /opt/oracle/archivelog/1_50_689973859.dbf
Mon Jul 6 01:43:17 2009
Media Recovery Log /opt/oracle/archivelog/1_51_689973859.dbf
Mon Jul 6 01:43:32 2009
Media Recovery Log /opt/oracle/archivelog/1_52_689973859.dbf
Mon Jul 6 01:43:45 2009
Media Recovery Log /opt/oracle/archivelog/1_53_689973859.dbf
正常情况下的配置及文件创建，其提示应该类似如下过程：
Mon Jul 6 01:53:28 2009
WARNING: File being created with same name as in Primary
Existing file may be overwritten
Recovery created file /opt/oracle/oradata/mmstest/wztest02.dbf
Successfully added datafile 7 to media recovery
Datafile #7: '/opt/oracle/oradata/mmstest/wztest02.dbf'
Media Recovery Log /opt/oracle/archivelog/1_80_689973859.dbf
在这个测试环境中，是由于空间不足导致的文件创建失败。
注意，在以上步骤中，如果standby_file_management设置为AUTO时，执行create命令会遇到如下错误：
SQL> alter database rename
2 file '/opt/oracle/product/10.2.0/dbs/UNNAMED00005' to '/opt/oracle/oradata/mmstest/test01.dbf';
alter database rename
*
ERROR at line 1:
ORA-01511: error in renaming log/data files
ORA-01275: Operation RENAME is not allowed if standby file management is automatic.
2 由于报错提示一个数据文件异常，可以采取恢复备库单个数据文件的办法。
主库先备份对应数据文件的备份copy，再创建一个standby控制文件
在备库端，先使用主库产生的standby控制文件，重命名到参数文件中记录的控制文件指向：
/orcldata/control01.ctl和/orcldata/control02.ctl
启动备库到mount状态，恢复11号数据文件 recover datafile 11
具体步骤是：
主库端：
主库先备份一个数据文件的映像
rman target /
backup as copy datafile '/orcldata/ocr7.dbf' format='/orcldata/ocr7_stb';
sqlplus / as sysdba
主库生成standby控制文件：
alter database create standby controlfile as '/orcldata/control_stb.ctl';
ftp control_stb.ctl和 ocr7_stb到备库
备库：
备份备库原有的控制文件
cp /orcldata/control01.ctl /oradata
cp /orcllog/control02.ctl /oradata
使用主库生成的statdby控制文件：control_stb.ctl
cp /orcldata/control_stb.ctl /orcldata/control01.ctl
cp /orcldata/control_stb.ctl /orcllog/control02.ctl
启动数据库到mount：
startup pfile='/orcldata/initorcl.int' mount;
查询需要恢复的数据文件：
select ERROR from v$recover_file;
提示 11号文件需要恢复
recover datafile 11
提示需要使用当前的日志文件，再执行以下命令
alter database recover managed standby database using current logfile disconnect from session;
提示需要先取消应用
alter database recover managed standby database cancel
再执行recover datafile 11
--recover managed standby database;
成功，日志逐渐恢复
ok....
查看alter日志动态变化，逐个应用归档日志，约过半小时，没有应用的日志全部应用完毕
在主库切换日志，备库正常应用，至此解决问题。