Archived logs are not synchronized in the Oracle Dataguard repository

Environment: rac+ stand-alone Dataguard
Issue: When you start the repository to ADG mode, you find that the background archive log is not synchronized

1, in the standby library to find logs of the archive log is not synchronized, the contents are 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 added for thread 2 sequence ID 0x971d6184 dest 1:
Sun Mar 04 16:35:33 2018
RFS[5]: Selected log one for thread 2 sequence 131 dbid-1759711868 branch 947273412
Sun Mar 04 16:35:34 2018
Archived Log entry added for thread 2 sequence 131 ID 0x971d6184 dest 1:
RFS[5]: Selected log one for thread 2 sequence dbid-1759711868 branch 947273412
Sun Mar 04 16:35:36 2018
Archived LOG Entry 98 added for thread 2 sequence ID 0x971d6184 dest 1:
RFS[5]: Selected log one for thread 2 sequence 133 dbid-1759711868 Branch 947273412
Sun Mar 04 16:39:32 2018

2, when switching in the main library node 1, the log in the repository does not print the relevant log process information, if the main library node 2 in the log switch, the repository is the information content of the print log, the contents of the first step of the information

3, through the description of the phenomenon in the second step, you can probably judge that the DG information in the main library node 1 may have a problem that the archive log can not be synchronized past

4, query the main library to configure the archive location configuration is error information, the results of the query is as follows:
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

Errorerror

Rows selected.
5, through the 4th step in the results, you can judge a direction, it may be the main Cullen received standby monitoring problems resulting in error, first in the TNS configuration to find the cause
6, in the main library node 1 tnsping the configuration of the service name to see if the error, the operation is as follows:
[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, 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)) (CON Nect_data = (service_name = Strac))) RAC =
Tns-12533:tns:illegal ADDRESS Parameters
7, at this time in the main Library Node 2 tnsping the repository service name found to be able to parse the normal.
[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, 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)) (CON Nect_data = (service_name = Strac)))
OK (msec)

8, check the TNS file configuration in the main Library node 1, discovered that TNS in the main library Node 1 has many duplicates, which causes the repository to not synchronize the archive log

9, from the main library node 2 to copy the TNS file to the main library node 1, at this time to observe the log in the repository can normally print the archive log synchronization information, details 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 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 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 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 Bayi 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 dbid-1759711868 branch 947273412
Archived Log entry added for thread 1 sequence 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

Summary description:
1, when the discovery of the library in the log out of sync, you can start by judging the configuration of the DG configuration, and then through the V$archive_dest table can see the current status of the archive is normal, the environment because the original DG Environment is normal, the problems behind the problem, you can judge the initial build environment is OK.
2, through the V$archive_dest query the current DG archive log information, if there is an error message, can provide a general reference range, convenient for us to locate the problem

Archived logs are not synchronized in the Oracle Dataguard repository