4 ARCH, 3 RFS1 & 1 MRP0

[Former Member]

Dear Db experts,

After Oracle DB upgrade from 10g to 11g , we have seen 4 numbers ARCH 3 Numbers RFS & 1 numbers MRP0 at DR site on following command.

sql> select process, sequence#, status from v$managed_standby;

Just confirm me it is okay or something wrong.

thanks

Kind Regards,

N S Rathore

[Reagan · Accepted solution]

Hello

The default value of LOG_ARCHIVE_MAX_PROCESSES has been change from 2 (on 10G) to 4 (on 11G)

Regards

RB

[Former Member · Accepted solution]

Dear Reagan Sir,

What about RFS ?

Kind Regards,

N S Rathore

[Reagan · Accepted solution]

Hello

To the best of my knowledge the RFS processes are based on the log_archive_max_processes parameter configured on the primary database.

But there is a calculation involved and I am not sure how that is done.

Regards

RB

[stefan_koehler]

Hi N S Rathore,

well there are several mistakes and misconceptions here.

> we have seen 4 numbers ARCH

That's alright, because of 4 is the default value of LOG_ARCHIVE_MAX_PROCESSES.

The LOG_ARCHIVE_MAX_PROCESSES initialization parameter specifies the number of ARCn processes that the database initially starts. The default is four processes. There is usually no need specify this initialization parameter or to change its default value, because the database starts additional archiver processes (ARCn) as needed to ensure that the automatic processing of filled redo log files does not fall behind.
However, to avoid any run-time overhead of starting additional ARCn processes, you can set the LOG_ARCHIVE_MAX_PROCESSES initialization parameter to specify that up to 30 ARCn processes be started at instance startup. The LOG_ARCHIVE_MAX_PROCESSES parameter is dynamic, so you can change it using the ALTER SYSTEM statement.

Source: Oracle Database Administrator's Guide

In most cases the default for LOG_ARCHIVE_MAX_PROCESSES is sufficient. However, in a Data Guard configurations that have multiple standby databases it may be necessary to increase the number of archive processes. The value of the LOG_ARCHIVE_MAX_PROCESSES initialization parameter must be at least one greater than the total number of all remote destinations. Use the following equation when setting the LOG_ARCHIVE_MAX_PROCESSES parameter for highly available environments:
LOG_ARCHIVE_MAX_PROCESSES = sum(remote_destinations) + count(threads)

Source: Set the LOG_ARCHIVE_MAX_PROCESSES Parameter

> 3 Numbers RFS

RFS processes are spawned regarding the amount of remote archiver connections (due to ARC in your DG configuration). One ARC process is related to local archiving on primary database and so 3 are left for DG transmission ... this can be parallelized as well, but needs additional parameter setting MAX_CONNECTIONS.

> 1 numbers MRP0

How many "Managed Standby Recovery Processes" do you expect? It is the coordinator - and like in real life only one guy is the boss

However after explaining all the basic stuff - it is useless anyway in 11g. You usually should not see this at all in your Oracle 11g Data Guard environment (except transfer lags), because of ARC redo transport mode is deprecated.

The ARCH redo transport mode has been deprecated
The ARCH redo transport mode has been deprecated and will be desupported in a future release. Oracle recommends that you switch to the ASYNC transport mode if you are currently using the ARCH transport mode. The ASYNC transport mode is superior to the ARCH transport mode in all respects, and is the new default transport mode.

Source: New Features Common to Redo Apply and SQL Apply

Regards

Stefan

[Former Member]

Dear Sir,

This is a very good information about Archive Max process. Keep in mind and tune that particular parameter.

Thanks a lot.

Kind Regards,

N S Rathore

[stefan_koehler]

Hi N S Rathore,

you don't need to keep all of this ARCH stuff in mind, because of you should not use ARCH redo transport mode at all with Oracle 11g R2. Check out the last paragraph of my previous reply once again.

Regards

Stefan

[former_member206552]

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

[Former Member]

Dear Sir,

It is a very useful tips which you provide me. I am very thankful for you that it will use when we will switch over from primary to DR.

Thanks,

Kind Regards,

N S Rathore