ORA-01111,ORA-01110,ORA-01157报错处理

客户一套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，问题圆满解决！