Solution to oracle elastic uard redo gap

Redogap is generated when the redo transmission is interrupted.
Generally, when the redo transmission service is restored, oracle automatically checks the gap and solves it by itself. The time required to fix the gap depends on the gap size and the network condition between the redo source database and the redo destination database. If there is a gap, you can consider the following optimization methods:
1. Transfer in compression mode. You can add the compression parameter to the log_archive_dest_n parameter.
2. Enable the parallel log transmission mode. In the log_archive_dest_n parameter, set the max_connections parameter to be greater than 1.
When the master database is unavailable, manual intervention may be required to fix the redo gap. The steps are as follows:
For physical standby databases:
Run the following statement to check whether the standby database has redogap:
SQL & gt; SELECT * FROM V $ ARCHIVE_GAP;
The result is as follows:
THREAD # LOW_SEQUENCE # HIGH_SEQUENCE #
--------------------------------------
1 7 10
The result shows that redo 7-10 of thread 1 is a gap. Execute the following query on the master database to determine the required archived logs:
SQL & gt; SELECT NAME FROM V $ ARCHIVED_LOG WHERE THREAD # = 1 AND-
& Gt; DEST_ID = 1 and sequence # BETWEEN 7 AND 10;
NAME
--------------------------------------------------------------------------------
/Primary/threadincludest/arcr_00007.arc
/Primary/threadincludest/arcr_00008.arc
/Primary/threadincludest/arcr_00009.arc
Assume that dest_1 of the master database is the local archive path.
Copy these files to the appropriate location of the slave database and make them belong to oracle: oinstall. The slave database runs the following command to register these archive logs:
SQL & gt; ALTER DATABASE REGISTER LOGFILE-
& Gt; '/physical_standby1/threadincludest/arcr_00007.arc ';
SQL & gt; ALTER DATABASE REGISTER LOGFILE-
& Gt; '/physical_standby1/threadincludest/arcr_00008.arc ';
SQL & gt; ALTER DATABASE REGISTER LOGFILE-
& Gt; '/physical_standby1/threadincludest/arcr_00009.arc ';
After executing these statements, re-execute the statements:
SQL & gt; SELECT * FROM V $ ARCHIVE_GAP;
Check whether the gap exists. If yes, repeat the above steps until no gap exists.
For logical standby databases:
Perform the following query on the slave database to check whether a gap exists:
SQL & gt; COLUMN FILE_NAME FORMAT a55
SQL & gt; SELECT THREAD #, SEQUENCE #, FILE_NAME FROM DBA_LOGSTDBY_LOG L-
& Gt; WHERE NEXT_CHANGE # not in-
& Gt; (SELECT FIRST_CHANGE # FROM DBA_LOGSTDBY_LOG where l. THREAD # = THREAD #)-
& Gt; order by thread #, SEQUENCE #;
THREAD # SEQUENCE # FILE_NAME
-------------------------------------------------------------------
1 6/disk1/oracle/dbs/log-1292880008_6.arc
1 10/disk1/oracle/dbs/log-1292880008_10.arc
For each THREAD, if an additional record is returned, the gap exists. The archived log is a file with the tail number 7-9. Find these files from the master database, copy them to the slave database, and run the following command:
SQL & gt; ALTER DATABASE REGISTER LOGICAL LOGFILE-
& Gt; '/disk1/oracle/dbs/log-1292880008_7.arc ';
SQL & gt; ALTER DATABASE REGISTER LOGICAL LOGFILE-
& Gt; '/disk1/oracle/dbs/log-1292880008_8.arc ';
SQL & gt; ALTER DATABASE REGISTER LOGICAL LOGFILE-
& Gt; '/disk1/oracle/dbs/log-1292880008_9.arc ';
After completion, re-execute the first step of the query to check whether a new gap is generated until there is no gap.

Author: "crawler of Oracle"