DataGuard故障：Standby日誌檔案正常傳輸但沒有Apply

hooca發表於2016-03-10
APP
OS：Linux
DB：Oracle 11.2.0.3

客戶有一套DG資料庫，Primary端是一套RAC+ASM，Standby端是單例項+ASM。屢次發生DG兩端不同步，standby端停止跟進的情況，表現為v$database中的current_scn欄位停止更新。但檢視日誌序列號，卻發現能夠與Primary同步

點選(此處)摺疊或開啟

  1. SELECT PROCESS, CLIENT_PROCESS,THREAD#, SEQUENCE#,STATUS
  2. FROM V$MANAGED_STANDBY;

PROCESS  CLIENT_PROCESS      THREAD#  SEQUENCE# STATUS
-------- ---------------- ---------- ---------- --------------------
ARCH     ARCH                      1        120 CLOSING
ARCH     ARCH                      1        119 CLOSING
ARCH     ARCH                      0          0 CONNECTED
ARCH     ARCH                      1        121 CLOSING
RFS      UNKNOWN                   0          0 IDLE
RFS      LGWR                      1        122 IDLE
RFS      UNKNOWN                   0          0 IDLE
MRP0     N/A                       1        122 APPLYING_LOG
同時，在歸檔日誌路徑下也確實能夠找到最新的歸檔日誌檔案。

該情況，在1個月的時間裡大約每隔一、兩週發生。

根據文件ID：1665814.1

導致該問題的原因是Standby端引數log_archive_dest_N做了多餘的配置，並且說明該問題會間歇性發生（原文：This happens intermitantly several times a week. ）

檢查Standby端的相關引數：

點選(此處)摺疊或開啟

  1. SQL> show parameter log_archive_dest_

  3. NAME                                 TYPE        VALUE
  4. ------------------------------------ ----------- ------------------------------
  5. log_archive_dest_1 string                        LOCATION=USE_DB_RECOVERY_FILE_
  6.                                                  DEST VALID_FOR=(ALL_LOGFILES,A
  7.                                                  LL_ROLES) DB_UNIQUE_NAME=SIMU
  8. log_archive_dest_10 string
  9. log_archive_dest_11 string
  10. log_archive_dest_12 string
  11. log_archive_dest_13 string
  12. log_archive_dest_14 string
  13. log_archive_dest_15 string
  14. log_archive_dest_16 string
  15. log_archive_dest_17 string

    1. NAME                                 TYPE        VALUE
  18. ------------------------------------ ----------- ------------------------------
  19. log_archive_dest_18 string
  20. log_archive_dest_19 string
  21. log_archive_dest_2 string                        service=simu LGWR ASYNC
  22.                                                              valid_for=(ONLINE_
  23.                                                  LOGFILES,PRIMARY_ROLE)
  24.                                                            db_unique_name=simu
在上例中，log_archive_dest_1因為在部署時，把Primary端的設定“拿”來用了，而該引數在Primary端就不應該設定。

解決方法，將該引數設定為空

點選(此處)摺疊或開啟

  1. SQL> alter system set log_archive_dest_1='' scope=spfile;

  3. SQL> shutdown immediate
  4. SQL> startup
重啟後，current_scn立即開始跟進，最終完成同步，問題解決。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/22621861/viewspace-2054538/，如需轉載，請註明出處，否則將追究法律責任。

相關文章