2 Managing Broker Configurations

2.1 Configuration Support

The broker enables you to logically define a Data Guard configuration, consisting of a primary database and physical and logical standby databases. With the broker, you define a broker configuration that is a logical grouping of the databases, including log transport services and log apply services. At the DBA's discretion, the broker controls the logical objects in the configuration, modifies their behavior at runtime, monitors the overall health of the configuration, and reports any health and other operational characteristics up through the Oracle Enterprise Management notification mechanisms if you are using the Data Guard GUI, or through SHOW commands if you are using the CLI.

The broker supports Data Guard configurations consisting of a primary database, and up to nine standby databases that are either local to, or, remote from, the primary database, and any of those databases can be an Oracle Real Application Clusters (RAC) database.

A supported Data Guard configuration contains the following components:

• A (RAC or non-RAC) primary database

• From one to nine physical or logical (RAC or non-RAC) standby databases

• Physical systems that host the primary and standby databases

• Oracle Net Services network configuration that defines a connection between the databases

• Standby (archived redo log files) destination parameters and configuration properties

• Log transport services that transmit the redo data from the primary database to the standby databases

• Log apply services that apply the archived redo log files or standby redo log files to the standby databases as they arrive from the primary database

The standby database is updated with redo data that is transmitted automatically from the primary database by log transport services. The archived redo log file and standby redo log file contain all of the database changes except for unrecoverable or unlogged changes. On the standby database, log apply services apply the archived redo log files to stay synchronized with the primary database. Thus, the standby database can take over operations if the primary database becomes unusable.

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.

Figure 2-1 shows a two-database broker configuration with the Data Guard monitor (DMON) process running at each location.

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

2.2 Setting Up the Broker Configuration Files

Two copies of the configuration file are maintained for each database so as to always have a record of the last known valid state of the configuration. When the broker is started for the first time, the configuration files are automatically created and named using a default path name and filename that is operating-system specific. You can override this default path name and filename by setting the following initialization parameters for that database:

DG_BROKER_CONFIG_FILE1
DG_BROKER_CONFIG_FILE2

If the broker is managing a RAC database, the value of DG_BROKER_CONFIG_FILE1 and the value of DG_BROKER_CONFIG_FILE2 for each of the instances must point to the same set of physical files. In other words, all instances of the database must reference the same set of configuration files. If cluster file system (CFS) is available, and the configuration files reside there, the DG_BROKER_CONFIG_FILEn parameters on all of the instances must be set to these files including the path to the CFS area. Figure 2-2 shows the set up for the broker configuration files on CFS. In this scenario, the parameters and value for all instances would be:

DG_BROKER_CONFIG_FILE1=$ORACLE_BASE/admin/db_unique_name/dr1db_unique_name.dat
DG_BROKER_CONFIG_FILE2=$ORACLE_BASE/admin/db_unique_name/dr2db_unique_name.dat

If CFS is not available, the files must be on raw devices. In this case, the parameter values on each of the instances must point to the raw devices. Figure 2-3 shows the set up for the broker configuration files on raw devices. On a UNIX system, you would set this up similar to the following:

%ln -s /dev/rdsk/c1t2d3s5 dr1instn.dat

You can change the configuration filenames dynamically by issuing the ALTER SYSTEM SQL statement. However, you cannot alter these parameters when the DMON process is running. To change the names of these configuration files for a given database, perform the following steps:

1. Disable the broker configuration using the CLI DISABLE command. See Section 2.5.

2. Stop the Data Guard broker DMON process using the following SQL statement:

   SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE;
   
   

3. Change the configuration filenames for the database:

   SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE1=filespec1
   SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE2=filespec2
   

   
   

   Note: If the broker is managing a RAC database, the value of DG_BROKER_CONFIG_FILE1 and the value of DG_BROKER_CONFIG_FILE2 for each of the instances must point to the same set of physical files.

   
   

4. If not on raw devices, rename the existing files to filespec1 and filespec2, respectively, at the operating system level to avoid losing the existing broker configuration information.

5. Restart the Data Guard broker DMON process, as follows:

   SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;
   
   

6. Enable the broker configuration using the CLI ENABLE command or the Enable operation in the Data Guard GUI.

2.3 Starting the Data Guard Broker

After setting up the configuration files, the DG_BROKER_START initialization parameter must be set to TRUE for each database to start the Data Guard monitor (DMON) processes.

By default, the DG_BROKER_START initialization parameter is set to FALSE. However, you can set the value in the following ways:

• If you are using the Data Guard GUI, it automatically sets the DG_BROKER_START initialization parameter to TRUE for new standby databases that it creates.

• If you are using the CLI, you must explicitly set the DG_BROKER_START initialization parameter to TRUE; otherwise, the DMON process will not start. You can set the DG_BROKER_START initialization parameter with the following SQL statement:

  SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;
  
  System altered.
  
  SQL> SHOW PARAMETER DG_BROKER_START
  
  NAME               TYPE      VALUE
  ------------------------------------  
  dg_broker_start    boolean   TRUE
  
  

Whether you use the Data Guard GUI or the CLI, set the DG_BROKER_START=TRUE initialization parameter in the server parameter file on each primary and standby database. Doing so ensures that the DMON processes will start automatically the next time you start any instance of the database.

2.4 Management Cycle of a Broker Configuration

The broker helps you to create a new configuration or manage an existing configuration. Figure 2-4 shows the life cycle of a broker configuration.

Create the Broker Configuration

When using the Data Guard GUI, the Add Standby Database wizard can either add an existing (RAC or non-RAC) standby database into the configuration or create a new (non-RAC only) standby database and add it to the configuration. The standby database can be either a physical or logical database.

When using the CLI, the primary database and a standby database must already exist. You construct the standby database from backups of the primary database control files and datafiles, and then prepare it for recovery.

Enable the Broker Configuration

A Data Guard configuration must be enabled to be managed or monitored by the broker. Conversely, you disable a configuration if you no longer want to manage it with the broker. When you disable a configuration, broker management of all of its databases is also disabled.

A broker configuration, when first created using the Data Guard GUI, is automatically enabled as soon as the Add Standby Database wizard completes.

A broker configuration, when first created using the CLI, is in a disabled condition. This means its constituent databases are not yet under active control of the Data Guard monitor. When you finish configuring the databases into a broker configuration with the CLI, you must enable the configuration to allow the Data Guard monitor (DMON) process to manage the configuration.

You can enable:

• The entire configuration, including all of its databases

• An individual standby database

You can easily disable a database if a problem occurs and you can no longer function properly in the broker configuration.

You may also want to disable a configuration temporarily, and then change some properties in the broker configuration without affecting the actual database properties. The changed properties will take effect when the configuration is enabled again for management by the broker.

Make Role Changes Within the Broker Configuration, As Needed

At any time, you can issue a single command to change the roles of the databases in the configuration. If some event renders the primary database unusable, you can fail over one of the standby databases to become the new primary database.

In addition, planned downtime for maintenance can be reduced because you can quickly switch over production processing from the current primary database to a standby database, and then switch back again after the planned maintenance.

Make State Changes to the Databases, As Needed

The Data Guard broker transitions the databases into an online state, by default, the first time that you enable the database.

At any time, you can issue a single command through the Data Guard GUI or the CLI to change the state of the database. For example, you could bring the primary database into a LOG-TRANSPORT-OFF state to temporarily stop archiving log files to the standby database. Then, you issue another command to return the database to a full online state (that is, online and archiving log files to the standby databases).

Update Database Properties, As Needed

The Data Guard broker enables you to set database properties, some of which correspond to database initialization parameters. You can change these properties to dynamically control such things as log transport, file management, log apply, and to support the overall configuration protection mode. The broker records the changes in the broker configuration file for each database in the Data Guard configuration and propagates the changes to the related initialization parameters in the server parameter files, if needed.

Set Data Protection Levels, As Needed

The Data Guard broker enables you to set the data protection level for the configuration. You can configure the protection mode to maximize data protection, maximize availability, or maximize performance.

Monitor the Configuration

You can check the health of the configuration, display and update the properties of the databases, and set Oracle Enterprise Manager events.

The Data Guard GUI also provides a dynamic performance page that automatically and dynamically refreshes chart data and status at specified intervals. The performance chart shows a graphical summary of how far behind and how much redo data is being generated and applied.

2.5 Enable and Disable Operations

A key concept of management with the broker is the notion of enabling and disabling broker management of the databases in a broker configuration. The enable and disable operations are defined for databases that were incorporated into a broker configuration; you cannot perform these broker operations on the physical components of a Data Guard configuration, nor on databases that are not part of the broker configuration. This is because when you enable or disable a database in the broker configuration, you are effectively enabling or disabling the ability of the Data Guard monitor (DMON) process to:

• Manage and monitor the specified database.

• Manage the profile information in the broker configuration file for each database.

However, disabling a broker configuration does not affect current services and operations in the actual Data Guard configuration. For example, when you disable a broker configuration, log transport services and log apply services in the Data Guard configuration continue to function unchanged, but you can no longer manage them through the broker interfaces.

In addition, disabling a database does not remove or delete its profile from the broker configuration file. You can reenable your ability to manage with the broker using the CLI ENABLE CONFIGURATION or ENABLE DATABASE commands, or the Enable option in the Data Guard GUI.

Disabling broker management of the configuration may be useful to do even though you are removing the broker's ability to monitor and control the databases. For example, it may be advantageous to disable a configuration temporarily in order to change one or more properties in the broker configuration all at the same time. When you change properties in a disabled configuration, it does not affect the actual database properties underneath because the changes are not applied to the running database until you reenable the configuration. For example, you might want to change the overall configuration protection mode and the log transport services properties on a disabled configuration so that all changes are applied to the configuration at the same time upon the next enable operation.

2.6 Configuration Status

A configuration status reveals the overall health of the configuration. Status of the configuration is acquired from the status of all of its databases.

The following list describes the possible status modes for a configuration:

• Normal

  The configuration, including all of the databases configured in it, is operating as specified by the user without any warnings or errors.

• Warning

  One or more of the databases in the configuration is not operating as specified by the user. To obtain more information, use the CLI SHOW command or the Data Guard GUI display to locate each database and examine its error status to reveal the source of the problem.

• Error

  One or more of the databases in the configuration failed or may no longer be operating as specified by the user. To obtain more information, use the CLI SHOW command or the Data Guard GUI display to locate each database and examine its error status to reveal the source of the problem.

• Unknown/Disabled

  Broker management of the configuration is disabled. The Data Guard monitor is not monitoring the status of the databases in the configuration.