How to check if MRP Process is Running

Below Query is Used to verify if MRP process is running fine on Standby Database, after any maintenance activity that requires disconnect to Primary and Standby database.
SQL> SELECT CLIENT_PROCESS, PROCESS, THREAD#, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;
Below is the sample output from the query:
SQL> SELECT CLIENT_PROCESS, PROCESS, THREAD#, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;
CLIENT_P PROCESS      THREAD#  SEQUENCE# STATUS
——– ——— ———- ———- ————
ARCH     ARCH               2     101072 CLOSING
ARCH     ARCH               0          0 CONNECTED
ARCH     ARCH               1     298101 CLOSING
ARCH     ARCH               2     103073 CLOSING
ARCH     ARCH               3      95398 CLOSING
ARCH     ARCH               1     296100 CLOSING
ARCH     ARCH               3      95399 CLOSING
ARCH     ARCH               3      95400 CLOSING
ARCH     RFS                0          0 IDLE
ARCH     RFS                0          0 IDLE
ARCH     RFS                0          0 IDLE
LGWR     RFS                2     101074 IDLE
LGWR     RFS                1     296102 RECEIVING
UNKNOWN  RFS                0          0 IDLE
UNKNOWN  RFS                0          0 IDLE
LGWR     RFS                3      95401 IDLE
UNKNOWN  RFS                0          0 IDLE
17 rows selected.

Convert Physical database into a Snapshot Standby Database

What are the benefits of Snapshot standby database?
Snapshot Standby Database is introduced from Oracle 11gR1. A Snapshot Standby database is a physical standby that is temporarily disconnected from Data Guard configuration, and started in READ-WRITE mode.It functions as a updateable Stand-alone Database, which is an exact Replica of Primary Database which is normally used for testing purpose. We can revert the Snapshot standby database to Physical Standby database after the testing is completed.
Steps to convert Physical database into a Snapshot Standby Database:
1. First step to convert to Snapshot standby database is to enable FLASHBACK feature on the Physical Standby, if not already enabled.
Ensure there is sufficient space available in Flash Recovery Area (FRA) for Flashback Logs.
2. Stop redo apply on the physical standby database:
SQL>alter database recover managed standby database cancel;
3. Turn on flashback logging:
SQL>alter database flashback on;
4. Convert the standby database into a snapshot standby database:
( For RAC Configurations: Shutdown all other instances except one, which is used as Snapshot standby database)
SQL>alter database convert to snapshot standby;
5.Shut down the snapshot standby database and startup the database (it will be opened for read/write access):
SQL>shutdown immediate;
SQL>startup
After the Snapshot mode is enabled on the database, perform the required testing and revert back to Physical Standby mode after the testing is complete.
Steps to Revert the Physical Standby Database Back to its Original State
1. Change the standby database back into its standby mode (from snapshot mode) as follows:
SQL>startup mount force;
SQL>alter database convert to physical standby;
SQL>shutdown immediate;
SQL>startup nomount;
SQL>alter database mount standby database;
2. Enable redo log apply.
SQL>alter database recover managed standby database using current logfile disconnect;
3.On the primary database, issue the following statement to re-enable archiving to the physical standby database:
SQL>alter system set log_archive_dest_state_2=enable scope=both;

Protection Modes in Oracle Dataguard

We have 3 Protection modes available in Oracle DataGuard
1. Maximum Performance :
This is the default protection mode. It provides the highest level of data protection that is possible
without affecting the performance of a primary database. This is accomplished by allowing transactions to commit as soon as all redo data generated by those transactions has been written to the online log. 
2. Maximum Availability :
This protection mode provides the highest level of data protection that is possible without compromising the availability of a primary database. Transactions do not commit until all redo data needed to recover those transactions has been written to the online redo log and to at least one standby database.
3. Maximum Protection :
This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover a transaction must be written to both the online redo log and to at least one standby database before the transaction commits. To ensure that data loss cannot occur, the primary database will shut down, rather than continue processing transactions.