Re: 4 ARCH, 3 RFS1 & 1 MRP0

Hi Rathore

please have a look at the following

Verify Redo is Current with Primary

Make certain that the standby (physical or logical) is applying changes from the primary. Also verify that the application of redo is current with the primary.

From the primary database, perform a log switch and then verify the transmissions of the archived redo log file was successful. If the transmission was successful, the status of the destination will be VALID as shown below.

SQL> alter system switch logfile;    System altered.      SQL> select status, error from v$archive_dest where dest_id = 2;    STATUS    ERROR  --------- ---------------------------------------------------------  VALID

Once it has been determined that the redo stream is current, make sure that the redo has been applied to the standby database. In the case of a physical standby database, verify Redo Apply by querying the status of the MRP0 process in V$MANAGED_STANDBY:

SQL> select client_process, process, sequence#, status  2  from v$managed_standby;    CLIENT_PROCESS PROCESS    SEQUENCE# STATUS  -------------- --------- ---------- ------------  ARCH           ARCH               0 CONNECTED  ARCH           ARCH               0 CONNECTED  ARCH           ARCH               0 CONNECTED  ARCH           ARCH               0 CONNECTED  N/A            MRP0             732 WAIT_FOR_LOG  N/A            RFS                0 IDLE

In the case of a physical standby database, if the MRP0 record is not returned in the above query, then redo apply is not running. In order ensure an efficient switchover process, Redo Apply should be started and caught up with the current redo stream:

SQL> startup mount    [ START REDO APPLY ]     SQL> alter database recover managed standby database disconnect;    [ START REDO APPLY USING REAL-TIME APPLY ]     SQL> alter database recover managed standby database using current logfile disconnect;

If the MRP0 record is returned but shows a status of WAIT_FOR_GAP, the switchover operation cannot occur until the redo gap has been resolved.

If the status of the MRP0 process is APPLYING_LOG then the standby is current and using real-time apply and current with the primary database.

Finally, if the status of the MRP0 process is WAIT_FOR_LOG, the standby is not running real-time apply (which is OK) or the DELAY qualifier was specified for the destination. If the DELAY qualifier was specified, stop the apply process and restart it with the NODELAY qualifier; otherwise the switchover operation will not complete. If the DELAY qualifier was not set and the standby is not using real-time apply, then it should be current with the primary database.

Verify Standby Redo Log (SRL) Files on the Primary

The physical standby database used in this example is configured with standby redo log (SRL) files. Verify that SRL files have been created on the current primary database so that it can receive the redo when it becomes a standby.

SQL> select group#, status, type, count(*) as "Members"  2  from v$logfile  3  group by group#, status, type  4  order by group#;    GROUP# STATUS  TYPE       Members  ---------- ------- ------- ----------  1         ONLINE           2  2         ONLINE           2  3         ONLINE           2  4         STANDBY          2  5         STANDBY          2  6         STANDBY          2  7         STANDBY          2

source: http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml

Hope it helps

Marius