Oracle ADG TroubleShooting -- FAL 配置

Oracle ADG TroubleShooting – FAL 配置

现有ADG环境架构

主库： 一套双节点RAC：

​节点一：REAL_IP：10.3.xx.1

​节点二：REAL_IP: 10.3.xx.2

备库： 单节点主机：10.0.xx.11

背景：

近期钉钉时常报警(报警代码详见<<Oracle ADG(二) Python 监控源码>>)，ADG 传输和应用归档日志均发生较大延迟，造成生产数据和备库数据不同步，影响ADG备库上的实时性业务较高的业务稳定运行。

问题排查：

报警内容分析：

​ 通过报警内容可知，主要的报警原因为： MRP0 进程状态异常(WAIT_FOR_GAP), 传输日志有延迟，应用日志有延迟。 通过WAIT_FOR_GAP 的状态可知部分归档日志在传输的过程中失败了。 进一步排查备库Trace 日志，确定丢失的日志属于主库的那个节点，进一步分析。

备库Trace日志排查：

​

​ 发现是thread 2 sequence 558445 - 558445 这个日志传输失败了，同时备库日志显示FAL[client] 进程通过ADG定义的FAL servers 参数重新去主库拉去归档，但仍未拉取到thread 2 sequence 558445 - 558445 日志片段。 若配置正确将不会有FAL[client]: ALL defined FAL Servers have been attempted 的报错，遂此处考虑备库配置是否不完整。

​ 通过以上判断，进一步去查看备库FAL Server 的配置，发现fal_server 处只配置了一个TNSNAME 为ORCLADG的配置，具体配置如下：

cat $ORACLE_HOME/network/admin/tnsnames.ora
ORCLADG =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 10.3.xx.1)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
  )

​ 发现此处FAL_SERVER只配置了节点一的的REAL_IP，遂出现节点二日志传输失败后FAL 进程无法重新拉取的报错， 遂更改ORCLADG TNSNAME 的配置，增加节点二的REAL_IP:

ORCLADG =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 10.3.xx.1)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = 10.3.xx.2)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
  )

$tnsping orcladg
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.3.xx.1)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = 10.3.xx.2)(PORT = 1521))) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl)))
OK (0 msec)

​ 到此备库配置的问题修改完毕， 配置正确的时候，日志传输失败后FAL重新拉去的日志如下：

Thu Sep 22 22:19:19 2022
Media Recovery Waiting for thread 2 sequence 558445
Fetching gap sequence in thread 2, gap sequence 558445 - 558445

TIPS:

​ 通过查阅资料，类似的主库是RAC节点，一般在备库的TNSNAME 里面配置的IP都是RAC集群的scan_ip， 而不是RAC节点的真实IP。

传输日志失败的节点问题排查：

​ 备库的FAL_SERVER配置问题解决后只是保证了日志传输失败的时候备库能正确的去重新拉去主库的日志，仍需排查为什么主库的归档日志为什么没有正确的传输到备库上。

​ 检查日志传输节点失败的TRACE日志，如下：

ARC0: Archive log rejected (thread 2 sequence 558852) at host 'orclold'
FAL[server, ARC0]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance hostname - Archival Error. Archiver continuing.

​ 通过TRACE 文件日志可知是 ARC0 进程在传输日志时失败，然后去trace 目录下查看ARC0 进程的trace 文件，最后发现的报错是：

# 查看trace 文件的命令： 
ls -lt *arc0*.trc

# 具体的报错
kcrrwkx: unknown error:16401
Error 16401 creating standby archive log file at host 'orclold'

​ 本次案例是在传输日志的时候被备库给拒绝了。当时备库的压力较大。

最后总结：

​ ORALCE ADG 在日志传输失败后会通过FAL 进程重新去拉取主库的日志，只要FAL进程的配置正确且数据不延迟，此报错可以忽略。