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_MODEcolumn isREAD 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.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.
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: SUCCESSWe had the general configuration information with the
show configurationcommand. At the end of the output we see the configuration status asSUCCESS, 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 theshow databasecommand 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": SUCCESSThe 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:
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.
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
SYNCmode 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.