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.