問題描述：主庫備庫之前正常連接，但是昨天磁盤空間滿了之後，由於不知什麽原因將備庫重做日誌刪了，今天早上發現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;也可以查看信息

DG不同步，MRP0進程打不開