Skip to content

Dataguard

Oracle数据库DataGuard数据无法同步，主库查询v$archive_dest出现ORA-16494错误。
数据库版本Oracle 12.1.0.2.0：

SQL> select * from v$version;

BANNER
 --------------------------------------------------------------------------------
 CON_ID
 ----------
 Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production



PL/SQL Release 12.1.0.2.0 - Production



CORE 12.1.0.2.0 Production



BANNER
 --------------------------------------------------------------------------------
 CON_ID
 ----------
 TNS for 64-bit Windows: Version 12.1.0.2.0 - Production



NLSRTL Version 12.1.0.2.0 - Production

检查主库DG参数：

SQL> show parameter log_archive_config

NAME TYPE VALUE
 ------------------------------------ ----------- ------------------------------
 log_archive_config string DG_CONFIG=(orcl,orcladg)
 SQL>
 SQL> show parameter log_archive_dest_2

NAME TYPE VALUE
 ------------------------------------ ----------- ------------------------------
 log_archive_dest_2 string SERVICE=orcladg LGWR ASYNC VAL
 ID_FOR=(ONLINE_LOGFILES,PRIMAR
 Y_ROLE) DB_UNIQUE_NAME=orcladg
 log_archive_dest_20 string
 log_archive_dest_21 string
 log_archive_dest_22 string
 log_archive_dest_23 string
 log_archive_dest_24 string
 log_archive_dest_25 string
 log_archive_dest_26 string
 log_archive_dest_27 string

NAME TYPE VALUE
 ------------------------------------ ----------- ------------------------------
 log_archive_dest_28 string
 log_archive_dest_29 string
 SQL> show parameter service_names

NAME TYPE VALUE
 ------------------------------------ ----------- ------------------------------
 service_names string orcl
 SQL> show parameter unique

NAME TYPE VALUE
 ------------------------------------ ----------- ------------------------------
 db_unique_name string orcl

检查备库参数：

SQL> show parameter log_archive_config

NAME TYPE VALUE
 ------------------------------------ ----------- ------------------------------
 log_archive_config string DG_CONFIG=(orcl,orcladg)
 SQL> show parameter log_archive_dest_2

NAME TYPE VALUE
 ------------------------------------ ----------- ------------------------------
 log_archive_dest_2 string SERVICE=orcl LGWR ASYNC VALID_
 FOR=(ONLINE_LOGFILES,PRIMARY_R
 OLE) DB_UNIQUE_NAME=orcl
 log_archive_dest_20 string
 log_archive_dest_21 string
 log_archive_dest_22 string
 log_archive_dest_23 string
 log_archive_dest_24 string
 log_archive_dest_25 string
 log_archive_dest_26 string
 log_archive_dest_27 string

NAME TYPE VALUE
 ------------------------------------ ----------- ------------------------------
 log_archive_dest_28 string
 log_archive_dest_29 string
 SQL> show parameter service_names

NAME TYPE VALUE
 ------------------------------------ ----------- ------------------------------
 service_names string pdborcl
 SQL> show parameter unique

NAME TYPE VALUE
 ------------------------------------ ----------- ------------------------------
 db_unique_name string orcladg

 

检查主备库之间的网络连通性

主库：

 C:\Users\Administrator>tnsping orcl

TNS Ping Utility for 64-bit Windows: Version 12.1.0.2.0 - Production on 08-5月 -2023 22:42:27

Copyright (c) 1997, 2014, Oracle. All rights reserved.

已使用的参数文件:
 C:\app\pdborcl\product\12.1.0\dbhome_1\network\admin\sqlnet.ora

已使用 TNSNAMES 适配器来解析别名
 尝试连接 (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = WIN-VJ841V9N3PU)(PORT = 1521))) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME =
 OK (20 毫秒)

C:\Users\Administrator>tnsping orcladg

TNS Ping Utility for 64-bit Windows: Version 12.1.0.2.0 - Production on 08-5月 -2023 22:42:39

Copyright (c) 1997, 2014, Oracle. All rights reserved.

已使用的参数文件:
 C:\app\pdborcl\product\12.1.0\dbhome_1\network\admin\sqlnet.ora

已使用 TNSNAMES 适配器来解析别名
 尝试连接 (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.188.201)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = pdborcl)))
 OK (20 毫秒)



 备库：
C:\Users\Administrator>tnsping orcl

TNS Ping Utility for 64-bit Windows: Version 12.1.0.2.0 - Production on 08-5月 -2023 22:42:27

Copyright (c) 1997, 2014, Oracle. All rights reserved.

已使用的参数文件:
 C:\app\pdborcl\product\12.1.0\dbhome_1\network\admin\sqlnet.ora

已使用 TNSNAMES 适配器来解析别名
 尝试连接 (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = WIN-VJ841V9N3PU)(PORT = 1521))) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME =
 OK (20 毫秒)

C:\Users\Administrator>tnsping orcladg

TNS Ping Utility for 64-bit Windows: Version 12.1.0.2.0 - Production on 08-5月 -2023 22:42:39

Copyright (c) 1997, 2014, Oracle. All rights reserved.

已使用的参数文件:
 C:\app\pdborcl\product\12.1.0\dbhome_1\network\admin\sqlnet.ora

已使用 TNSNAMES 适配器来解析别名
 尝试连接 (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.188.201)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = pdborcl)))
 OK (20 毫秒)

 主备库之间网络是畅通的。
 主库切换日志，查询v$archive_dest：
SQL> alter system switch logfile;

系统已更改。

出现ORA-16494错误，该错误在网上找不到，而且MOS上也没有相关的记载。
再次检查备库，会不会是PDB模式的，而且有名为PDBORCL的PDB，导致主库通过tns直接连到了PDB中。
备库查询：

SQL> select con_id,name,open_mode from v$pdbs;

CON_ID NAME OPEN_MODE
---------- ------------------------------ ----------
2 PDB$SEED MOUNTED
3 PDBORCL MOUNTED


果然有个叫PDBORCL的PDB。

查看数据库的数据库名：

 

SQL> select name,open_mode,database_role from v$database;

NAME OPEN_MODE DATABASE_ROLE
 --------- -------------------- ----------------
 ORCL MOUNTED PHYSICAL STANDBY

所以，如果想连到CDB中，应该将service_names指定为orcl，由于是备库，可设置为rzorcl或orclstd等，方便识别，但是一定要与PDBORCL不同名。
修改备库service_names

 

SQL> alter system set service_names='rzorcl';

 

在修改主库和备库中tnsnames.ora文件中备库连接串中SERVICE=RZORCL。
再次尝试切换日志，错误消失。

系统已更改。

 SQL> select error from v$archive_dest;

ERROR
 -----------------------------------------------------------------

ERROR
 -----------------------------------------------------------------

ERROR
 -----------------------------------------------------------------

已选择 31 行。

SQL>

 再次查看备库日志接收情况：
SQL> select process,sequence#,block# from v$managed_standby;

PROCESS SEQUENCE# BLOCK#
 --------- ---------- ----------
 ARCH 103988 43008
 ARCH 0 0
 ARCH 103987 4096
 ARCH 103989 40960
 MRP0 103990 29955
 RFS 0 0
 RFS 103990 29955
 RFS 0 0
 RFS 0 0

9 rows selected.

 15
 备库日志接收正常，问题解决。

Oracle-16494 在Oracle support中并未能找到相关报错信息，疑似bug，但是我们并未提交该bug

疑似Oracle 未发布的Oracle dataguard 相关bug一例 Oracle – 16494

归档日志间隙（Archive Gap）

 

归档日志间隙是在 Standby 端一系列丢失的重做日志，导致日志应用服务无法继续运行。这通常发生在 Standby 端无法从 Primary Database 接收重做日志或重做日志在 Standby Database 上不可用时。常见原因有:

  • 网络连接断开或者日志传输服务停止
  • Standby Database 不可用
  • 日志传输服务的配置错误
  • Standby 端的 IO 问题
  • 归档日志在应用到 Standby 前被手工删除
  • Primary 和 Standby 之间的网络带宽不足

一旦在 Standby Database 上存在归档间隙，Log Apply Services 就会卡住，直到日志间隙（Gap）被解决，例如。丢失的 Redo 被重新获取并且在 Standby 端可用。然后，日志应用服务可以选中它并继续处理。

 

解决日志间隙的方式

 

有4种方案来解决 Standby Database 上的日志间隙。这些方案在下面讨论。

自动日志间隙解决方案

自动日志间隙解决方案是由日志传输服务自动进行的。它会把当前正在传输的日志和最近收到的日志进行对比，如果有不匹配的情况出现，Standby 端的 RFS 进程就会检测到并自动发送 ARCH-RFS 心跳 Ping 请求来要求发送丢失的日志。这种类型的日志间隙解决方法使用了主数据库上的 log_archive_dest_n 中定义的 Service。另外 ARCH-RFS 心跳 Ping 可以通过对当前的日子序列号进行查询来检测日志间隙。如果存在日志间隙则仍通过ARCH-RFS 心跳 Ping 请求来解决它。在问题得到解决后，会通知日志传输进程（ARCH 或者 LGWR）。对于自动日志间隙解决方案，不需要额外的设置或者监控。

 

FAL (Fetch Archive Log)日志间隙解决方案

当一个归档日志在 Standby 数据库上被收到或者归档，它就会被注册到 Standby 的控制文件中。（您可以在物理 Standby 数据库上查询 v$archived_log 或在逻辑 Standby 数据库上查询 dba_logstdby_log 来获取这些注册信息）。如果这个文件因为某些原因丢失或者损坏（比如，它被意外删除），FAL 就会被调用来解决日志间隙问题。因为这些缺失的日志文件通常由 Standby 数据库上的日志应用服务检测到。它独立于日志传输服务，并且没有和主库之间的直接链接。要使用 FAL，必须在 Standby 数据库设置一个或者两个（11.2.0 之前的版本）初始化参数：

FAL_SERVER：设置 Oracle Net Service Name（TNS-Alias 或者 Connect Descriptor）指向用来获取丢失的归档日志的数据库。它可以是一个 Data Guard 环境的主库，或者是另一个备库，ArchiveLog Repository- 或者 Far Sync Standby (> Oracle 12.1.0) Database。可以指定多个 Service Names（逗号分隔）。FAL 会顺序的尝试这些数据库来解决日志间隙问题。

FAL_CLIENT (< Oracle 11.2.0)：在 FAL_SERVER 数据库上设置 Oracle Net Service Name（TNS-Alias 或 Connect Descriptor）指向接收 REDO 的 Standby 数据库（比如，它是 FAL_SERVER 数据库需要发送 REDO 到的目标数据库）。确保这个 TNS-Alias 存在于 FAL_SERVER 数据库的 TNSNAMES.ORA 文件中。从 Oracle 11.2.0 开始，这个参数不再需要。但是需要确保 FAL_SERVER 数据库存在一个log_archive_dest_n 指向要解决日志间隙问题的 Standby 数据库。

当 Log ApplyServices 检测到日志间隙问题，它会发送一个 FAL 请求把 FAL_CLIENT 信息（Version > 11.1.0 则为 db_unique_name）给 FAL_SERVER。一个 FAL_SERVER 数据库上的 ARCH-Process 会尝试获取那个日志并发送回 FAL_CLIENT（或者 db_unique_name 对应的 Destination）。如果第一个 FAL_SERVER 无法解决日志间隙，会尝试列表中的下一个 FAL_SERVER。如果所有的 FAL_SERVERs 都无法解决，那么 FAL 请求会失败，并且一个对应的错误信息会写入对应 Standby 数据库的 ALERT.LOG。

为了成功解决日志间隙问题，需要的归档日志应当存在于 FAL_SERVER 数据库（存在于磁盘并且对应的信息同时存在于控制文件中）。

FAL 从 Oracle 9.2.0 开始可用于物理 Standby 数据库，从 Oracle 10.1.0 开始可用于逻辑 Standby 数据库。

 

手工解决日志间隙

如果日志间隙问题不能被上面提到方式解决，那么可以尝试手工解决。

可以通过查询物理 Standby 数据库的 $archive_gap 或者逻辑 Standby 数据库的 dba_logstdby_log 来确定当前的归档日志间隙，例如：

 

物理 Standby 数据库

SQL> select * from v$archive_gap;

逻辑 Standby 数据库

SQL> select thread#, sequence# from dba_logstdby_log l where next_change# not in

(select first_change# from dba_logstdby_log where l.thread#=thread#)

order by thread#, sequence#;

 

现在复制缺失的特定编号的 redo 日志到 Standby 数据库的对应位置。如缺失的日志尚未注册到 Standby 数据库，需要先注册它们才能让 Log Apply Services 处理这些日志文件。可以使用下面的命令注册：

物理 Standby：

SQL> alter database register logfile ‘<File-Specification>’;

逻辑 Standby：

SQL> alter database register logical logfile ‘<File-Specification>’;

 

在它们被注册后，Log Apply Services 就可以处理了。

 

使用增量备份前滚（仅适用于物理 Standby）

如果日志间隙无法被上面提到的方式解决，间隙太大需要太久时间才能解决或者丢失的日志无法被找到，您仍然可以通过使用 SCN 增量备份来前滚物理 Standby 数据库。这个功能从 Oracle 10.2.0 开始可以使用。这个功能通过记录最后应用到 Standby 数据库的SCN，然后使用 RMAN 以及当前控制文件的备份来对主库创建一个从那个 SCN 开始的增量备份。

之后首先用增量备份中的控制文件替换 Standby 的控制文件，之后应用增量备份到 Standby 数据库。这是一个把 Standby 数据库同步到最新的主库的状态的最快最简单的方式。因为采取的步骤各个版本都不同

Oracle dataguard 日志缺失的解决办法

An Oracle Data Guard far sync instance is a remote Oracle Data Guard destination that accepts redo from the primary database and then ships that redo to other members of the Oracle Data Guard configuration. A far sync instance manages a control file, receives redo into standby redo logs (SRLs), and archives those SRLs to local archived redo logs, but that is where the similarity with standbys ends. A far sync instance does not have user data files, cannot be opened for access, cannot run redo apply, and can never function in the primary role or be converted to any type of standby database.

Active Data Guard Far Sync是Oracle 12c的新特性（也称为Far Sync Standby），Far Sync功能的实现是通过在距离主库(Primary Database)相对较近的地点配置Far Sync实例，主库(Primary Database) 同步(synchronous)传输redo到Far Sync实例，然后Far Sync实例再将redo异步(asynchronous)传输到终端备库(Standby Database)。这样既可以保证零数据丢失又可以降低主库压力。Far Sync实例只有密码文件，init参数文件和控制文件，而没有数据文件。所以无法打开用于访问。

Far Sync配置对于Data Guard 角色转换(role transitions)是透明的，即switchover/failover命令方式与12c之前相同。

2 实验-Far Sync安装配置
创建Far Sync实例类似于创建物理备库，但数据文件在Far Sync实例中不存在。因此不需要拷贝数据文件并还原数据文件。一旦Far Sync实例创建了，那么就默认运行在Maximum Availability模式，那么REDO是实时同步传输的。

2.1 主库配置和操作
2.1.1 创建Far Sync实例的控制文件
SQL> ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS ‘/tmp/control01.ctl’;
Database altered.
将上面生成的Far Sync的控制文件拷贝到Far Sync所在的主机上。

SQL> !scp /tmp/control01.ctl 192.168.1.173://u01/app/oracle/oradata/cndba_far/

[Expect-le@ www.cndba.cn]$ pwd
/u01/app/oracle/oradata/cndba_far
2.1.2 修改配置，指向Far Sync实例
SQL> alter system set LOG_ARCHIVE_CONFIG =’DG_CONFIG=(cndba_p,cndba_far_sync,cndba_s)’ scope=both;
System altered.

SQL> alter system set LOG_ARCHIVE_DEST_2=’SERVICE=cndba_far_sync ASYNC NOAFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=cndba_far_sync’ scope=both;
System altered.
2.2 备库修改配置
SQL> alter system set LOG_ARCHIVE_CONFIG =’DG_CONFIG=(cndba_p,cndba_far_sync,cndba_s)’ scope=both;
System altered.

SQL> alter system set LOG_ARCHIVE_DEST_2=’SERVICE=cndba_p ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=cndba_p’ scope=both;
System altered.
2.3 Far Sync实例配置
2.3.1 修改PFILE
cndba_s是物理备库，cndba_far_sync是Far Sync实例的DB_UNIQUE_NAME。如果日志文件路径需要修改，也要修改DB_FILE_NAME_CONVERT和LOG_FILE_NAME_CONVERT。

DB_UNIQUE_NAME=cndba_far_sync
CONTROL_FILES=’/u01/app/oracle/oradata/cndba_far/control01.ctl’
FAL_SERVER=cndba_p
LOG_ARCHIVE_CONFIG=’DG_CONFIG=(cndba_p,cndba_far_sync,cndba_s)’
LOG_ARCHIVE_DEST_1=’LOCATION=/u01/archivelog VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=cndba_far_sync’
LOG_ARCHIVE_DEST_2=’SERVICE=cndba_s ASYNC
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=cndba_s’
2.3.2 将Far Sync实例启动到mount
SQL> create spfile from pfile=’/u01/app/oracle/product/12.1.0.2/db_1/dbs/initcndba_far.ora’;
File created.

SQL> startup mount;
ORACLE instance started.
Total System Global Area 2348810240 bytes
Fixed Size 2927048 bytes
Variable Size 1409287736 bytes
Database Buffers 922746880 bytes
Redo Buffers 13848576 bytes
Database mounted.
2.3.3 查看Far Sync实例状态
SQL> select protection_mode,database_role,protection_level,open_mode from v$database;
PROTECTION_MODE DATABASE_ROLE PROTECTION_LEVEL OPEN_MODE
——————– —————- ——————– ——————–
MAXIMUM PERFORMANCE FAR SYNC MAXIMUM PERFORMANCE MOUNTED
2.3.4 创建standby redo log(可选，最好创建)
语法：

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4(‘/u01/app/oracle/oradata/cndba_far/standbyredo11.log’) SIZE 52428800;
2.4 主备库和Far Sync添加TNSNAME
CNDBA_FAR_SYNC =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.173)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = cndba)
)
)
2.5 检查配置
SQL> select * from V$DATAGUARD_CONFIG;
DB_UNIQUE_NAME PARENT_DBUN DEST_ROLE CURRENT_SCN CON_ID
—————————— —————————— —————– ———– ———-
cndba_p NONE PRIMARY DATABASE 2154617 0
cndba_far_sync cndba_p FAR SYNC INSTANCE 2151372 0
cndba_s cndba_far_sync PHYSICAL STANDBY 2151372 0
从上面可以看出，配置没有问题。

Cndba_p -> cndba_far_sync -> cndba_s

2.6 测试日志是否正常传输
–查看当前日志序列号

主库：

SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
————–
56
Far Sync实例:

SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
————–
56
备库：
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
————–
56
–手动切换日志

SQL> alter system switch logfile;
System altered.
–再次查看备库和Far Sync实例的日志序列号
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
————–
57
至此搭建Far Sync结束了。

3 总结
1. 由于Far Sync存在单点故障，所以建议搭建两个及以上的Far Sync实例。默认只启用其中一个，只有当一个挂掉了，才会自动启用另一个。

2. 主库建议配置一个备用的LOG_ARCHIVE_DEST_3，直接指向备库。在LOG_ARCHIVE_DEST_2不可用时，会启用LOG_ARCHIVE_DEST_3直接传输redo到备库。

3. Far Sync可大大减少主库的压力，特别是在一主多备的情况下。

4. switchover/failover对于Far Sync是透明的，不需要特殊配置，按正常切换即可。

Active DataGuard Far sync在dataguard中的应用（12c，18c，19c）

1  说明

In previous releases, when creating a Data Guard configuration using the SQL command line, the default configuration was to apply redo from archived log files on the standby database. In Oracle Database 12c Release 1 (12.1), the default configuration is to use real-time apply so that redo is applied directly from the standby redo log file.

在之前版本中启用MRP默认是从归档日志文件中应用redo日志。从12c开始，默认是通过读取standby redo日志文件来启用real-time redo应用。

Recovery time is shortened at failover given that there is no backlog of redo waiting to be applied to the standby database if a failover is required. An active Data Guard user also sees more current data. This enhancement eliminates additional manual configuration (and the requirement that the administrator be aware of the default setting) that was required in past releases. It also makes the default SQL*Plus configuration identical to the default configuration used by the Data Guard broker.

2  实验

2.1   主备库状态

—主库

SQL> select protection_mode,database_role,protection_level,open_mode from v$database;
PROTECTION_MODE      DATABASE_ROLE    PROTECTION_LEVEL	   OPEN_MODE
-------------------- ---------------- -------------------- --------------------
MAXIMUM AVAILABILITY PRIMARY	      MAXIMUM AVAILABILITY READ WRITE

—备库

SQL> select protection_mode,database_role,protection_level,open_mode from v$database;
PROTECTION_MODE      DATABASE_ROLE    PROTECTION_LEVEL	   OPEN_MODE
-------------------- ---------------- -------------------- --------------------
MAXIMUM AVAILABILITY PHYSICAL STANDBY MAXIMUM AVAILABILITY READ ONLY WITH APPLY

2.2   启用MRP

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
或
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING ARCHIVED LOGFILE DISCONNECT;

在备库配置了standby redo log，并处于归档模式，那么默认情况下会上面语句会自动启用real-time redo应用。

2.3   主库创建表

SQL> create table cndba as select * from dba_users;
Table created.
 
SQL> select count(*) from cndba;
COUNT(*)
----------
36

注意：不要切换日志，看看备库是否实时同步。

2.4   备库查询数据

SQL> select count(*) from cndba;
  COUNT(*)
----------
36

数据同步过来了。所以Real-Time应用是默认设置。

Real-Time Apply Default For Data Guard （12c，18c，19c）

11g Dataguard error ORA-16191

报错信息:

Error 1017 received logging on to the standby
------------------------------------------------------------
Check that the primary and standby are using a password file
and remote_login_passwordfile is set to SHARED or EXCLUSIVE,
and that the SYS password is same in the password files.
returning error ORA-16191

产生情况是这样的,一套rac的dataguard,在搭建完成后开启standby seesion后主备库都在不断报ORA-16191,这个错误出现时候也没有发现伴随错误,而且三个实例的password是一样的,只是orapw文件是每个实例单独生成.
根据错误描述,是怀疑此DG的pri和std的密码文件密码不一致导致,逐用统一命令重建实例1和STD的密码文件,报错依旧.节点2重建密码文件,报错依旧.
其次对节点1的密码文件拷贝到std中,并修改orapw对应的实例名,重启standby session,rac节点1和standby的实例不再报错ora-16191,而实例二依然再报ora-16191,将节点1的密码文件拷贝至节点2,并修改对应实例名,报错消失,至此日志传输以及应用恢复正常.

 

相关Metalink文档排障思路参考文档:

Troubleshooting – Heartbeat failed to connect to standby (文档 ID 1432367.1)

Dataguard Oracle 数据技术 | Guang Cai Li |