Shulou(Shulou.com)06/01 Report--

Environment: RAC+ stand-alone Dataguard

Problem: when starting the slave library to ADG mode, it is found that the background archive log is not synchronized.

1. The archive log of the log is found to be out of sync in the repository, 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 131dbid-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 132dbid-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 in the main database node 1, the log in the standby database does not print the relevant log process information. If the log is switched in the main database node 2, the information content of the printed log is in the standby database, as shown in the information in step 1.

3. Through the description of the phenomenon in the second step, we can roughly judge that there may be a problem with the DG information in the main database node 1, which may cause the archive log to fail to synchronize.

4. Query whether there is an error message in the configuration of the archive location in the main database. The query result 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

31 rows selected.

5. Through the result in step 4, you can judge about one direction. It may be that there is a problem with the connection of the main database to the slave monitoring, which may lead to an error. Find the reason in the TNS configuration first.

6. Check the service name configured by tnsping slave database in the main database node 1 to see if there is 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, 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. At this time, the tnsping slave service name discovery can be resolved normally in the main database node 2.

[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. Check the configuration of the TNS file in the main database node 1. It is found that there are many duplicates in the TNS in the main database node 1, which leads to the failure of the backup database to synchronize the archive log.

9. Copy the TNS file from the master database node 2 to the master database node 1, and observe the logs in the slave database to print archive 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 176176

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_176f9q9w9h6.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 177177

Sun Mar 04 16:00:41 2018

RFS [6]: Opened log for thread 1 sequence 177dbid-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 178178

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

Summary description:

1. When logs are found to be out of sync in the slave database, you can start by determining the configuration of DG configuration items, and then you can check whether the current archiving status is normal through the v$archive_dest table. Because the original DG environment is normal in this environment, you can determine that the initial building environment is Ok.

2. Query the archive log information of the current DG through v$archive_dest. If there is any error information in it, it can provide an approximate reference range to facilitate us to locate the problem.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.