Data Guard Monitor

The configuration, control, and monitoring functions of the broker are implemented by server-side software and configuration files that are maintained for each database that the broker manages. The software is called the Data Guard monitor.

The following sections describe how the Data Guard monitor interacts with the Oracle database and with remote Data Guard monitors to manage the broker configuration.

1.6.1 Data Guard Monitor (DMON) Process

The Data Guard monitor process (DMON) is an Oracle background process that runs for every database instance that is managed by the broker. When you start the Data Guard broker, a DMON process is created.

Whether you use Oracle Enterprise Manager or DGMGRL to manage a database, the DMON process is the server-side component that interacts with the local database and the DMON processes of the other databases to perform the requested function. The DMON process is also responsible for monitoring the health of the broker

configuration and for ensuring that every database has a consistent description of the configuration.

Figure 1–4 shows the broker’s DMON process as one of several background processes that constitute an instance of the Oracle database. Figure 1–4 shows multiple

databases, each having its own DMON process.

HELP Displays description and syntax for individual commands

QUIT Exits the program

REINSTATE Changes a disabled database into a viable standby database REM Comments to be ignored by DGMGRL

REMOVE Removes a configuration, database, or instance

SHOW Displays information of a configuration, database, or instance SHUTDOWN Shuts down a currently running Oracle instance

START Starts the fast-start failover observer STARTUP Starts an Oracle database instance STOP Stops the fast-start failover observer

SWITCHOVER Switches roles between the primary database and a standby database

See Also: Chapter 8 for complete reference information for the Data Guard command-line interface

See Also: Section 3.3 for information on starting the broker.

See Also: Oracle Database Concepts for more information about the memory structures and processes that are used with an Oracle database

Table 1–2 (Cont.) DGMGRL Commands

Command Description

Data Guard Monitor

Figure 1–4 Databases With Broker (DMON) Processes

The zigzag arrow in the center of Figure 1–4 represents the two-way Oracle Net Services communication channel that exists between the DMON processes of two databases in the same broker configuration.

This two-way communication channel is used to pass requests between databases and to monitor the health of all of the databases in the broker configuration.

When creating a new Data Guard configuration or adding a new standby database into an existing configuration, the DMON process uses an initial connect identifier to connect to the database to collect necessary information about the database. This initial connect identifier is supplied by the user if DGMGRL is used, or constructed

automatically if Oracle Enterprise Manager is used.

After the initial connection, the DMON process constructs connect descriptors for communication with other DMON processes on other databases, using the address value from the LOCAL_LISTENER initialization parameter from those databases. The DMON processes automatically manage the connections to each other. If a database is a RAC database, then as long as one instance in the database is running and the DMON process is started on the instance, that DMON process is able to establish two-way communications with other DMON processes on other databases to manage the database as part of the Data Guard configuration.

Oracle Database Instance

Data Guard Monitor

1.6.2 Configuration Management

The broker’s DMON process persistently maintains profiles about all database objects in the broker configuration in a binary configuration file. A copy of this file is

maintained by the DMON process for each of the databases that belong to the broker configuration. If it is a RAC database, each database’s copy of the file is shared by all instances of the database.

This configuration file contains profiles that describe the states and properties of the databases in the configuration. For example, the file records the databases that are part of the configuration, the roles and properties of each of the databases, and the state of each database in the configuration.

The configuration data is managed transparently by the DMON process to ensure that the configuration information is kept consistent across all of the databases. The broker uses the data in the configuration file to configure and start the databases, control each database’s behavior, and provide information to DGMGRL and Oracle Enterprise Manager.

Whenever you add databases to a broker configuration, or make a change to an existing database’s properties, each DMON process records the new information in its copy of the configuration file.

1.6.3 Database Property Management

Associated with each database are various properties that the DMON process uses to control the database’s behavior. The properties are recorded in the configuration file as a part of the database’s object profile that is stored there. Many database properties are used to control database initialization parameters related to the Data Guard

environment.

To ensure that the broker can update the values of parameters in both the database itself and in the configuration file, you must use a server parameter file to control static and dynamic initialization parameters. The use of a server parameter file gives the broker a mechanism that allows it to reconcile property values selected by the database administrator (DBA) when using the broker with any related initialization parameter values recorded in the server parameter file.

When you set values for database properties in the broker configuration, the broker records the change in the configuration file and propagates the change to all of the databases in the Data Guard configuration.

See Also: Section 4.3 for more information

Note: The broker supports both the default and nondefault server parameter file filenames. If you use a nondefault server parameter filename, the initialization parameter file must include the complete filename and location of the server parameter file. If this is a RAC database, there must be one nondefault server parameter file for all instances.

See Also: Section 4.3.2 for more information.

2