DataGuardGapDetectionandResolution(DocID232649.1)(二)
process locates the remote archive destination with the corresponding service
name and ships the missing archived redo logs. If the first destination listed
in FAL_SERVER is unable to resolve the gap then the next destination is
attempted until either the gap is resolved or all FAL_SERVER destination have
been tried.
As of 9.2.0 FAL Gap Resolution only works with Physical Standby databases as
the process is tied to MRP. Gap recovery on a logical standby database is
handled through the heartbeat mechanism.
Simulating Gap Recovery
==========================
The follow steps can be used to illustrate and verify both automatic and FAL
gap recovery. As the steps involve shutting down the standby database, which
can impact disaster recovery, it is recommended to perform these procedures
in a test environment.
Automatic Gap Resolution:
1. Shutdown the physical standby database.
2. Determine the current sequence on the primary database.
3. Perform at least three log switches on the primary database.
4. Verify that the logs did not get transferred to the standby archive dest.
5. Start the standby database.
6. Perform a log switch on the primary and verify that the gap gets resolved
on the standby.
FAL Gap Resolution:
1. In the standby init.ora define the fal_server and fal_client parameters.
2. Bounce the standby database so that the parameters are put into effect.
3. Perform three log switches on the primary database.
4. In the standby_archive_dest directory delete the middle archive log on
the standby.
5. Start managed recovery and verify that the gap is resolved by FAL_SERVER
and FAL_CLIENT.
Manually Resolving a Gap:
=============================
In some rare cases it might be necessary to manually resolve gaps. The following
section describes how to query the appropriate views to determine if a gap
exists.
On your physical standby database:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query the V$ARCHIVE_GAP view:
SQL>
SELECT * FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
----------- ------------- --------------
1 443 446
The query results show that your physical standby database is currently missing
logs from sequence 443 to sequence 446 for thread 1. After you identify the
gap, issue the following SQL statement on the primary database to locate the
archived redo logs on your primary database:
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND
2> SEQUENCE# BETWEEN 443 AND 446;
NAME
--------------------------------------------------------------------------------
/u01/oradata/arch/arch_1_443.arc
/u01/oradata/arch/arch_1_444.arc
/u01/oradata/arch/arch_1_445.arc
Copy the logs returned by the query to your physical standby database and
register using the ALTER DATABASE REGISTER LOGFILE command.
SQL> ALTER DATABASE REGISTER LOGFILE
'/u01/oradata/stby/arch/arch_1_443.arc';
SQL> ALTER DATABASE REGISTER LOGFILE
'/u01/oradata/stby/arch/arch_1_444.arc';
SQL> ALTER DATABASE REGISTER LOGFILE
'/u01/oradata/stby/arch/arch_1_445.arc';
Once the log files have been registered in the standby controlfile, you can
restart the MRP process.
On a logical standby database:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query the DBA_LOGSTDBY_LOG view.
SQL> SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L
2> W