Oracle ADG Heartbeat failed to connect to standby故障案例

    客戶的主資料庫是一套Oracle Database 11gR2 for AIX的單機資料庫，在系統層面部署了IBM HACMP軟體，將該資料庫做成了能在兩臺物理機之間切換的主備模式，並且為該資料庫實施了ADG。客戶將主資料庫切換到備用伺服器之後，主資料庫與備用資料庫不再同步，在資料庫的告警日誌中收到如下告警：
Fri Mar 13 02:28:00 2015
PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.  <<<<  注意錯誤編號。
Fri Mar 13 02:29:01 2015
PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.
Fri Mar 13 02:30:01 2015
PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.
Fri Mar 13 02:31:02 2015
PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.
Fri Mar 13 02:32:02 2015
PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.
Fri Mar 13 02:33:02 2015
PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.
Fri Mar 13 02:34:03 2015
PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.
Fri Mar 13 02:35:03 2015
PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.
Fri Mar 13 02:36:04 2015
PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.

   以上告警在ADG的環境中已經多次遇到，請注意類似報錯的錯誤ID，這裡的ID是16057，Oracle對該錯誤是這樣解釋的：
ORA-16057: DGID from server not in Data Guard configuration
在MOS中找到如下文章：

Primary Remote log shipping failing with ORA-16057 - Server not in Data Guard configuration (Doc ID 1570928.1)

In this Document

Symptoms

Cause

Solution

---

Applies to:

Oracle Database - Enterprise Edition - Version 12.1.0.1 and later
Information in this document applies to any platform.

Symptoms

 ------------Primary Alert log-----------------
Thu Jul 11 16:28:16 2013
ALTER SYSTEM SET log_archive_dest_2='service=chicago async valid_for=(all_logfiles,primary_role) db_unique_name=chicago'

SCOPE=BOTH;
Thu Jul 11 16:28:17 2013
PING[ARC1]: Heartbeat failed to connect to standby 'chicago'. Error is 16057..'
..
.
Error 16057 for archive log file 1 to 'chicago'
Thu Jul 11 16:28:19 2013
Errors in file /u01/app/oracle/diag/rdbms/boston/boston/trace/boston_tt01_6296.trc:
ORA-16057: server not in Data Guard configuration


@primary,

SQL> col error for a30
SQL> select dest_id,error,status,log_sequence,applied_scn from v$archive_dest where dest_id=2;

   DEST_ID ERROR                          STATUS    LOG_SEQUENCE APPLIED_SCN
---------- ------------------------------ --------- ------------ -----------
         2 ORA-16057: server not in Data  ERROR               61           0
           Guard configuration

Cause

log_archive_config not set.

Solution

@primary,

SQL> sho parameter log_archive_config

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_config                   string

SQL>ALTER SYSTEM SET log_archive_config='dg_config=(boston,ChicagO)' SCOPE=BOTH;

System altered.

SQL> alter system set log_archive_dest_state_2=defer;

System altered.

SQL>  alter system set log_archive_dest_state_2=enable

System altered.

SQL> alter system switch logfile;

System altered.

SQL> select dest_id,error,status,log_sequence,applied_scn from v$archive_dest where dest_id=2;

   DEST_ID ERROR                          STATUS    LOG_SEQUENCE APPLIED_SCN
---------- ------------------------------ --------- ------------ -----------
         2                                VALID               63     2133221


@standby,

SQL> sho parameter log_archive_config

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_config                   string

NOTE :

1.  It is not mandatary to set the config parameter at standby side. But we need this to be set on standby side as well for any role

transition purpose and for DG broker configuration.

2.  Once remote shipping established then log_archive_config to null will not affect the remote destination until DB is restarted.

Restart will verify log_archive_config.

rti.run" type="text/javascript">

   這個錯誤是由於沒有配置log_archive_config造成的，重新配置該引數，重新啟用log_archive_dest_state_x引數之後，主備資料庫同步恢復正常。出現這個錯誤的原因是客戶沒有同步主資料庫的主備伺服器下的初始化引數檔案造成的。

   當遇到Heartbeat failed to connect to standby的錯誤時一定注意錯誤編號，根據編號來找錯誤，對新完成配置的ADG環境也可以嘗試重啟備庫或主庫觀察是否能正常同步。

--end--