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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/27067062/viewspace-2131174/，如需转载，请注明出处，否则将追究法律责任。