Which process in physical Data Guard processes Redo GAP

In Oracle Data Guard, the Redo Gap is generated because of some network or other problems, resulting in the interruption of the redo transmission. After the fault is eliminated, these redo files that have not been transferred will be discovered by some processes and transmitted to the slave database.

Terms:

ARC: archiving process
MRP: Media Recovery Process, responsible for applying redo on the slave Database
RFS: Remote File Server, which receives the redo File sent from the slave database.
FAL: Fetch Archive Log

Objective: To determine which process is responsible for handling the gap after a gap occurs due to a network problem.

Test environment: Oracle 11.2.0.2 on Linux 5.

Test process:

1. Ensure that the current master and slave databases are synchronized:
Primary:
MAX (SEQUENCE #)
--------------
86

Standby:
MAX (SEQUENCE #)
--------------
86

2. Simulate network interruption, resulting in gap:
Stop the NIC in the master database: # ifconfig eth0 down

Switch logfile to the master database several times:
SQL> alter system switch logfile;
SQL> alter system switch logfile;
...

Primary:
MAX (SEQUENCE #)
--------------
96

At this time, the alert log of the master database reports an error that cannot be connected to the slave database:
TNS-00513: Destination host unreachable
Nt secondary err code: 101
Nt OS err code: 0
Error 12543 removed ed logging on to the standby
FAL [server, ARCp]: Error 12543 creating remote archivelog file 'standby'
FAL [server, ARCp]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance orcl-Archival Error. Archiver continuing.



3. Temporarily change the archive files of the master database to a directory to ensure that these archives cannot be uploaded to the slave database:
Mv *. arc ../

4. Enable the NIC of the master database:
# Ifconfig eth0 up

5. At this time, the ARC of the master database did not transmit the missing logs to the slave database. Finally, the MRP of the slave database discovers the gap and fetching the gap.

Standby Database alert log:
Thu Mar 29 19:58:49 2012
Media Recovery Waiting for thread 1 sequence 87 (in transit) <=== Waiting for 87
...
Thu Mar 29 20:08:45 2012
...
Media Recovery Waiting for thread 1 sequence 94
Thu Mar 29 20:11:01 2012
RFS [61]: Assigned to RFS process 13643
RFS [61]: Opened log for thread 1 sequence 97 dbid 1285401128 branch 757620395
Archived Log entry 80 added for thread 1 sequence 97 rlc 757620395 ID 0x4c9d8928 dest 2:
Thu Mar 29 20:11:02 2012
RFS [62]: Assigned to RFS process 13645
RFS [62]: Selected log 4 for thread 1 sequence 98 dbid 1285401128 branch 757620395
Thu Mar 29 20:11:02 2012
Primary database is in maximum performance mode
Re-archiving standby log 4 thread 1 sequence 98
Thu Mar 29 20:11:02 2012
Archived Log entry 81 added for thread 1 sequence 98 ID 0x4c9d8928 dest 1:
RFS [63]: Assigned to RFS process 13647
RFS [63]: Selected log 4 for thread 1 sequence 99 dbid 1285401128 branch 757620395
Thu Mar 29 20:11:05 2012
Fetching gap sequence in thread 1, gap sequence 94-96 <========== get gap
...

6. Through the trace of MRP, it can be determined that MRP has performed fetching gap:

MRP trace:

* ** 20:08:45. 375 4265 krsh. c
Media Recovery Waiting for thread 1 sequence 94

* ** 2012-03-29 20:11:05. 543
* ** 20:11:05. 543 4265 krsh. c
Fetching gap sequence in thread 1, gap sequence 94-96 <========= MRP get gap.
Redo shipping client login Ming standby login
* ** 20:11:05. 593 4595 krsu. c
Logged on to standby successfully
Client logon and security negotiation successful!

7. After the archived logs are removed, the RFS of the slave database receives these logs, and the MRP applies these logs.

Thu Mar 29 20:12:06 2012
RFS [64]: Assigned to RFS process 13649
RFS [64]: Opened log for thread 1 sequence 94 dbid 1285401128 branch 757620395
Archived Log entry 82 added for thread 1 sequence 94 rlc 757620395 ID 0x4c9d8928 dest 2:
Thu Mar 29 20:12:06 2012
RFS [65]: Assigned to RFS process 13651
RFS [65]: Opened log for thread 1 sequence 95 dbid 1285401128 branch 757620395
Thu Mar 29 20:12:06 2012
RFS [66]: Assigned to RFS process 13653
RFS [66]: Opened log for thread 1 sequence 96 dbid 1285401128 branch 757620395
Archived Log entry 83 added for thread 1 sequence 95 rlc 757620395 ID 0x4c9d8928 dest 2:
Archived Log entry 84 added for thread 1 sequence 96 rlc 757620395 ID 0x4c9d8928 dest 2:
Thu Mar 29 20:12:16 2012
Media Recovery Log/home/oracle/arch1/standby/1_94_757620395.arc
Media Recovery Log/home/oracle/arch1/standby/1_95_757620395.arc
Media Recovery Log/home/oracle/arch1/standby/1_96_757620395.arc
Media Recovery Log/home/oracle/arch1/standby/1_97_757620395.arc
Media Recovery Log/home/oracle/arch1/standby/1_98_757620395.arc


Test conclusion:
This example shows that the ARC process in the master database does not process the previously generated gap files. The MRP process of the slave database finds the gap when applying the log and retrieves these files through the FAL process.

Note: At 11 GB, theoretically, the ARC process of the master database and the RFS and MRP processes of the slave database may process the gap in some situations.

8. to further confirm that MRP obtained the gap file through FAL, I modified the password of the master database. As a result, the following error was reported in the trace of MRP: FAL [client, MRP0]. the description is obtained through FAL.

* ** 21:18:15. 964 4265 krsh. c
Error 1031 removed ed logging on to the standby
* ** 21:18:15. 964 4265 krsh. c
FAL [client, MRP0]: Error 1031 connecting to PRIMARY for fetching gap sequence