Archiving logs in the slave database of Oracle Dataguard are not synchronized

Archiving logs in the slave database of Oracle Dataguard are not synchronized

Environment: RAC + single-host Dataguard
Problem: when the slave database is started to the ADG mode, the archived logs in the background are not synchronized.

1. the archived logs of logs in the slave database are not synchronized. The content is as follows:
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. When switching is performed in master database Node 1, logs in the slave database do not print the relevant log process information. If log switching is performed in master database Node 2, the standby database contains information about the printed logs. For details, see step 1.

3. Based on the symptom description in step 2, it can be preliminarily determined that the DG Information in master database Node 1 may be faulty, resulting in the failure of archiving logs to be synchronized.

4. check whether there is any error message when configuring the archive location in the master database. The query result is as follows:
SQL> select error from v $ archive_dest where target = 'standby'
2;

ERROR

ORA-12154: TNS: cocould not resolve the connect identifier specified

SQL> select error from v $ archive_dest;

ERROR

ORA-12154: TNS: cocould not resolve the connect identifier specified

ERROR

ERROR

31 rows selected.
5. Based on the result in step 1, you can determine the approximate direction. It may be that an error occurs when the master database is connected to the standby database. First, locate the cause in the TNS configuration.
6. Check whether the service name configured for the tnsping slave database in master database Node 1 reports an error. The operation is as follows:
[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,201 3, 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. At this time, the service name of the tnsping slave database in master database Node 2 can be resolved normally.
[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,201 3, 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. Check the TNS file configuration in master database Node 1. It is found that TNS in master database Node 1 has many repeated items, which causes the backup database to fail to synchronize archiving logs.

9. copy the TNS file from master database Node 2 to master database Node 1. Observe that logs in the slave database can print the archived log synchronization information normally. The details are as follows:
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_2017176f9q9w9h5.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_2017179f9q9xxgx.arc
Media Recovery Log/archlog/STRAC/archivelog/2018_03_04/o1_mf_2_1_f9q9qmwy.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_109180f9q9y7sn.arc
Media Recovery Log/archlog/STRAC/archivelog/2018_03_04/o1_mf_2_115f9q9qncr.arc
Media Recovery Waiting for thread 1 sequence 181

Summary:
1. When you find that there are different log steps in the slave database, you can start by judging the configuration of the DG configuration item, and then check whether the current archiving status is normal through the v $ archive_dest table, in this environment, because the original DG Environment is normal and subsequent problems occur, it can be determined that the initial build environment is OK.
2. query the archive log information of the current DG through v $ archive_dest. If there is an error message in it, you can provide an approximate reference scope to help us locate the problem.

This article permanently updates link: https://www.bkjia.com/Linux/2018-03/151254.htm