问题描述：主库备库之前正常连接，但是昨天磁盘空间满了之后，由于不知什么原因将备库重做日志删了，今天早上发现DG不同步的报警。

　　当时思路如下：1、通过select thread#,low_sequence#,high_sequence# from v$archive_gap; 查看是否有归档没有传到备库上去，当时查询结果为  no rows selected。表示主备库归档日志都是同步的。

　　　　　　　　　2、然后select sequence#,creator,archived,applied from v$archived_log ;查看备库的日志是不是都有应用到主库上面去。结果如下：

                                       

　　　　　　　　　　原因就是备库的归档日志没有应用到备库上面。然后我使用alter database recover managed standby database disconnect from session.来启动应用日志。但结果就是没有MRP0进程。

　　　　　　　　　　也不能通过alter database recover managed standby database cancel;来取消应用日志，他会报没有恢复备库的错误。

　　　　　　　　　　然后通过查看警告日志。

                                       

　　　　　　　　　　发现是因为重做日志不知道什么时候被删除了。

　　　　　　　　　　然后首先通过alter system set  standby_file_management='manual';将该参数设为手动的。

　　　　　　　　　　通过 ALTER DATABASE RENAME FILE '/u1/oradata/FTNFUSE1/redo01a.log' to '/u1/oradata/FTNFUSE1/redo1a.log';

　　　　　　　　　　现将日志重命名，这样可以在指定的路径生成日志文件，再通过alter database clear logfile group 1,

　　　　　　　　　　将日志组1的状态改为clearing。

　　　　　　　　　　通过select GROUP#,members,BYTES/1024/1024 size_M,STATUS,ARCHIVED from v$log; 查询日志组的状态及大小。

　　　　　　　　　　3、这是重做日志建好了，执行alter system set  standby_file_management='auto'将参数改为自动的。

　　　　　　　　　　然后执行alter database recover managed standby database disconnect from session.打开应用日志，

　　　　　　　　　　通过执行 select process,sequence#,status from v$managed_standby;发现MRP0进程还是没有开启。

　　　　　　　　　　只有又去看警告日志。

                                       　

　　　　　　　　　　发现其中一行报的是恢复 Media Recovery Log /u2/arch/1_3775_947332915.dbf 出现错误。

　　　　　　　　　　我想着主库的这个归档文件应该是没问题的，将主库的归档文件拷贝到备库，然后在通过

　　　　　　　　　　alter database recover managed standby database disconnect from session.打开应用日志。

　　　　　　　　　　通过执行 select process,sequence#,status from v$managed_standby查看各个进程是不是正常的。结果正常。

　　　　　　　　　       　

　　　　　　　　　　图中是将归档日志复制过来之后，注册日志的。因为已经注册过了，所以会报这个错误。但是如果这个日志文件是坏的，那么他就会报其他错误，当时忘记截图了。

　　　　　　　　　　select message from v$dataguard_status;也可以查看信息