Skip Headers
Oracle® Data Guard Broker
10g Release 2 (10.2)

Part Number B14230-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

1 Oracle Data Guard Broker Concepts

This chapter describes the Oracle Data Guard broker, its architecture and components, and how it automates the creation, control, and monitoring of a Data Guard configuration.

The following sections introduce Data Guard broker terminology and concepts:

See Oracle Data Guard Concepts and Administration for the definition of a Data Guard configuration and for complete information about Oracle Data Guard concepts and terminology.

1.1 Overview of Oracle Data Guard and the Broker

Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions. Data Guard maintains these standby databases as transactionally consistent copies of the primary database. If the primary database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the production role, thus minimizing the downtime associated with the outage. Data Guard can be used with traditional backup, recovery, and cluster techniques, as well as the Flashback Database feature to provide a high level of data protection and data availability.

1.1.1 Data Guard Configurations and Broker Configurations

A Data Guard configuration consists of one primary database and up to nine standby databases. The databases in a Data Guard configuration are connected by Oracle Net and may be dispersed geographically. There are no restrictions on where the databases are located if they can communicate with each other. For example, you can have a standby database on the same system as the primary database, along with two standby databases on another system.

The Data Guard broker logically groups these primary and standby databases into a broker configuration that allows the broker to manage and monitor them together as an integrated unit. You can manage a broker configuration using either the Oracle Enterprise Manager graphical user interface or the Data Guard command-line interface.

1.1.2 Oracle Data Guard Broker

The Oracle Data Guard broker is a distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations. The following list describes some of the operations the broker automates and simplifies:

  • Creating Data Guard configurations that incorporate a primary database, a new or existing (physical or logical) standby database, redo transport services, and log apply services, where any of the databases could be Real Application Clusters (RAC) databases.

  • Adding additional new or existing (physical or logical, RAC or non-RAC) standby databases to an existing Data Guard configuration, for a total of one primary database, and from 1 to 9 standby databases in the same configuration.

  • Managing an entire Data Guard configuration, including all databases, redo transport services, and log apply services, through a client connection to any database in the configuration.

  • Managing the protection mode for the broker configuration.

  • Invoking switchover or failover with a single command to initiate and control complex role changes across all databases in the configuration.

  • Configuring failover to occur automatically upon loss of the primary database, increasing availability without manual intervention.

  • Monitoring the status of the entire configuration, capturing diagnostic information, reporting statistics such as the log apply rate and the redo generation rate, and detecting problems quickly with centralized monitoring, testing, and performance tools.

You can perform all management operations locally or remotely through the broker's easy-to-use interfaces: the Data Guard management pages in Oracle Enterprise Manager, which is the broker's graphical user interface (GUI), and the Data Guard command-line interface called DGMGRL.

These interfaces simplify the configuration and management of a Data Guard configuration. Table 1-1 provides a comparison of configuration management using the broker's interfaces and using SQL*Plus.

Table 1-1 Configuration Management With and Without the Broker


With the Broker Without the Broker

General

Provides primary and standby database management as one unified configuration.

You must manage the primary and standby databases separately.

Standby Database Creation

Provides the Enterprise Manager 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.

You must manually:

  • Copy the database files to the standby database.

  • Create a control file on the standby database.

  • Create server parameter or initialization parameter files on the standby database.

Configuration and Management

Enables you to configure and manage multiple databases from a single location and automatically unifies all of the databases in the broker configuration.

You must manually:

  • Set up redo transport services and log apply services on each database in the configuration.

  • Manage the primary database and standby databases individually.

Control

  • Automatically set up redo transport services and log apply services. Simplify management of these services, especially in a RAC environment.

  • Simplifies switchovers and failovers by allowing you to invoke them through a single command.

  • Automates failover by allowing the broker to determine if failover is necessary and initiate failover to a specified target standby database, with no need for DBA intervention and with no loss of data.

  • Integrates Cluster Ready Services (CRS)Foot 1  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.

You must manually:

  • Use multiple SQL*Plus statements to manage the database.

  • Coordinate sequences of multiple commands across multiple database sites to execute switchover and failover operations.

  • Coordinate sequences of multiple commands to manage services and instances during role transitions.

Monitoring

  • Provides continuous monitoring of the configuration health, database health, and other runtime parameters.

  • Provides a unified updated status and detailed reports.

  • Provides integration with Oracle Enterprise Manager events.

You must manually:

  • Monitor the status and runtime parameters using fixed views on each database—there is no unified view of status for all of the databases in the configuration.

  • Provide a custom method for monitoring Oracle Enterprise Manager events.


Footnote 1 Cluster Ready Services (CRS) are part of Oracle Clusterware.

1.2 Benefits of Data Guard Broker

The broker's interfaces improve usability and centralize management and monitoring of the Data Guard configuration. Available as a feature of the Enterprise Edition and Personal Edition of the Oracle database, the broker is also integrated with the Oracle database and Oracle Enterprise Manager. These broker attributes result in the following benefits:

Disaster protection:  By automating many of the manual tasks required to configure and monitor a Data Guard configuration, the broker enhances the high availability, data protection, and disaster protection capabilities that are inherent in Oracle Data Guard. Access is possible through a client to any system in the Data Guard configuration, eliminating any single point of failure. If the primary database fails, the broker automates the process for any one of the standby databases to replace the primary database and take over production processing. The database availability that Data Guard provides makes it easier to protect your data.

Higher availability and scalability with Real Application Clusters (RAC) Databases: While Oracle Data Guard broker enhances disaster protection by maintaining transactionally consistent copies of the primary database, Data Guard, configured with Oracle high availability solutions such as Real Application Clusters (RAC) databases, further enhances the availability and scalability of any given copy of that database. The intrasite high availability of a RAC database complements the intersite protection that is provided by Data Guard broker.

Consider that you have a cluster system hosting a primary RAC database comprised of multiple instances sharing access to that database. Further consider that an unplanned failure has occurred. From a Data Guard broker perspective, the primary database remains available as long as at least one instance of the clustered database continues to be available for transporting redo data to the standby databases. Oracle Clusterware manages the availability of instances of a RAC database. Cluster Ready Services (CRS), a subset of code that is a part of Oracle Clusterware, works to rapidly recover failed instances to keep the primary database available. If CRS is unable to recover a failed instance, the broker continues to run automatically with one less instance. If the last instance of the primary database fails, the broker provides a way to fail over to a specified standby database.

The broker is integrated with CRS so that database role changes occur smoothly and seamlessly. This is especially apparent in the case of a planned role switchover (for example, when a physical standby database is directed to take over the primary role while the former primary database assumes the role of standby). The broker and CRS work together to temporarily suspend service availability on the primary database, accomplish the actual role change for both databases during which CRS works with the broker to properly restart the instances as necessary, then to resume service availability on the new primary database. The broker manages the underlying Data Guard configuration and its database roles while CRS manages service availability that depends upon those roles. Applications that rely on CRS for managing service availability will see only a temporary suspension of service as the role change occurs in the Data Guard configuration.

Note that, while CRS enhances availability of a given copy of the RAC database, the broker enhances availability of the sites and databases across multiple geographically dispersed locations, hence providing disaster protection. Together, the broker and Oracle Clusterware provide a strong foundation for Oracle's high-availability architecture.

Automated creation of a Data Guard configuration: The broker helps you to logically define and create a Data Guard configuration consisting of a primary database and (physical or logical, RAC or non-RAC) standby databases. The broker automatically communicates between the databases in a Data Guard configuration using Oracle Net Services. The databases can be local or remote, connected by a LAN or geographically dispersed over a WAN.

Oracle Enterprise Manager provides a wizard that automates the complex tasks involved in creating a broker configuration, including:

Although DGMGRL cannot automatically create a new standby database, you can use DGMGRL commands to configure and monitor an existing standby database, including those created using Enterprise Manager.

Easy configuration of additional standby databases: After you create a Data Guard configuration consisting of a primary and a standby database, you can add up to eight new or existing, physical or logical standby databases to each Data Guard configuration. Oracle Enterprise Manager provides an Add Standby Database wizard to guide you through the process of adding more databases. It also makes all Oracle Net Services configuration changes necessary to support redo transport services and log apply services across the configuration.

Simplified, centralized, and extended management: You can issue commands to manage many aspects of the broker configuration. These include:

Simplified switchover and failover operations: The broker simplifies switchovers and failovers by allowing you to invoke them using a single key click in Oracle Enterprise Manager or a single command at the DGMGRL command-line interface. (referred to in this documentation as manual failover). For lights-out administration, you can enable fast-start failover to allow the broker to determine if a failover is necessary and initiate the failover to a pre-specified target standby database automatically, with no need for DBA intervention and with no loss of data.

Fast-start failover allows you to increase availability with less need for manual intervention, thereby reducing management costs. Manual failover gives you control over exactly when a failover occurs and to which target standby database. Regardless of the method you choose, the broker coordinates the role transition on all databases in the configuration.

Only one command is required to initiate complex role changes for switchover or failover operations across all databases in the configuration. The broker automates switchover and failover to a specified standby database in the broker configuration. Enterprise Manager enables you to select a new primary database from a set of viable standby databases (enabled and online, with normal status). The DGMGRL SWITCHOVER and FAILOVER commands only require you to specify the target standby database before automatically initiating and completing the many steps in switchover or failover operations across the multiple databases in the configuration.

Built-in monitoring and alert and control mechanisms: The broker provides built-in validation that monitors the health of all of the databases in the configuration. From any system in the configuration connected to any database, you can capture diagnostic information and detect obvious and subtle problems quickly with centralized monitoring, testing, and performance tools. Both Enterprise Manager and DGMGRL retrieve a complete configuration view of the progress of redo transport services on the primary database and the progress of Redo Apply or SQL Apply on the standby database.

The ability to monitor local and remote databases and respond to events is significantly enhanced by the broker's health check mechanism and tight integration with the Oracle Enterprise Manager event management system.

Transparent to application: Use of the broker is possible for any database because the broker works transparently with applications; no application code changes are required to accommodate a configuration that you manage with the broker.

See Also:

Oracle Data Guard Concepts and Administration for a complete description of the discrete steps that comprise the creation of standby databases and the other monitoring and control operations that have been automated or simplified by the broker

1.3 Data Guard Broker Management Model

The broker simplifies the management of a Data Guard environment by performing operations on the following logical objects:

The broker supports one or more Data Guard configurations, each of which includes a profile for the primary database and each standby database. A supported broker configuration consists of:

Figure 1-1 shows the relationship of these objects.

Figure 1-1 Relationship of Objects Managed by the Data Guard Broker

Description of Figure 1-1 follows
Description of "Figure 1-1 Relationship of Objects Managed by the Data Guard Broker"

See also:

Chapter 3, Chapter 4, and Chapter 5 for more information about managing configuration and database objects

1.4 Data Guard Broker Components

The Oracle Data Guard broker consists of the following components:

Oracle Enterprise Manager and the Data Guard command-line interface (DGMGRL) are the broker client interfaces that help you define and manage a configuration consisting of a collection of primary and standby databases. DGMGRL also includes commands to create an observer, a process that facilitates fast-start failover. Section 1.5 describes these interfaces in more detail.

The Data Guard monitor is the broker server-side component that is integrated with the Oracle database. Data Guard monitor is composed of the DMON process and broker configuration files that allow you to control the databases of that configuration, modify their behavior at runtime, monitor the overall health of the configuration, and provide notification of other operational characteristics. Section 1.6 describes the Data Guard monitor in more detail.

Figure 1-2 shows these components of the broker.

Figure 1-2 Oracle Data Guard Broker

Description of Figure 1-2 follows
Description of "Figure 1-2 Oracle Data Guard Broker"

1.5 Data Guard Broker User Interfaces

You can use either of the broker's user interfaces to create a broker configuration and to control and monitor the configuration. The following sections describe the broker's user interfaces:

1.5.1 Oracle Enterprise Manager

Oracle Enterprise Manager works with the Data Guard monitor to automate and simplify the management of a Data Guard configuration.

With Enterprise Manager, the complex operations of creating and managing standby databases are simplified through Data Guard management pages and wizards, including:

  • An Add Standby Database wizard that helps you to create a broker configuration, if one does not already exist, having a primary database and a local or remote standby database. The wizard can create a physical or logical standby database (non-RAC) or import an existing physical or logical (RAC or non-RAC) standby database. If the wizard creates a physical or logical standby database, the wizard also automates the creation of the standby control file, server parameter file, online redo log files, and the standby datafiles.

  • A switchover operation that helps you switch roles between the primary database and a standby database.

  • A failover operation that changes one of the standby databases to the role of a primary database.

  • Performance tools and graphs that help you monitor and tune redo transport services and log apply services.

  • Property pages that allow you to set database properties on any database and, if applicable, the settings are immediately propagated to all other databases and server parameter files in the configuration.

  • Event reporting through e-mail.

In addition, it makes all Oracle Net Services configuration changes necessary to support redo transport services and log apply services.

Figure 1-3 shows the Data Guard overview page in Oracle Enterprise Manager.

Figure 1-3 Data Guard Overview Page in Oracle Enterprise Manager

Description of Figure 1-3 follows
Description of "Figure 1-3 Data Guard Overview Page in Oracle Enterprise Manager"

See Also:

Oracle Enterprise Manager online help

1.5.2 Data Guard Command-Line Interface (DGMGRL)

The Data Guard command-line interface (DGMGRL) enables you to control and monitor a Data Guard configuration from the DGMGRL prompt or within scripts. You can perform most of the activities required to manage and monitor the databases in the configuration using DGMGRL commands.

DGMGRL also includes commands to create an observer process that continuously monitors the primary and target standby databases and evaluates whether failover is necessary, and then initiates a fast-start failover when conditions warrant.

Table 1-2 lists the DGMGRL commands.

Table 1-2 DGMGRL Commands

Command Description

ADD

Adds a standby database to the broker configuration

CONNECT

Connects to an Oracle instance

CREATE

Creates a broker configuration

DISABLE

Disables a configuration, a database, or fast-start failover

EDIT

Edits a configuration, database, or instance

ENABLE

Enables a configuration, a database, or fast-start failover

EXIT

Exits the program

FAILOVER

Changes a standby database to be the primary database

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

1.6 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.

See Also:

Section 3.3 for information on starting the broker.

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.

See Also:

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

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.

Figure 1-4 Databases With Broker (DMON) Processes

Description of Figure 1-4 follows
Description of "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.

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.

See Also:

Section 4.3 for more information

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.

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.