知道这是Dataguard的特性，或者说主要功能之一。一般场景是，当主库某个数据文件损坏或丢失时，可以直接cp备库对应文件来恢复；反过来也是可以的。

想找找相关文档，没找到。查官方文档，也没有。那就只能自己测测了，最后测试成功。我测试的是后面一种情况，主要步骤如下：

Step 1,
On Primary DB,将问题数据文件所在表空间置于备份模式。
SQL> alter tablespace perfstat begin backup;

Tablespace altered.

Step 2,
On Standby DB,将备库关闭，或者置于其它状态，但备库不能处于恢复状态。

Step 3,
cp主库数据文件到对应备库文件所在目录

Step 4,
On Primary DB,cp完成后，将问题数据文件所在表空间置于正常模式。
SQL> alter tablespace perfstat end backup;

Tablespace altered.

Step 5,
On Standby DB,恢复问题数据文件
SQL> select name,status  from v$datafile where file#=70; --恢复前问题数据文件状态

NAME
--------------------------------------------------------------------------------
STATUS
-------
/d03/PROD/proddata/perfstat02.dbf
RECOVER

SQL> alter database mount standby database;

Database altered.

SQL> alter database datafile '/d03/PROD/proddata/perfstat02.dbf' online; --如果数据文件本身是online状态,可省略

Database altered.

SQL> recover managed standby database disconnect from session;
Media recovery complete.


SQL>  select name,status  from v$datafile where file#=70;

NAME
--------------------------------------------------------------------------------
STATUS
-------
/d03/PROD/proddata/perfstat02.dbf
ONLINE

如果上面recover完成后,数据文件状态任未变化(如果数据文件无需恢复的话,也就是checkpoint与其它数据文件一样,可能出现此现象),可以open read only一下,让数据库能主动去check.
SQL>  recover managed standby database  cancel;
Media recovery complete.
SQL> alter database open read only;

Database altered.


SQL>  select name,status  from v$datafile where file#=70;

NAME
--------------------------------------------------------------------------------
STATUS
-------
/d03/PROD/proddata/perfstat02.dbf
ONLINE

整个动作完成.前面文章解决ORA-01272错误时,见下链接.如果需apply 日志过大时,或者日志不全时,可以使用上面方法恢复.
hi.baidu.com/flying_hg/blog/item/036c9330b8c0a593a8018e27.html