Time for action – using interfaces to monitor Data Guard

1. At the first step we will use SQL*Plus to gather information from Data Guard and monitor its status. The connection to the standby database must be from the standby database server with password file authentication if the standby database is on mount mode and so not accessible from outside. If Active Data Guard is enabled, it's also possible to connect a standby database remotely. Let's connect to the standby database and gather the main Data Guard configuration information:

   $sqlplus / as sysdba
   SQL> select database_role,open_mode,protection_mode from v$database;
   
   DATABASE_ROLE      OPEN_MODE             PROTECTION_MODE
   ----------------   --------------------  --------------------
   PHYSICAL STANDBY   READ ONLY WITH APPLY  MAXIMUM PERFORMANCE
   
   SQL> select recovery_mode from v$archive_dest_status where recovery_mode !='IDLE';
   
   RECOVERY_MODE
   -----------------------
   MANAGED REAL TIME APPLY
   

   We have a physical standby database with the Maximum Performance mode. The value of the OPEN_MODE column is READ ONLY WITH APPLY, which indicates that Active Data Guard is enabled. The output of the second query shows that real-time apply is being used as the recovery mode.

2. Now let's check the status of the Data Guard synchronization:

   SQL> select name, value from v$dataguard_stats;
   NAME                      VALUE
   ------------------------- ---------------
   transport lag             +00 00:00:00
   apply lag                 +00 00:00:00
   apply finish time
   estimated startup time    231

   The output shows that we have a fully synchronized standby database, where there is no redo transport and apply lag. The estimated startup time value is 231 seconds, which is an estimate of the time needed to start and open the standby database.

3. Now we'll see an example about how to use Data Guard broker command-line interface (DGMGRL) to gather information about the Data Guard status. We can run DGMGRL on the primary database server and connect locally or we can also connect from a remote server. Let's connect from the primary database server locally:

   $dgmgrl
   DGMGRL> connect sys/password;
   Connected.
   We have connected to the primary database with the sys user.Now we can check the configuration.
   DGMGRL> show configuration;
   Configuration - TEST
     Protection Mode: MaxPerformance
     Databases:
       Turkey    - Primary database
       India     - Physical standby database
   
   Fast-Start Failover: DISABLED
   
   Configuration Status:
   SUCCESS
   

4. We had the general configuration information with the show configuration command. At the end of the output we see the configuration status as SUCCESS, which means, everything in the broker configuration is working properly. However, we can also see a status of warning or error. We can also run the show database command for some general information:

   DGMGRL> show database 'India';
   Database
     Name:            India
     Role:            PHYSICAL STANDBY
     Enabled:         YES
     Intended State:  ONLINE
     Instance(s):
       india
   Current status for "India":
   SUCCESS

   Tip

   In order to gather detailed information from the databases in the Data Guard configuration, we use the keyword verbose in the show database command such as show database verbose 'India'.

5. The last interface to monitor and manage a Data Guard configuration is the Enterprise Manager Cloud Control, with the former name Enterprise Manager Grid Control. The following screenshot shows the interface for the monitoring and administration of Data Guard. Detailed information will be given in Chapter 8, Integrating Data Guard with the Complete Oracle Environment, about using Enterprise Manager Cloud Control for Data Guard management:

   

What just happened?

You have just seen examples of monitoring the Data Guard environment with three different interfaces. These examples are just intended to give you a first impression of what these interfaces look like. Properties and details of the tools in question will be covered in the next chapters.

All of these interfaces can be used to monitor and manage the Data Guard; however, they all have their own pros and cons. If you already use Enterprise Manager Cloud Control in your current IT infrastructure, Data Guard installations must be added as targets in order to take advantage of its visual and easy monitoring and management potential. If you don't have Cloud Control but have multiple Data Guard installations, you should think about using it to overcome the challenges of central monitoring.

Data Guard background processes

In a Data Guard configuration we can see some Oracle Data Guard specific background processes in both, primary and standby databases. These processes perform the operations of redo transport and apply services. Data Guard broker also has some specific background processes. We can see the description and duties of the most important Data Guard processes as follows:

• MRP0 (Managed Standby Recovery Process) coordinates the read and apply process of redo in a physical standby database.

• RFS (Remote File Server) is responsible for receiving the redo data, which is sent by the primary database to the standby database.

• LSP0 (Logical Standby Coordinator Process) coordinates the SQL Apply processes, which are the mining processes and apply processes.

• LSP1 (Logical Standby Dictionary Build Process) is used on the logical standby databases when a switchover or failover is in action.

• LSP2 (Logical Standby Set Guard Process) is used to operate Database Guard settings. Database Guard specifies which objects will be protected for modification in a logical standby database.

• NSAn (Redo Transport NSA1 Process) is used on the primary database to ship redo data to the standby database when ASYNC mode is being used. There may be multiple NSA processes such as NSA1 and NSA2.

• NSSn (Redo Transport NSA1 Process) is also used on the primary database to ship redo data to the standby database. However, only when the SYNC mode is being used.

• DMON (Data Guard Broker Monitor Process) runs on every instance in a Data Guard broker configuration. It communicates with local database and DMON processes of the remote databases. The broker-related requests and the monitoring information are transferred on this communication channel.

• FSFP (Data Guard broker fast-start failover pinger process) is used for the management of fast-start failover status.