一、问题描述

使用rman auxiliary 方式部署DG时，数据恢复了一段时间，突然被中断，查看报错原因，显示报错内容如下：

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 12/01/2023 12:44:56
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script

RMAN-03009: failure of backup command on ORA_DISK_1 channel at 12/03/2021 12:43:03
ORA-17628: Oracle error 19505 returned by remote Oracle server
复制

二、处理过程

根据报错信息 ORA-17628: Oracle error 19505 returned by remote Oracle server 登陆 MOS 查询到该问题其实是一个BUG(Bug 12609412 : ORA-17628 ORA-19505 DURING DUPLICATE FROM ACTIVE),存在于Oracle Enterprise 11.1.0.7 版本及之后，报错的原因是因为主库有数据文件采用了非OMF命名，而是使用了带有其它后缀的命名方式。

登陆该数据库主库，查看到主库是使用OMF管理，通过select tablespace_name,file_name from dba_data_files;语句查询到主库确实有个表空间使用了.dbf命名格式

SQL> select tablespace_name,file_name from dba_data_files;
SYSTEM                   +DATA/XXXX/datafile/system.273.1059923331
SYSAUX                   +DATA/XXXX/datafile/sysaux.272.1059923297
UNDOTBS1                 +DATA/XXXX/datafile/undotbs1.264.1059921737
T_XXXX_IDX               +DATA/XXXX/datafile/t_XXXX_idx.266.1059922347
USERS                    +DATA/XXXX/datafile/users.276.1059923407
T_XXXX                   +DATA/XXXX/datafile/t_XXXX.259.1059920141
T_XXXX                   +DATA/XXXX/datafile/t_XXXX.260.1059920455
T_XXXX                   +DATA/XXXX/datafile/t_XXXX.261.1059920781
T_XXXX                   +DATA/XXXX/datafile/t_XXXX.262.1059921095
T_XXXX_IDX               +DATA/XXXX/datafile/t_XXXX_idx.268.1059922797
xxx_CORE                 +DATA/XXXX/datafile/xxx_core.258.1059919525
T_xxxQB                  +DATA/XXXX/datafile/t_xxxqb.dbf
复制

虽然主备库都设置了db_file_name_convert=’+data’,’+data’，但依然无法避免该问题，MOS上给出了两个解决方案：(1) 使用参数DB_FILE_NAME_CONVERT并使用别名指定数据文件的完整位置；(2)在备库的磁盘组中创建和原库一样的文件路径.

本次尝试在备库ASM中创建和主库 xxx.dbf相同路径的目录。

然后备库重新使用pfile文件启动到nomount,再通过duplicate target database for standby from active database nofilenamecheck;恢复数据。

按照此方式重新恢复数据，正常执行，没有再报错。