問題描述：主庫備庫之前正常連接，但是昨天磁碟空間滿了之後，由於不知什麼原因將備庫重做日誌刪了，今天早上發現DG不同步的報警。 當時思路如下：1、通過select thread#,low_sequence#,high_sequence# from v$archive_gap; 查看是否有歸檔沒有傳到備 ...
問題描述：主庫備庫之前正常連接，但是昨天磁碟空間滿了之後，由於不知什麼原因將備庫重做日誌刪了，今天早上發現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;也可以查看信息
