客户一套AIX平台的9208的DG灾备端报归档日志不能正常应用，从alert日志观察到有如下报错：

ORA-01111: name for data file 13 is unknown – rename to correct file
ORA-01110: data file 13: ‘/u01/app/oracle/oradata/fapdb/UNNAMED0013′
ORA-01157: cannot identify/lock data file 13 – see DBWR trace file

跟客户沟通下来了解到7号应用那边对生产数据库某一表空间增加了一个裸设备文件，通过查询生产数据库确定13号数据文件即7号添加的裸设备文件，照理说不会出现这种情况，由于有2套灾备standby库，出问题的这套是上海的，另一套在深圳，登陆查看深圳那套备库没有问题。我深信该问题肯定是由于上海灾备端的数据文件转换参数有问题，因为standby的数据文件都是同一放在/oradata/fapdb下面的。

通过查询standby数据库的db_file_name_convert参数发现这个参数确实设置的有问题，设反了！！这一个小问题可能会导致一个很严重的生产事故。

在确认问题后以及确认文件号与文件的关系后通过如下命令对该数据文件进行了重建。

alter system set standby_file_management=manual;
alter database create datafile  ‘/oradata/fapdb/dcept01.dbf’ as ‘/u01/app/oracle/oradata/fapdb/UNNAMED0013′;
alter system set standby_file_management=auto;
alter database recover managed standby database disconnect from session;

改是改完了但是在我想应用未应用的日志时客户跟我说他们的归档只保留5天，我操~这不玩我么，备份策略很是有问题，连没应用的规档都给清了，怎么办？2个办法 要么这套DG重搭，要么使用增量备份前滚standby，由于考虑到该库只有九十多G的大小以及要对生产减小到最小的影响，故采用重新搭建该DG的方式解决了该问题。

 

在做恢复的过程中对客户其余8套灾备数据库的参数也做了一个检查，发现灾备端的db_file_name_convert和log_file_name_convert全部设反了~~OH MY GAD!这个工程师怎么搭的DG 啊。。。。犯这么低级的错误~~

既然发现了问题，全部改正~

OK，问题圆满解决！