环境:RAC+单机 Dataguard 问题:启动备库到ADG模式时,发现后台归档日志并不同步
1、在备库中发现日志的归档日志不同步,内容如下: MRP0: Background Media Recovery process shutdown (strac) Managed Standby Recovery Canceled (strac) Completed: alter database recover managed standby database cancel Sun Mar 04 16:35:33 2018 Archived Log entry 96 added for thread 2 sequence 130 ID 0x971d6184 dest 1: Sun Mar 04 16:35:33 2018 RFS[5]: Selected log 11 for thread 2 sequence 131 dbid -1759711868 branch 947273412 Sun Mar 04 16:35:34 2018 Archived Log entry 97 added for thread 2 sequence 131 ID 0x971d6184 dest 1: RFS[5]: Selected log 11 for thread 2 sequence 132 dbid -1759711868 branch 947273412 Sun Mar 04 16:35:36 2018 Archived Log entry 98 added for thread 2 sequence 132 ID 0x971d6184 dest 1: RFS[5]: Selected log 11 for thread 2 sequence 133 dbid -1759711868 branch 947273412 Sun Mar 04 16:39:32 2018
2、当在主库节点1中做切换时,备库中日志并不打印相关的日志进程信息,如果在主库节点2中做日志切换时,备库中是有打印日志的信息内容,内容见第一步中信息
3、通过第二步中的现象描述,可以先大概判断为是主库节点1中DG信息可能有问题导致归档日志无法同步过去
4、查询主库中配置归档位置配置的是否有错误信息,查询的结果如下: SQL> select error from v$archive_dest where target='STANDBY' 2 ;
ERROR
ORA-12154: TNS:could not resolve the connect identifier specified
SQL> select error from v$archive_dest ;
ERROR
ORA-12154: TNS:could not resolve the connect identifier specified
ERROR
ERROR
31 rows selected. 5、通过第4步中的结果,可以判断大概一个方向 ,可能是主库连接到备中监听有问题导致报错,先先TNS配置中查找原因 6、在主库节点1中tnsping 备库配置的服务名看是否报错,操作如下: [oracle@rac1:/home/oracle]$tnsping strac
TNS Ping Utility for Linux: Version 11.2.0.4.0 - Production on 04-MAR-2018 16:57:32
Copyright (c) 1997, 2013, Oracle. All rights reserved.
Used parameter files:
Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.103)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = strac)))rac = TNS-12533: TNS:illegal ADDRESS parameters 7、此时在主库节点2中tnsping 备库服务名发现是可以正常解析过来的 [oracle@rac2:/home/oracle]$tnsping strac
TNS Ping Utility for Linux: Version 11.2.0.4.0 - Production on 04-MAR-2018 16:58:17
Copyright (c) 1997, 2013, Oracle. All rights reserved.
Used parameter files:
Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.103)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = strac))) OK (50 msec)
8、检查主库节点1中的TNS文件配置,经发现主库节点1中的TNS有很多的重复项,从而导致备库不能同步归档日志
9、从主库节点2中把TNS文件copy到主库节点1中,此时观察备库中的日志可以正常打印归档日志同步信息,详细内容如下: Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_1_175_f9q9vwo0_.arc Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_2_110_f9q9qlco_.arc Media Recovery Waiting for thread 1 sequence 176 Fetching gap sequence in thread 1, gap sequence 176-176 Sun Mar 04 16:00:09 2018 RFS[6]: Opened log for thread 1 sequence 176 dbid -1759711868 branch 947273412 Archived Log entry 78 added for thread 1 sequence 176 rlc 947273412 ID 0x971d6184 dest 2: Sun Mar 04 16:00:21 2018 Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_1_176_f9q9w9h5_.arc Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_2_111_f9q9qmng_.arc Media Recovery Waiting for thread 1 sequence 177 Fetching gap sequence in thread 1, gap sequence 177-177 Sun Mar 04 16:00:41 2018 RFS[6]: Opened log for thread 1 sequence 177 dbid -1759711868 branch 947273412 Archived Log entry 79 added for thread 1 sequence 177 rlc 947273412 ID 0x971d6184 dest 2: Sun Mar 04 16:00:51 2018 Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_1_177_f9q9x92z_.arc Media Recovery Waiting for thread 1 sequence 178 Fetching gap sequence in thread 1, gap sequence 178-178 Sun Mar 04 16:00:51 2018 RFS[6]: Opened log for thread 1 sequence 178 dbid -1759711868 branch 947273412 Archived Log entry 80 added for thread 1 sequence 178 rlc 947273412 ID 0x971d6184 dest 2: Sun Mar 04 16:01:01 2018 Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_1_178_f9q9xmc8_.arc Media Recovery Waiting for thread 1 sequence 179 Fetching gap sequence in thread 1, gap sequence 179-179 Sun Mar 04 16:01:01 2018 RFS[6]: Opened log for thread 1 sequence 179 dbid -1759711868 branch 947273412 Archived Log entry 81 added for thread 1 sequence 179 rlc 947273412 ID 0x971d6184 dest 2: Sun Mar 04 16:01:11 2018 Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_1_179_f9q9xxgx_.arc Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_2_112_f9q9qmwy_.arc Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_2_113_f9q9qmyd_.arc Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_2_114_f9q9qncn_.arc Media Recovery Waiting for thread 1 sequence 180 Fetching gap sequence in thread 1, gap sequence 180-180 Sun Mar 04 16:01:11 2018 RFS[6]: Opened log for thread 1 sequence 180 dbid -1759711868 branch 947273412 Archived Log entry 82 added for thread 1 sequence 180 rlc 947273412 ID 0x971d6184 dest 2: Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_1_180_f9q9y7sn_.arc Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_2_115_f9q9qncr_.arc Media Recovery Waiting for thread 1 sequence 181
总结说明: 1、当发现备库中有日志不同步时,可以先从判断配置DG配置项着手,然后通过v$archive_dest 表可以查看当前的归档状态是否正常,本环境中由于原来的DG环境是正常的,后面出现的问题,可以判断初步搭建环境是Ok的。 2、通过v$archive_dest 查询当前的DG的归档日志信息,如果里面有报错信息,可以提供一个大概的参考范围,方便我们定位问题