Oracle Dataguard中备库中归档日志不同步

环境：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 备库配置的服务名看是否报错，操作如下：
[[email protected]:/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 备库服务名发现是可以正常解析过来的
[[email protected]:/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_175f9q9vwo0.arc
Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_2_110f9q9qlco.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_176f9q9w9h5.arc
Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_2_111f9q9qmng.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_177f9q9x92z.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_178f9q9xmc8.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_179f9q9xxgx.arc
Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_2_112f9q9qmwy.arc
Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_2_113f9q9qmyd.arc
Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_2_114f9q9qncn.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_180f9q9y7sn.arc
Media Recovery Log /archlog/STRAC/archivelog/2018_03_04/o1_mf_2_115f9q9qncr.arc
Media Recovery Waiting for thread 1 sequence 181

总结说明：
1、当发现备库中有日志不同步时，可以先从判断配置DG配置项着手，然后通过v$archive_dest 表可以查看当前的归档状态是否正常，本环境中由于原来的DG环境是正常的，后面出现的问题，可以判断初步搭建环境是Ok的。
2、通过v$archive_dest 查询当前的DG的归档日志信息，如果里面有报错信息，可以提供一个大概的参考范围，方便我们定位问题

原文地址：http://blog.51cto.com/xiaocao13140/2082846

时间： 2024-10-31 16:08:14

Oracle Dataguard中备库中归档日志不同步的相关文章

oracle dataguard主备库参数文件配置详解

主库参数详解: 保持同一个Data Guard中所有的DB_NAME相同 DB_NAME=ora11g 为一个数据库指定一个唯一的名称,该参数一经指定就不会发生改动除非DBA主动改动 DB_UNIQUE_NAME=ora11g_primary 初始化参数LOG_ARCHIVE_CONFIG用于控制发送归档日志到远程位置.接收远程归档日志,并指定Data  Guard配置的惟一数据库名,默认值为SEND,RECEIVE,NODG_CONFIG. 当设置该参数为SEND时,会激活发送归档日志到远程位

oracle11g dataguard物理备库搭建

Dataguard 环境: 操作系统:Redhat6.4 Primary数据库: IP 地址:192.168.1.122 数据库SID:ora11g DB_UNIQUE_NAME:ora11g_primary Standby数据库: IP 地址:192.168.1.123 数据库SID:ora11g DB_UNIQUE_NAME:ora11g_standby (注:oracle数据库版本是11.2.0.1.0) 1.Primary端的配置 (1).检查数据库是否支持 Data Guard(企业版

Oracle 12c DG备库Alert报错ORA-10877全库恢复

12C Oracle Data Guard 备库今天异常 2018-07-05T21:31:32.291970+08:00GEN0 (ospid: 75371): terminating the instance due to error 4722018-07-05T21:31:32.293376+08:00System state dump requested by (instance=1, osid=75371 (GEN0)), summary=[abnormal instance term

Lua中字符串库中的几个重点函数

前言 在<Lua中的一些库>中也说道了,要对string库的模式匹配进行单独的讲解.对于字符串的处理,对于任何语言的学习来说,都是一个难点,而且也是一个必会的知识点.给你一个字符串,让你按照某种需求进行处理,你不会,那是多么尴尬的一件事情.所以,看完<Lua中的一些库>和这篇文章之后,我争取做到让你在处理字符串时,不再感到捉襟见肘,不再尴尬. 说到Lua中的模式匹配,基本上就是围绕着以下几个函数展开的: find match gsub gmatch 我的总结也就是围绕着上面的四个函

Oracle 12c DG备库Alert报错ORA-01110

环境是12.2.0.1 version, Oracle Data Guard备库今天故障恢复了一下,RMAN恢复后发现备库Alert一直报错,但是备库主库同步一致,数据一致.2018-07-05T23:42:22.184048+08:00Errors in file /u01/app/oracle/diag/rdbms/dwjrstdydb/dwjrstdydb/trace/dwjrstdydb_m000_129832.trc:ORA-01110: data file 7: '/u01/app/

oracle DG 主备库为RAC及一个主库对多个从库的实验环境搭建

主库 RAC :192.168.1.210 node1 192.168.1.211 node2 备库(1) RAC:    192.168.1.247 rac1 192.168.1.248 rac2 备库(2) 单实例:192.168.1.219 dataguard 以上均为ASM管理. 实验步骤: 配置备库(1)的静态监听: SID_LIST_LISTENER=       (SID_LIST=       (SID_DESC=       (GLOBAL_DBNAME=SMS)      

ORACLE DataGuard主备切换

主库磁盘问题,导致主库宕机,因为归档还没有应用,导致备库无法转为主库 先查看一下备库当前的信息: SQL> select * from v$version; BANNER ---------------------------------------------------------------------Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production PL/SQL Release 11.

记一次DG搭建过程中备库ORA-00210，ORA-00202，ORA-27086错误

ORA-00210: cannot open the specified control file ORA-00202: control file: '/u01/app/oracle/oradata/orcl/control01.ctl' ORA-27086: unable to lock file - already in use 思路: 1.看一下"lk" and "sgadef.dbf"这两个文件是不是存在着,如果存在将其删掉: 2.看是不是有后台进程存在:

python中json库中的load、loads、dump、dumps的区别与用法

一.json.dumps(i): json中的dumps方法是用来将特定格式的数据进行字符串化的操作,比如列表字典都可以进行字符串化操作然后写入json的file:而且如果是要写入json文件就必须要进行dumps操作: 二.json.dump(): 和dumps差一个s,功能作用大致上是一样,也是讲数据转换成str格式,最终包括了讲数据写入json文件的一个操作步骤,json.dump(data, file-open,ascii=False),可以包含三个属性,第三个ascii是用来避免出现u