周末一个下午，接到公司领导安排说某局的一个库主备不一致了，由于备库查询功能，导致不能查到新数据，需要及时处理，当时我只能开车直接去公司有内网机器处理。其实，大家可以想想如果遇到这样的问题，该如何思考，一般是日志gap，解决Gap，这是常规的想法，其实我当时也是，下面是我的处理过程。当时情况有点紧急，对方要求尽快恢复。
1 我们查看了备库是否有日志gap，没有结果，也就是主备日志是传递过来的。
select * from v$archive_gap;
2 既然日志在备库，为何没有使用呢，我们知道这个用日志的进程有mrp进程负责，下面查新该进程
ps -ef | grep mrp
select process,status,sequence# from v$managed_standby
没有发现MRP进程，这就是问题的进一步根源，MRP异常终止。
3 查询数据库告警日志。
发现在3天前有个记录如下所示
ORA-01119: error in creating database file '+data'
ORA-17502:ksfdcre:4 Failed to create file +data
ORA-15041: diskgroup 'DATA' space exhausted
File #64 added to control file as 'unnamed00064'
Originally created as :
'+DATA/ddx/datafile/opms.325.10512334334'
Recovery was unable to create the file as : '+data'
MRP0:Background Media Recovery terminated with error 1274
ORA-01274:cannot add datafile '+DATA/ddx/datafile/opms.325.10512334334' - file could not be created
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovered data files to a consistent state at change 16458842540422
MRP0: Background Media Recovery Process shutdown (ddx)
从告警日志我们知道，主库创建了一个数据文件，但是该数据文件在备库由于空间问题没有创建成功，Oracle默认将该文件记录下控制文件中，名字为$ORACLE_HOME/dbs/unnamed00064.dbf
而该文件不存在，无法恢复。
需要做两件事
1 扩容ASM磁盘组，这个需要用户到现场去扩盘。
2 扩容后处理问题文件，重建该文件，启动MRP进程做恢复，这个过程我们详细说下
关闭数据库，启动到Mount阶段
alter system set standby_file_management=manual；
alter database create datafile '/oracle/app/oracle/product/11.2.0/dbs/UNNAMED00064' as ''+DATA/ddx/datafile/db1.dbf';
alter database open <<<<此时只读，没有Apply日志
alter database recover managed standby database using current logfile disconnect from session; <<<<< 启动MRP进程恢复数据
由于这个文件日志恢复需要3天的数据，大约恢复了30分钟，主备就一致了。
这个案例的启示： 主库和备库必须具有相同的配置，包括空间大小，我建议将convert参数也配置好，及时主备环境一致，这样号排查问题。
