2
Managing Broker Configurations

This chapter contains the following sections:

• Section 2.1, "Configuration Support"
• Section 2.2, "Starting the Data Guard Broker"
• Section 2.3, "Management Cycle of a Broker Configuration"
• Section 2.4, "Enable and Disable Operations"
• Section 2.5, "States"
• Section 2.6, "State Transitions"
• Section 2.7, "Status"
• Section 2.8, "Properties"
• Section 2.9, "Protection Modes"

2.1 Configuration Support

The broker allows you to logically define a Data Guard configuration, consisting of a primary site and physical and logical standby sites. With the broker, you define a broker configuration that is a logical grouping of the sites and database resources, including log transport services and log apply services. The broker controls the logical objects in the configuration, modifies their behavior at runtime, dynamically sets the protection mode across the configuration, monitors the overall health of the configuration, and reports any health and other operational characteristics up through the Enterprise Management notification mechanisms and the Data Guard Manager general property pages if you are using Data Guard Manager, or through SHOW commands if you are using the CLI.

The broker supports one or more Data Guard configurations, with each configuration consisting of a site containing a primary database, and up to nine standby databases on sites that are either local to, or, remote from, the primary site. This is the maximum number of standby databases allowed by the underlying Data Guard and standby database technology.

A supported Data Guard configuration contains the following components:

• A primary database, located on a primary site
• From one to nine physical or logical standby databases, each of which is located on a standby site.
• Physical systems that host the primary and standby database instances
• Oracle Net network configuration that defines a connection between the primary and standby database instances

  Note: For databases configured in a shared server configuration, the connect string or Oracle Net service name used for broker communications must specify a dedicated server process instead of the dispatcher process. This is because, during some database operations, the broker must perform database administration tasks that cannot be done over shared server connections. In addition, connections between the CLI or Data Guard Manager and the database instance must also use a dedicated server link.

• Archived redo log destination parameters and configuration properties
• Log transport services that archive the redo logs from the primary database to the standby databases
• Log apply services that apply the archived redo logs to the standby databases as they arrive from the primary database

The standby database is updated by archived redo logs that are shipped automatically from the primary database by means of log transport services. The archived redo logs contain a record of all of the database changes except for unrecoverable or unlogged changes. On the standby site, log apply services apply the archived redo logs 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 components as a unified group of objects that you can manage and monitor as a single unit. Thus, when you enter a command having a scope that affects multiple objects, the DMON process:

• Carries out your request on the primary site object
• Coordinates with the DMON process on the other sites as required for your request
• Updates its local configuration file
• Communicates with the DMON process on the other sites to update their copies of the configuration file

The broker carries out your requests against a hierarchy of objects that are dependent upon one another. For example, a database resource object is dependent upon the site object in which the resource resides, and the site object is dependent upon the configuration object. Thus, a site is the parent for a database resource and the configuration is the parent for a site.

This is important because when you request to take an object offline, its dependents will also be taken offline in dependency order. For example, if a site is put in an offline state, the database that is dependent on the site will also be put in an offline state first. Similarly, if the configuration is offline, all of the sites and resources in the configuration are also offline because all are dependent on the configuration. If you later request the configuration object to go online, the broker brings each site object to an online state, followed by bringing each resource object for the sites online as well. It is in this manner that the DMON process allows you to create, monitor, and control all aspects of the configuration together as a unit.

Figure 2-1 shows a two-site broker configuration with the Data Guard monitor (DMON) process running on each site. The standby site must contain a physical standby database to use the standby redo logs. Logical standby databases do not support standby redo logs.

Figure 2-1 Oracle9i Data Guard Broker Configuration

Text description of the illustration odg_arch.gif

Table 2-1 provides a comparison of configuration management with and without the broker.

Table 2-1  Configuration Management With and Without the Broker

	Configuration Management
	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 Data Guard Manager wizards that automate and simplify the complex steps required to create a configuration with a single Oracle database instance on each site, including creating the standby control file, datafiles, and initialization parameter file.	You must manually: Copy the database files to the standby site. Create a control file on the standby site. Create initialization parameter files on the standby site.
Configuration and Management	Allows you to configure and manage multiple sites from a single location and automatically unifies all of the sites and resources in the broker configuration.	You must manually: Set up log transport services and log apply services on each site in the configuration. Manage the primary database and standby databases individually.
Control	Automatically opens the primary database, mounts physical standby databases and opens logical standby databases, and starts log transport services and log apply services. Automates switchover and failover operations. Provides mouse-driven database state changes and a unified presentation of configuration and database status. Provides mouse-driven property changes.	You must: Use SQL*Plus commands to manage database states. Coordinate sequences of multiple commands across multiple sites to execute operations.
Monitoring	Provides continuous monitoring of the configuration health, database health, and other runtime parameters. Provides a unified updated status through the database alert log and Data Guard configuration log. Provides an integrated tie-in to Oracle Enterprise Manager events.	You must: Monitor the status and runtime parameters using fixed views on each site--there is no unified view of status for all of the sites and resources in the configuration. Provide a custom method for monitoring events.

2.2 Starting the Data Guard Broker

After installing the Oracle9i release 2 database server on each site in the configuration, the DG_BROKER_START initialization parameter must be set to TRUE on each site to start the Data Guard monitor (DMON) processes.

By default, the DG_BROKER_START initialization parameter is set to FALSE. However, its runtime value is determined as follows:

• If you are using Data Guard Manager, it automatically sets the DG_BROKER_START initialization parameter to TRUE.
• 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 either before or after you start the Oracle instance:
  • Before starting the Oracle instance, add the DG_BROKER_START=TRUE record to the initialization parameter file.
  • After starting the Oracle instance, set DG_BROKER_START=TRUE using the SQL ALTER SYSTEM 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 Data Guard Manager or the CLI, Oracle Corporation recommends that you set the DG_BROKER_START=TRUE initialization parameter in the SPFILE on each primary and standby site. Doing so ensures that the DMON processes will start automatically the next time you start the database.

2.3 Management Cycle of a Broker Configuration

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

Figure 2-2 Life Cycle of a Broker Configuration

Text description of the illustration lifecycl.gif

Create the Broker Configuration

When using Data Guard Manager, the Create Configuration Wizard can either add an existing standby database into the configuration or create a new 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 when you no longer want to manage it with the broker. When you disable a configuration, broker management of all of its site objects and resource objects is also disabled.

A broker configuration, when first created using Data Guard Manager is automatically enabled as soon as the Create Configuration wizard completes.

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

You can enable:

• The entire configuration, including all of its sites and resources
• A standby site, including the standby database resource
• A database resource

The ability to enable and disable an entire configuration can be useful if you choose to use Data Guard Manager only to create a Data Guard configuration and then manage it using other interfaces (for example, using command-line interfaces and SQL statements). Also, you can easily disable a site (or a database resource on the site) if a problem has occurred and the site 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 State Changes or Role Changes to the Broker Configuration, As Needed

The Data Guard monitor transitions the configuration, sites, and database resources into an online state, by default, the first time that you enable the configuration.

At any time, you can issue a single command through Data Guard Manager or the CLI to change the state of the entire configuration, or of a single site or database resource. For example, you could bring the primary database resource into an online, paused state to temporarily stop archiving logs to the standby database. Then, you simply issue another command to return the database resource to a full online state (that is, online and archiving logs to the standby databases).

Similarly, at any time, you can issue a single command to change the roles of the objects 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 and easily switch over production processing from the current primary database to a standby database, and then back again.

Update Database Properties, As Needed

The Data Guard monitor allows you to set database properties that map directly to several of the database initialization parameters. You can change these properties to dynamically control such things as log archival, file management, log switching, and to support the overall configuration protection mode. The broker records the changes in the Data Guard configuration file and also propagates the changes to the related initialization parameters in the server parameter files (SPFILE) to each site in the Data Guard configuration.

Monitor and Tune the Configuration

You can check the health of the configuration, display and update the properties of the database resources, set Oracle Enterprise Manager events, and change the state to online or offline, as required. Moreover, the broker allows you to tune the configuration to balance data protection levels and application performance impact; you can configure the protection mode to maximize data protection, maximize availability, or maximize performance.

Data Guard Manager also provides a dynamic performance page that automatically and dynamically refreshes chart data and status at specified intervals. (The collection interval--the rate at which data is sampled from the primary--defaults to 60 seconds. You can change the collection interval.) The different performance charts include bar, line, grid, and pie show a graphical summary of how far behind and how much redo data is being generated and applied. You can also set up multiple test applications to quickly modify a table under a test schema to generate redo data and test the configuration setup.

.

2.4 Enable and Disable Operations

A key concept of management with the broker is the notion of enabling and disabling objects in a broker configuration. The enable and disable operations are relevant only to the (logical) objects in a broker configuration; you cannot perform these broker operations on the physical components of a Data Guard configuration. This is because when you enable or disable an object 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 configuration, site, or database resource object.
• Manage the configuration information in the Data Guard configuration file on each site.

However, disabling a broker configuration does not affect 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 an object does not remove or delete it from the Data Guard configuration file. You can re-enable your ability to manage with the broker using the CLI ENABLE CONFIGURATION, ENABLE SITE, or ENABLE RESOURCE commands, or the Enable and Disable options in Data Guard Manager.

Thus, it may be advantageous to disable a configuration temporarily and 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 because the changes are not applied to the running database until you re-enable 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.5 States

While enabled, a broker configuration, site, or database resource can be in one of two states: offline or online. When disabled, the states of the objects in the configuration are left as is. The first time that the broker configuration is enabled^{Foot 1}, each object is automatically entered into the following default runtime state known as a default state:

• The broker configuration is in an online state.
• The primary and standby sites are in online states.
• The primary database resource is in an online state, started and opened in read/write mode, but the replicated tables in the database are open read-only to queries.
• The physical standby database resource is in an online state, started and mounted. The logical standby database is opened in read/write mode.
• Log transport services and log apply services are online.

When the broker configuration is enabled for the first time, the configuration and all of the sites and database resources are also brought online automatically. In addition, note that the database resources' online states are further qualified by substates (for example, the primary database is opened in read/write mode with log transport services started).

The database resource substates are related to the role (primary or standby) in which the site is currently running. By default, the first time the configuration and all of the objects are enabled and brought online, the database resources are put into the following substates:

• For a primary database, the default is to start the database instance and open it in read/write mode with log transport services started (archiving redo logs to the standby database). This is referred to as the READ-WRITE-XPTON substate in the CLI. In Data Guard Manager, you can put the database in this state by selecting Online on the Set State dialog for the primary database resource.
• For a physical standby database, the database instance is started and mounted, while a logical standby database is open in read/write mode. Log apply services apply archived redo logs to the standby database. This is referred to as the PHYSICAL-APPLY-ON (for physical standby databases) or LOGICAL-APPLY-ON (for logical standby databases) substate in the CLI. In Data Guard Manager, you can put the database in this state by selecting Online on the Set State dialog for the standby database.

  .

  See Also: Chapter 4 for complete information about the online substates for the primary and standby database resources

Running the broker configuration using the initial default online states described in this section will be fine, most of the time. However, there may be times when you want to change the state of one or more objects in the broker configuration. Section 2.6 describes state transitions in more detail.

2.6 State Transitions

When enabled, you can transition any object in the broker configuration into another valid state (or substate if it is a database resource), provided such a transition is allowed for the object. When you change the state of an object, you are effectively changing its current runtime state, which is sometimes referred to as its intended state.

State transitions occur when:

• You explicitly cause a state change (by selecting the online or offline states in Data Guard Manager or by using the CLI ALTER command) to bring the configuration, sites, or resources online or take them offline as necessary.
• You enable the configuration, sites, or resources (using the Data Guard Manager Enable option or using the CLI ENABLE command).
• A failover or a switchover operation occurs.

When a state change occurs, it only affects the current (intended) runtime state for the object; the default state is not altered. (Section 2.5 described the default state, which is the initial runtime state of an object when the broker configuration is first enabled.)

State transitions may result in a state change to multiple objects. You can request a state transition that affects only one resource, or you can change the state of the broker configuration and affect all of the sites and resources in the configuration. For example, when you change the broker configuration into an offline state, the configuration and all of its dependent sites and resources are also taken offline. The databases in the configuration will be shut down and started (nomount), log transport services will stop sending archived redo logs, and log apply services will stop applying redo logs to the standby database.

Although Data Guard Manager does not differentiate between states and substates, or default and intended states, the CLI does. You can see information about the default and intended (current runtime) states by issuing the CLI SHOW commands or viewing the General property page in Data Guard Manager. In Example 2-1, the SHOW RESOURCE VERBOSE command displays the default and intended states and other information for the Sales_db database resource on site Boston. Notice that although the configuration was initially enabled in the READ-WRITE-XPTON (default state), its current runtime (intended) state is READ-WRITE with log transport services stopped.

Example 2-1 Showing Default and Intended States with the CLI

DGMGRL> SHOW RESOURCE VERBOSE Sales_db ON SITE Boston;

The CLI returns the following information:

Resource
  Name:             Sales_db
  Manager Type:     internal
   Standby Type:     PHYSICAL
Online States:
  ONLINE
  PHYSICAL-APPLY-READY
  PHYSICAL-APPLY-ON
  READ-ONLY
  LOGICAL-APPLY-READY
  LOGICAL-APPLY-ON
  READ-WRITE
  READ-WRITE-XPTON
Properties:
  INTENDED_STATE                  = 'READ-WRITE-XPTON'
  ENABLED                         = 'yes'
  IGNORE_STATUS                   = 'no'
  LogXptMode                      = 'ARCH'
  Dependency                      = ''
  Alternate                       = ''
  DelayMins                       = '0'
  Binding                         = 'OPTIONAL'
  MaxFailure                      = '0'
  ReopenSecs                      = '300'
  AsyncBlocks                     = '2048'
  LogShipping                     = 'ON'
  ApplyNext                       = '0'
  ApplyNoDelay                    = 'NO'
  ApplyParallel                   = '1'
  StandbyArchiveDest              = '/oracle/dbs/a1'
  LogArchiveTrace                 = '4095'
  StandbyFileManagement           = 'AUTO'
  ArchiveLagTarget                = '0'
  LogArchiveMaxProcesses          = '5'
  LogArchiveMinSucceedDest        = '1'
  DbFileNameConvert               = 'dbs/s2t, dbs/t'
  LogFileNameConvert              = 'dbs/s2t, dbs/t'
  LogArchiveFormat                = 'r_%t_%s.arc'
  InconsistentProperties          = '(monitor)'
  InconsistentLogXptProps         = '(monitor)'
  SendQEntries                    = '(monitor)'
  LogXptStatus                    = '(monitor)'
  SbyLogQueue                     = '(monitor)'
Properties for 'PRIMARY' state:
  DEFAULT_STATE    = 'READ-WRITE-XPTON'
  EXPLICIT_DISABLE = 'no'
  REQUIRED         = 'yes'
Properties for 'STANDBY' state:
  DEFAULT_STATE    = 'PHYSICAL-APPLY-ON'
  EXPLICIT_DISABLE = 'no'
  REQUIRED         = 'yes'
Current status for "db":
SUCCESS

2.7 Status

A configuration status reveals the overall health of the configuration. In essence, the status indicates whether or not the configuration, site, or resource is in its intended state.

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

• Normal

  The configuration, including all of the database resources configured in it, is operating as specified by the user. All of the resources that are in the ONLINE state are operating properly without any warnings or errors.

• Warning

  One or more of the database resources in the configuration has failed and may no longer be operating as specified by the user. To obtain more information, locate each resource and examine its error status to reveal the source of the problem.

• Error

  One or more of the database resources in the configuration is not operating as specified by the user. To obtain more information, locate each resource and examine its error status to reveal the source of the problem.

• Permanently Disabled

  A database resource object is permanently disabled and can no longer be managed through Data Guard Manager or the CLI.

• Unknown

  Broker management of the configuration is disabled and not currently under the control of Data Guard Manager. Therefore the status is unknown.

2.8 Properties

There are two types of properties that can be associated with broker objects--configurable and monitorable:

• Configurable property values can be viewed and dynamically updated.

  Configurable properties affect the operation or configuration of the broker object. You can change the value of these properties using the Data Guard CLI or Data Guard Manager. You can edit properties if the configuration and its sites and database resources are enabled, disabled, online, or offline. However, if the state is offline, the new property value will not take effect until you enable the configuration, site, or resource, as appropriate.

• Monitorable property values can only be viewed when the associated object is enabled.

  Monitorable properties allow you to view information related to objects, but you cannot change the value of these properties.

  See Also: Chapter 4 for complete information about database resource properties.

There are a number of properties that are common to most of the objects in a broker configuration. Table 2-2 lists common properties for each.

Table 2-2  Common Properties

Property	Common to . . . .
DEFAULT_STATE	Configurations, sites, and resources
ENABLED	Configurations, sites, and resources
EXPLICIT_DISABLE	Configurations, sites, and resources
HEALTH_CHECK_INTERVALFoot 1	Configuration (Default is 1 minute)
INTENDED_STATE	Configurations, sites, and resources
STATUS	Configurations, sites, and resources

1 The health check interval is configurable with Data Guard Manager.

For example, to see these properties, you might use any of the SHOW commands. The following example uses the SHOW SITE VERBOSE command to display information about the Boston site.

DGMGRL> SHOW SITE VERBOSE 'Boston';
Site
  Name:                          'Boston'
  Hostname:                      'system1'
  Instance name:                 'bstn'
  Service Name:                  'primary'
  Standby Type:                  'physical'
  Number Built-in Processes:     '2'
  Enabled:                       'yes'
  Required:                      'yes'
  Default state:                 'PRIMARY'
  Intended state:                'PRIMARY'
  Number of resources:  1
  Resources:
    Name: Sales_db (default) (verbose name='Sales_db')

2.9 Protection Modes

The broker can simplify the process of setting up your configuration for any of the different grades of data protection: maximum protection, maximum availability, maximum performance.

This section contains the following topics to help you configure the proper protection for your configuration:

• Section 2.9.1, "Setting the Protection Mode for Your Configuration"
• Section 2.9.2, "How Broker Operations Affect Protection Modes"

2.9.1 Setting the Protection Mode for Your Configuration

To set the protection mode, perform the following steps:

Step 1 Determine which data protection mode you want to use.

Each data protection mode provides a different balance of data protection, data availability, and database performance. To select the data protection mode that meets the needs of your business, carefully consider your data protection requirements and the performance expectations of your users.

Maximum Protection

Maximum protection mode offers the highest level of data protection, but it may decrease the performance and availability of the primary database. The maximum protection mode:

• Guarantees there will be no data loss between the primary site and at least one physical standby site in the configuration.
• Shuts down the primary database instance if the primary database is unable to write the redo records to at least one physical standby database that is configured to use the SYNC log transport mode.
• Requires at least one physical standby database must be configured to use the SYNC log transport mode.

  You must set the LogXptMode property to SYNC for the physical standby database. (See Section 4.3.2.4 for more information about setting the log transport mode.)

• Requires that standby redo logs must be configured for at least one physical standby database.
• Does not support logical standby databases.

Maximum Availability

Maximum availability mode offers the next highest level of data protection possible while maximizing the availability of the primary database. The performance impact on the primary database is less than that of the maximum protection mode. The maximum availability mode:

• A transaction does not commit until all data needed to recover it has been written to at least one (physical or logical) standby database that is configured to use the SYNC log transport mode. This mode guarantees zero data loss unless a primary database failure occurs before recovery from a network outage.
• Makes a best effort to write the redo records to at least one physical or logical standby database that is configured to use the SYNC log transport mode.

  Unlike maximum protection mode, the maximum availability mode does not shut down the primary database instance if the primary database is unable to write the redo records to at least one physical standby database that is configured to use the SYNC log transport mode. Instead, the protection mode is downgraded temporarily to maximum performance mode until the fault has been corrected and the standby database has caught up with the primary database.

• Requires that at least one standby database must be configured to use the SYNC log transport mode.

  You must set the LogXptMode property to SYNC for the standby database. (See Section 4.3.2.4 for more information about setting the log transport mode.)

• Requires that standby redo logs must be configured for physical standby databases.
• Can be used with physical and logical standby databases.

Maximum Performance

Maximum performance mode is the default protection mode. This mode provides the highest level of data protection possible without affecting the performance of the primary database. This protection mode:

• Allows a transaction to commit on the primary database before the data needed to recover it has been written to a (physical or logical) standby database. Therefore, some transactions may be lost if the primary database fails and you are unable to recover the redo records from the primary database.
• You should set the LogXptMode property to ASYNC or ARCH for the standby database. (See Section 4.3.2.4 for more information about setting the log transport mode.)

  See Also: Oracle9i Data Guard Concepts and Administration for a complete discussion about the advantages and disadvantages of each data protection mode and for information about configuring log transport services for each protection mode

Step 2 Set up standby redo logs, if needed.

If the data protection mode that you need requires that one or more physical standby databases use the SYNC or ASYNC log transport mode, you may need to add standby redo logs to those physical standby sites. Logical standby database do not support standby redo logs. (Note that the maximum performance mode does not require standby redo logs.)

Data Guard Manager provides the Standby Redo Log Assistant that automatically sets up standby redo logs on one or more physical standby databases in your configuration, and on the primary database in preparation for a switchover operation.

Step 3 Set the LogXptMode property, if necessary.

If the data protection mode requires that you change the log transport mode used by any of the standby databases, change the setting of the LogXptMode database property appropriately on each standby database. See Section 4.3.2.4 for more information about setting the log transport mode.

Step 4 Set the protection mode.

Select the Protection Mode using the CLI or Data Guard Manager:

With Data Guard Manager:

1. Select the configuration in the navigator tree.
2. Click the Data Protection tab.
3. Select the Protection Mode you chose in step 1 and click Apply.

   After you change the protection mode, the primary site and database will automatically restart.

With the CLI:

1. If you plan to set the protection mode to either the MAXPROTECTION or MAXAVAILABILITY protection mode, ensure that standby redo logs are configured on the physical standby site.
2. Use the ALTER RESOURCE (property) command on the standby database to set the log transport mode that corresponds to the protection mode you plan to set. For example, if you plan to set the overall Data Guard configuration to the MAXAVAILABILITY mode, you must use the ALTER RESOURCE command to set the SYNC mode for log transport services. For example:

   SQL> ALTER RESOURCE 'Sales_db' ON SITE 'Boston' SET PROPERTY 
   LogXptMode=SYNC;
   
   

3. Use the ALTER CONFIGURATION SET PROTECTION MODE AS protection-mode; command on the standby database to set the overall configuration protection mode. For example:

   SQL> ALTER CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
   
   

After you change the protection mode, the primary site and database will automatically restart.

2.9.2 How Broker Operations Affect Protection Modes

This section describes how operations such as switchover, failover, disabling, or enabling the Data Guard configuration can have an affect on the configuration's protection mode and the log transport services. This section contains the following sections:

• Upgrading or Downgrading the Current Protection Mode
• Switchover Operations
• Failover Operations
• Disable and Enable Operations
• Requirements When Removing an Object in the Configuration
• Requirements On Other Operations

2.9.2.1 Upgrading or Downgrading the Current Protection Mode

When you change the current Data Guard protection mode to another protection mode (for example, you might want to upgrade from the maximum performance mode to the maximum availability mode), you must shut down and restart the primary database. Follow these recommendations when upgrading or downgrading the Data Guard protection mode:

• When upgrading the protection mode, upgrade the log transport mode before you upgrade the overall protection mode. At the time when you change the protection mode or reset the log transport mode of a standby site, the broker verifies that there is at least one standby site in the configuration that can support the requested grade of protection. If not, then the broker does not change the protection mode and returns an error.
• When downgrading the protection mode, downgrade the protection mode first and then change the log transport mode (if necessary). The broker will not downgrade the log transport mode if doing so invalidates the current overall protection mode.

For example, if you reset the protection mode from the maximum performance mode to the maximum protection mode, the broker ensures that there is at least one physical standby database using standby redo logs, and whose log transport mode is set to SYNC. If there are no physical standby databases in the configuration that meet these requirements, the request to upgrade the protection mode is rejected with an error.

2.9.2.2 Switchover Operations

A switchover operation does not change the overall Data Guard protection mode. The protection mode remains the same as it was at prior to the switchover operation. However, before you start the switchover operation, you should verify that there will be at least one standby site in the configuration whose log transport mode can support the grade of protection after the switchover occurs.

Before you invoke a switchover operation, if necessary, you can pre-set the log transport mode on the current primary site to the SYNC, ASYNC, or ARCH mode that is required to support the Data Guard protection mode. Then, when the switchover operation begins, the broker verifies the log transport mode setting on each standby site including the log transport mode value that you preset for the current primary site. If the verification is successful, the switchover operation continues; otherwise the switchover operation fails, and the database roles and the Data Guard configuration files remain unchanged.

2.9.2.3 Failover Operations

After a failover, the Data Guard protection mode is always degraded to maximum performance mode. This is because there may not be a standby site in the configuration whose log transport mode can support a higher grade of protection (maximum protection and maximum availability mode) after the failover occurs. You can upgrade the protection mode later, if necessary. During a failover operation, the log transport modes of the bystanders remain the same.

2.9.2.4 Disable and Enable Operations

When you disable a standby site or a standby database resource, the broker checks to see if the overall protection mode can still be satisfied by any of the remaining standby databases. If not, the broker rejects the disable operation. Otherwise, the broker allows the disable operation to proceed.

After a standby database resource object is successfully disabled, you can change the log transport mode of the resource and the broker will record the change only in the Data Guard configuration file. Thus, the change will not affect the overall protection mode because it is guaranteed that at least one of the enabled standby databases already satisfies the overall protection mode requirement. Once the database resource object is re-enabled, the broker will set the log transport mode of the database according to the value in the Data Guard configuration file.

When you disable the entire configuration, the broker always allows the operation to complete. This is because you may want to use the broker only to set up a Data Guard configuration, and then disable it from the broker's control and use other interfaces (for example, using command-line interfaces and SQL statements) for management.

If the entire configuration is disabled, you can change any broker settings, including the log transport modes of the standby databases and the protection mode of the configuration. The broker saves the changes in the Data Guard configuration file, but the changes will not be made to the database itself.

When enabling the entire configuration, the broker first checks to see if the protection mode will be satisfied by the log transport modes of the standby databases that will be enabled. If not, the enable operation fails and the configuration remains disabled. Otherwise, the enable operation successfully enables the configuration and the broker enables the database using the settings saved in the Data Guard configuration file.

2.9.2.5 Requirements When Removing an Object in the Configuration

When removing a standby database resource object or a standby site, the broker checks to see if the protection mode is still satisfied. If you want to remove the entire configuration, the broker always allows the operation.

2.9.2.6 Requirements On Other Operations

Some operations that take place in a broker configuration, especially operations related to log transport services, can affect the overall protection mode. These operations include:

• Setting the standby database into the offline state
• Stopping log transport services on the primary database
• Stopping log transport services on individual standby databases

Before any of these operations can proceed, the broker checks to see if the protection mode will be supported by the log transport mode settings on the standby sites after the operation completes. If not, the broker quits the operation and returns an error.

---

¹ Configurations are enabled automatically when created with Create Configuration wizard in Data Guard Manager, but you must enable a configuration that you create with the CLI.