oracle dataguard 配置錯誤彙總

    公司內部現在用DG作為oracle的高可用架構較多，之前部署的時候出現過一些問題，每次問題可能都不一致，這裡將DG搭建過程遇到的錯誤做個彙總文章，後續如有遇到類似的問題，可以做個參考。
    （持續更新中）
   一、ORA-16401、ORA-16032
    現象描述：
    資料庫恢復沒問題，但主庫做重做日誌切換，歸檔無法傳輸至備庫。但在備庫重啟的情況下，日誌會傳輸至備庫並完成應用。
    錯誤日誌：
    Wed Dec 21 18:27:07 2016
    Errors in file /U01/app/oracle/admin/ora2/bdump/ora2_arc0_3721.trc:
    ORA-16401: archivelog rejected by RFS
    Wed Dec 21 18:28:07 2016
    ARC0: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)
    ARC0: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
    PING[ARC0]: Error 3113 when pinging standby ora2c.

    跟蹤檔案：
    *** 2016-12-21 18:17:49.159 66535 kcrr.c
    Logged on to standby successfully
    Client logon and security negotiation successful!
    ABC: tkrsf_al_read: No mirror copies to re-read data
    ABC: tkrsf_al_read: No mirror copies to re-read data
    ABC: tkrsf_al_read: No mirror copies to re-read data
    ABC: tkrsf_al_read: No mirror copies to re-read data
    ABC: tkrsf_al_read: No mirror copies to re-read data
    *** 2016-12-21 18:18:07.669
    tkcrrsarc: (WARN) Failed to find ARCH for message (message:0x2)
    tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message:0x2)
    ABC: tkrsf_al_read: No mirror copies to re-read data
    *** 2016-12-21 18:18:20.883
    ABC: tkrsf_al_read: No mirror copies to re-read data
    *** 2016-12-21 18:19:11.570
    ABC: tkrsf_al_read: No mirror copies to re-read data
    *** 2016-12-21 18:20:07.715
    tkcrrsarc: (WARN) Failed to find ARCH for message (message:0x2)
    tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message:0x2)
    Error 16401 creating standby archive log file at host 'ora2c'
    ORA-16401: archivelog rejected by RFS
    錯誤原因：
    由於主庫是從一備庫切換完成的，其log_archive_config配置的是原來的unique name，而在做主從部署的時候，先調整了log_archive_dest_2（遠端歸檔傳輸路徑），然後又調整了log_archive_config，從而導致LOG_ARCHIVE_DEST_N引數生效的時候無法從DG_CONFIG中獲取到對應的配置，導致了ORA-16032、ORA-16401的錯誤。
    也有可能是歸檔程式不足導致，可以透過alter system set log_archive_max_processes=4 scope=both;調整歸檔程式解決。
    解決方案：
    要避免這個錯誤很簡單，只需要先配置LOG_ARCHIVE_CONFIG，然後再配置LOG_ARCHIVE_DEST_N引數既可。
    對於已經出現的這個錯誤，只需要透過引數LOG_ARCHIVE_DEST_STATE_N暫停日誌，隨後在啟用，Oracle就會重新分析LOG_ARCHIVE_DEST_N中的配置
    ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=BOTH;
    ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=BOTH;
    重啟測試主備的歸檔同步，正常。
 
   二、ORA-16625
    現象描述：
    主備切換透過手動切換，而不是透過dg broker做的切換，那麼在切換後dg broker配置資訊損壞，無法透過remove,disable的方式清理dg broker的配置。
    
    錯誤日誌：
    DGMGRL> show configuration;
    Configuration
      Name:                ora2
      Enabled:             YES
      Protection Mode:     MaxPerformance
      Fast-Start Failover: DISABLED
      Databases:
        ora2n - Primary database
        ora2s - Physical standby database
    Current status for "ora2":
    Error: ORA-16625: cannot reach the database   

    錯誤原因：
    主備切換透過手動切換，而不是透過dg broker做的切換，那麼在切換後dg broker配置資訊損壞，需要清理掉重新配置。由於原主庫已經不可達，因此透過remove,disable的方式已經無法完成。那麼我們就需要手動清理dg broker的配置。
    解決方案：
    停掉dg broker配置，手動刪除dg broker的配置檔案，開啟dg broker配置即可。
    sys@ora2> show parameter dg_broker_start   ;

    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- ------------------------------
    dg_broker_start                      boolean     TRUE
    sys@ora2> alter system set dg_broker_start =false scope=both;

    System altered.

    cd $ORACLE_HOME/dbs
    rm -rf dr*

    sys@ora2>  alter system set dg_broker_start =true scope=both;                                                                    
    System altered.

    DGMGRL> show configuration;
    Error: ORA-16532: Data Guard broker configuration does not exist
    Configuration details cannot be determined by DGMGRL