问题描述：主库备库之前正常连接，但是昨天磁盘空间满了之后，由于不知什么原因将备库重做日志删了，今天早上发现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;也可以查看信息