The Data Guard broker can be configured on existing or new Data Guard configurations either with physical or with logical standby databases with a global configuration.
The Data Guard broker provides a graphical user interface and command-line interface for the simple management and automation of management and operational tasks across multiple databases in a Data Guard configuration. The broker monitors all of the systems within a single Data Guard configuration. You can perform all management operations locally or remotely through the broker's easy-to-use interfaces, such as the Data Guard management pages in Oracle Enterprise Manager Cloud Control, that is, the broker's graphical user interface and the Data Guard command-line interface called DGMGRL.
Integration with Enterprise Manager Cloud Control simplifies the management of standby databases by using graphical consoles. All operations are controlled through navigation when managed with Cloud Control. Role transitions (switchovers and failovers) can be performed, and redo transport and log apply services can be monitored using graphical consoles. In the case of any warning or error occurring in the Data Guard configuration, alerts can be received via e-mails. Enterprise Manager can perform Oracle Net Services configurations as they are required to support redo transport and log apply services.
To enable all the features required by Data Guard with Cloud Control, the following compatibility of Enterprise Manager with broker requirements should be met:
|
Database Version |
Enterprise Manager Cloud / Grid Control |
|---|---|
|
10.2.0.X |
10.2.0.1 and above |
|
11.1.0.X |
10.2.0.5 |
|
11.2.0.X |
10.2.0.5 with patches |
Oracle Data Guard and RAC are the two products that combine in such a way that they enhance or emphasize each other's qualities. RAC refers to node or instance failures; it provides automatic instance recovery from failures, such as node failures, instance crashes, or service lost failures, that do not affect data. It also provides scalability along with high availability. On the other hand, Data Guard provides data protection through the use of transactional images in primary and standby databases. Data Guard enables recovery from site disasters or data corruptions.
In RAC, all the instances of nodes share the same data, including control files and datafiles, but the Data Guard data/control/redo logfiles are exclusive to primary and standby databases.
Use of Data Guard broker with RAC databases is supported by Oracle 10g.
Performing role transitions with the broker helps avoid the need to perform tiresome tasks. To perform a switchover between a primary and standby database using SQL*Plus, you have to execute the commands step-by-step and check the synchronization and switchover status from both sites, the switchover status of both the sites, and the step-by-step commands from the primary and standby locations. The broker simplifies the performance of switchover and failover operations by gathering many tasks under a single command.
Fast-start failover was introduced to reduce unplanned downtime. Automatic database failover may occur because a primary database is down, due to designated health-check conditions, or due to the request of an application. FSFO (fast-start failover) is a feature of the broker that records information about the failover target, informs how long to wait after a failure before triggering another failover, and also records other FSFO-specific properties. When a fast-start failover is enabled, the Data Guard broker automatically fails over to a synchronized standby site in the event of a disaster at the primary site; it requires no intervention by the DBA. In addition to this, applications are automatically notified of the role transition. The disadvantage is that even though both the primary and standby databases' state is good, if there is any connectivity issue between the primary server and the observer server, failover will be initiated.
To sum up, the Data Guard broker can restart failed processes, manage CRS, automate switchovers/failovers, integrate with OEM so you can use GUI for management, and collect additional metrics for monitoring. On the other hand, one advantage of using SQL*Plus is that it requires you to have a full understanding of what's going on behind the scenes. We would recommend setting up a Data Guard configuration manually at least once, for the purpose of your own learning. You will have a better scope to learn. The broker has the advantage of providing shortcuts to the functions you might need to perform with your Data Guard configuration. If you use SQL*Plus to manage Data Guard, you'll likely develop scripts that are already duplicating some broker functionality.
For example, the first time that you create a standby and the first time you run a switchover, it would be good to do it with SQL*Plus and tail the alert log so that you can understand the parameters and see how it works. After you have successfully done a few switchovers manually, move to the Data Guard broker, and you will appreciate how much easier it is, how many errors it fixes, as well as understanding exactly what it is doing.