Which three are among the various tasks performed by the data Guard Monitor (DMON) process?

So I will say B,D,E

http://docs.oracle.com/database/121/DGBKR/concepts.htm#DGBKR045

I think that is ABCE

D – This is wrong! This is wrong because the observer (external/remote) does not contain a DMON process; only databases monitored by the broker configuration have the DMON process

For me, ABCE is correct!

Doubt is the best answer between “A” d “C”…

What do you think about?

See:

Oracle Database 12c: Data Guard Administration Student Guide – Volume I
Data Guard Broker: Components
• Client-side:
— Oracle Enterprise Manager Cloud Control
— DGMGRL (command-line interlace)
• Server-side: Data Guard monitor
— DMON process
— Configuration files

The Oracle Data Guard broker consists of both client-side and server-side components.
On the client, you can use the following Data Guard components to define and manage a configuration:
• Oracle Enterprise Manager Cloud Control
• DGMGRL, which is the Data Guard command-line interface (CLI)
On the server, the Data Guard monitor is a broker component that is integrated with the Oracle database. The Data Guard monitor comprises the Data Guard monitor (DM0N) process and broker configuration files, with which you can control the databases of that configuration, modify their behavior at run time, monitor the overall health of the configuration, and provide notification of other operational characteristics.
The configuration file contains profiles that describe the current state and properties of each database in the configuration. 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.

The Data Guard broker helps you create, control, and monitor a Data Guard configuration.
This configuration consists of a primary database that is protected by one or more standby databases. After the broker has created the Data Guard configuration, the broker monitors the activity, health, and availability of all systems in that configuration.
The Data Guard monitor process (DMON) is an Oracle background process that runs on every instance that is managed by the broker, including Far Sync instances. When you start the Data Guard broker, a DMON process is created.
When you use Enterprise Manager or the Data Guard command-line interface (CLI), the DMON process is the server-side component that interacts with the local instance and the DMON processes that are running on other sites to perform the requested function. The DMON process is also responsible for monitoring the health of the broker configuration and for ensuring that every instance has a consistent copy of the configuration files in which the DMON process stores its configuration data. There are two multiplexed versions of the configuration file on each database.

Data Guard Monitor: DMON Process
• A server-side background process
• A part of each database instance in the configuration
• Created when you start the broker
• Performs requested functions and monitors the resource
• Communicates with other DMON processes in the configuration
• Updates the configuration file
• Creates the drc trace file in the location set by the DIAGNOSTIC DEST initialization parameter
• Modifies initialization parameters during role transitions as necessary

The Data Guard monitor comprises two components: the DMON process and the configuration file.
The DMON process is an Oracle background process that is part of each database instance managed by the broker. When you start the Data Guard broker, a portion of the SGA is allocated and a DMON process is created. The amount of memory allocated is typically less than 50 KB per site; the actual amount on your system varies.
When you use Enterprise Manager or the CLI, the DMON process is the server-side component that interacts with the local instance and the DMON processes running on other sites 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 copy of the broker configuration files in which the DMON process stores its configuration data.
The DIAGNOSTIC_DEST parameter defines the location for diagnostic files such as trace files and core files. The structure of the directory specified by DIAGNOSTIC_DEST is as follows: /diag/rdbms///
This location is known as the Automatic Diagnostic Repository (ADR) Home. The DMON trace files are located in the /trace subdirectory.

Oracle® Data Guard Broker 12c Release 1 (12.1) – E48241-08
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.
When you use the Data Guard GUI or the CLI 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.

2.1 Configuration Support
…
The broker’s DMON process configures and maintains the broker configuration as a group of objects that you can manage and monitor as a single unit. Thus, when you enter a command that affects multiple databases, the DMON process:
Carries out your request on the primary database
Coordinates with the DMON process for each of the other databases, as required for your request
Updates its local configuration file
Communicates with the DMON process for each of the other databases to update their copies of the configuration file

The DMON process enables you to configure, monitor, and control the databases and the configuration together as a unit. If the configuration is disabled, broker management of all of the databases in the configuration is also disabled. If you later request the configuration to be enabled, broker management is enabled for each database in the configuration.

With the Broker
– Provides primary and standby database management as one unified configuration.
– Provides the Data Guard GUI wizards that automate and simplify the steps required to create a configuration with an Oracle database on each site, including creating the standby control file, online redo log files, datafiles, and server parameter files.
– Enables you to configure and manage multiple databases from a single location and automatically unifies all of the databases in the broker configuration.
Automatically set up log transport services and log apply services. Simplify management of these services, especially within a RAC database environment.
Automates switchover and failover.
Automates CRS service and instance management over database role transitions.
Provides mouse-driven database state changes and a unified presentation of configuration and database status.
Provides mouse-driven property changes.
Provides continuous monitoring of the configuration health, database health, and other runtime parameters.
Provides a unified updated status and detailed reports.
Provides an integrated tie-in to Oracle Enterprise Manager events.

Client Failover Best Practices for Highly Available Oracle Databases Oracle Database 12c
ORACLE WHITE PAPER | AUGUST 2015
The best practices described in this paper require that the Data Guard configuration be managed by the Data Guard Broker13. The Data Guard Broker is responsible for sending FAN events to client applications in order to clean up their connections to the down database and reconnect them to the new production database. The Data Guard broker also coordinates with Oracle Clusterware (or Oracle Restart for single instance databases) to properly fail over role-based services to a new primary database after a Data Guard failover has occurred.

Initial Connections
Read-only queries and reporting applications can be directed to an Active Data Guard standby by creating a database service description that will start a read-only service anytime a database functions in the standby role. Because role-based services are controlled by the Data Guard Broker and CRS (Oracle Restart in the case of single instance databases), services will also be started/stopped appropriate for the database role whenever a Data Guard role transition occurs.