一、問題概述
某客戶11.2.0.4 linux 環境，dg備庫檢查同步是否正常，以下為完整流程；
1) 通過主庫檢查dg 連通性，一切正常；
2）查詢dg 觀察mrp status 處於 WAIT_FOR_LOG；
3）檢查發現延遲幾十天？？？
4）再次檢查，發現wait_for_log sequence# 與主庫最新的歸檔相差幾十天！
5) 重啟dg,重新開啟Mrp進程，dg恢復
二、問題分析
1) 通過主庫檢查dg 連通性，一切正常；
SQL> select DEST_NAME , STATUS , RECOVERY_MODE from v$archive_dest_status; DEST_NAME STATUS RECOVERY_MODE ---------------------------------------- --------- ----------------------- LOG_ARCHIVE_DEST_6 VALID MANAGED SQL> select dest_id,error from v$archive_dest; DEST_ID ERROR ---------- ----------------------------------------------------------------- 6
2）查詢dg 觀察mrp status 處於 WAIT_FOR_LOG；
select process,client_process,sequence#,status,BLOCK#,BLOCKS from v$managed_standby; PROCESS CLIENT_P SEQUENCE# STATUS BLOCK# BLOCKS --------- -------- ---------- ------------ ---------- ---------- RFS LGWR 205192 IDLE 11 1 MRP0 N/A 205016 WAIT_FOR_LOG 0 0
3）檢查發現延遲幾十天？？？
select name,value,unit,time_computed from v$dataguard_stats where name in ('transport lag','apply lag'); NAME VALUE UNIT TIME_COMPUTED -------------------- -------------------- ------------------------------ ------------------------------ transport lag +00 00:00:00 day(2) to second(0) interval 04/20/2021 11:18:34 apply lag +74 12:14:19 day(2) to second(0) interval 04/20/2021 11:18:34
TRANSPORT LAG - Transport lag is a measure of the degree to which the transport of redo to the standby database lags behind
the generation of redo on the primary database. If there are one or more redo gaps on the standby database,
the transport lag is calculated as if no redo has been received after the beginning of the earliest redo gap. 如果GAP，則計算延遲時間
APPLY LAG - Apply lag is a measure of the degree to which the data in a standby database lags behind the data
in the primary database, due to delays in propagating and applying redo to the standby database. This value is
relevent only to the applying instance.
時間取決於主備之間的數據傳輸的延遲 or DG應用歸檔日志與主庫最新日志的延遲時間
4）再次檢查，發現wait_for_log sequence# 與主庫最新的歸檔相差幾十天！
select process,client_process,sequence#,status,BLOCK#,BLOCKS from v$managed_standby; PROCESS CLIENT_P SEQUENCE# STATUS BLOCK# BLOCKS --------- -------- ---------- ------------ ---------- ---------- RFS LGWR 205192 IDLE 11 1 MRP0 N/A 205016 WAIT_FOR_LOG 0 0
5) 重啟dg,重新開啟Mrp進程，dg恢復
檢查發現DG 一直正常接收主庫傳輸的歸檔日志，但是MRP進程並未應用！
$ ls -lrt total 40500044 drwxr-x---. 3 oracle oinstall 24 Jun 15 2019 ORCL -rw-r-----. 1 oracle oinstall 394691584 Feb 4 23:04 1_205015_848250756.dbf -rw-r-----. 1 oracle oinstall 24641536 Feb 5 09:03 1_205016_848250756.dbf -rw-r-----. 1 oracle oinstall 2956288 Feb 5 09:03 1_205018_848250756.dbf -rw-r-----. 1 oracle oinstall 45406208 Feb 5 09:06 1_205017_848250756.dbf
檢查主庫歸檔日志的情況，主庫歸檔日志已刪除，其它線程已傳輸至2個dg庫 select SEQUENCE#,to_char(FIRST_TIME,'yyyy-mm-dd hh24:mi:ss') as "date",name,status from v$archived_log where sequence#=205016; SEQUENCE# date NAME S ---------- ------------------- -------------------- - 205016 2021-02-04 23:13:34 D 205016 2021-02-04 23:13:34 dg1 A 205016 2021-02-04 23:13:34 dg2_tns A select name,status from v$archived_log where sequence#=205016; NAME S -------------------- - /oradata/flash_recovery_area/1_205016_848250756.dbf A Completed: ALTER DATABASE RECOVER managed standby database using current logfile disconnect select process,client_process,sequence#,status,BLOCK#,BLOCKS from v$managed_standby; PROCESS CLIENT_P SEQUENCE# STATUS BLOCK# BLOCKS --------- -------- ---------- ------------ ---------- ---------- MRP0 N/A 205020 APPLYING_LOG 280 281 ······ MRP0 N/A 205022 APPLYING_LOG 179675 821187 ······ select name,value,unit,time_computed from v$dataguard_stats where name in ('transport lag','apply lag'); NAME VALUE UNIT TIME_COMPUTED -------------------- -------------------- ------------------------------ ------------------------------ transport lag +00 00:00:00 day(2) to second(0) interval 04/20/2021 12:36:36 apply lag +00 00:00:00 day(2) to second(0) interval 04/20/2021 12:36:36