本帖最后由 yuanqk 于 2018-8-11 20:28 编辑

真实案例，记录一下，都是小白，非常理解小白在遇到问题时的无奈，希望能帮助到一些人。过程非常简单，主要是处理问题的思路。

1、早上收到告警，说备库有15个归档没有同步，我们的告警还是非常low的那种，只能告诉你有几个归档没同步，具体原因不知道。(这也是我后续需要调整的)

2、检查具体原因，登录主库，查看dest状态，确实是有问题，不能创建归档日志了。

SQL> select status,gap_status,error from v$archive_dest_status;

STATUS                      GAP_STATUS                                                               ERROR

--------------------------- ------------------------------------------------------------------------ ------------------------------------------

VALID

ERROR                       RESOLVABLE GAP                                                           ORA-00270: error creating archive log

3、登录备库，检查alert日志，看到db_recovery_file_dest_size使用率100%

Creating archive destination file : /opt/app/oracle/oradata/xxxxxx/o1_mf_1_2990_%u_.arc (1176113 blocks)

Sat Aug 11 13:02:50 2018

Errors in file /u01/app/oracle/diag/rdbms/xxxxxxxxxxx/trace/xxxxxx_rfs_20130.trc:

ORA-19815: WARNING: db_recovery_file_dest_size of 101295421440 bytes is 100.00% used, and has 0 remaining bytes available.

4、从现象上看问题很简单，调整这个目录大小就行了，调整之后看归档文件，缺少的也都同步过来了

ALTER SYSTEM SET db_recovery_file_dest_size='300G' SCOPE=BOTH;

5、看似很ok，启动应用进程吧，结果启动后又报了一个错

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE  DISCONNECT FROM SESSION;

ORA-01186: file 50 failed verification tests

ORA-01157: cannot identify/lock data file 50 - see DBWR trace file

ORA-01111: name for data file 50 is unknown - rename to correct file

ORA-01110: data file 50: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00050'

File 50 not verified due to error ORA-01157

MRP0: Background Media Recovery terminated with error 1111

6、这个报错也很简单，就是主备库数据文件路径不一致，而且在db_file_name_convert中也没有设置，这时就检查一下主库的数据文件路径，和备库的db_file_name_convert参数

结果确实是缺少了一个映射关系。

7、处理上面的问题，先到主库查看下file_id为50的数据文件信息，然后在备库执行下面的命令处理：

alter system set standby_file_management='MANUAL' SCOPE=MEMORY;

alter database create datafile '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00050' as '备库数据文件存放路径/主库查询出来的数据文件名称.dbf';

alter system set standby_file_management='AUTO' SCOPE=MEMORY;

8、在检查主库file_id为50的数据文件信息时，发现是8月3号创建的，那就是说8月3号这套dg就出问题了，当时心里一万个草拟马在奔腾(哎，我也不是圣人，正在医院挂号，突然回来替别人擦屁股)

检查一下备库日志应用情况，确定在2907的归档断了，再检查下归档目录，发现归档还全部都在。。。

2904 03-AUG-18       03-AUG-18       YES

2905 03-AUG-18       03-AUG-18       YES

2906 03-AUG-18       03-AUG-18       YES

2907 03-AUG-18       03-AUG-18       NO

2908 03-AUG-18       03-AUG-18       NO

2909 03-AUG-18       03-AUG-18       NO

9、确认问题都解决后启动恢复进程，慢慢恢复吧，反正又每人急着用，结果又报错了

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE  DISCONNECT FROM SESSION;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE  DISCONNECT FROM SESSION

*

ERROR at line 1:

ORA-01153: an incompatible media recovery is active

10、这个错误第一次遇到，查了官方文档也没明白。尝试关闭应用进程，再启用还是一样报错

SQL> alter database recover managed standby database cancel;

alter database recover managed standby database cancel

*

ERROR at line 1:

ORA-16136: Managed Standby Recovery not active

11、不知道怎么回事，尝试recover automatic standby database竟然成功了(这样一个一个归档去追很慢，可以考虑使用增量恢复)

alter database recover automatic standby database;

12、恢复完成后，启动应用进程

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE  DISCONNECT FROM SESSION;

13、最后别忘了修改db_file_name_convert和log_file_name_convert参数，这2个参数需要重启数据库。