3 Managing Databases

3.2.1 Database State Transitions

Figure 3-1 graphically shows the transition of the states that were described in Table 3-1. The double arrows indicate that you can transition from one state to any other state.

Figure 3-1 Database State Transition Diagrams

Description of the illustration transitn.gif

With the CLI, you can use the EDIT DATABASE command to explicitly change the state of a database. For example, the EDIT DATABASE command in the following example changes the state of the North_Sales database to LOG-TRANSPORT-OFF.

DGMGRL> EDIT DATABASE 'North_Sales' SET STATE='LOG-TRANSPORT-OFF';
Succeeded.

The following sections detail the transition of the states in which the primary and standby databases can be.

For the primary database, when transitioning from any state to the ONLINE state, the broker sets up log transport services to all broker-managed standby databases using the log transport-related properties of the standby databases (see Section 3.4 for the list of all log transport-related properties). Log transport services setup is done by setting the LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_DEST_STATE_n initialization parameters on the primary database, and the LOG_ARCHIVE_CONFIG initialization parameter on all databases (primary or standby). If necessary, the broker also sets up the data protection mode of the database to match the protection mode recorded in the broker configuration file, and opens the database for read and write access. Finally, the broker switches a log for each thread to initiate log transport services.

When transitioning from any state to the LOG-TRANSPORT-OFF state, the broker turns off log transport services to all broker-managed standby databases by resetting the LOG_ARCHIVE_DEST_STATE_n initialization parameter. Transmission of redo data to all broker-managed standby databases is stopped. Log files continue to be archived at the primary database.

When transitioning to the OFFLINE state, the broker shuts down the primary database. The primary database is not available, and the broker is no longer managing the configuration. To transition out of the OFFLINE state, you need to start up the database in the mounted mode. The broker will restore the primary database to the ONLINE state.

If the primary database is a RAC database, the broker configures log transport services on all primary instances with the exact same settings.

For a physical standby database, when transitioning from any state to the ONLINE state, the broker starts log apply services with options specified by the log apply-related properties (see Section 3.5 for the property list). If the standby database is a RAC database, the broker starts log apply services on one standby instance, called the apply instance.

When transitioning to the LOG-APPLY-OFF state, the broker stops log apply services if the database is in the ONLINE state, or closes the database if the database is in the READ-ONLY state.

When transitioning to the READ-ONLY state, the broker stops log apply services if it is running, and opens the database for read-only access. If the standby is a RAC database, all currently active instances will be open READ-ONLY.

When transitioning to the OFFLINE state, the broker shuts down the standby database. The standby database is not available, the broker stops log transport services to this database, and the broker stops managing this database. To transition out of the OFFLINE state, you need to start up the database in the mounted mode. The broker restores the standby database to the state it was in before the OFFLINE state. In order for the broker to once again manage a standby database that is shutdown, the primary database must be running and the broker must be managing the Data Guard configuration when the standby database is restarted.

For a logical standby database, when transitioning from any state to the ONLINE state, the broker opens the database if it is not yet opened, turns on the guard, and starts log apply services with options specified by the log apply-related properties. If the logical standby database is a RAC database, the broker starts log apply services on one standby instance, the apply instance.

When transitioning to the LOG-APPLY-OFF state, the broker stops log apply services.

When transitioning to the OFFLINE state, the broker shuts down the logical standby database. The logical standby database is not available, the broker stops log transport services to this database, and the broker stops managing this database. To transition out of the OFFLINE state, you need to start up the database in the mounted mode. The broker restores the standby database to the state it was in before the OFFLINE state. In order for the broker to once again manage a standby database that is shutdown, the primary database must be running and the broker must be managing the Data Guard configuration when the standby database is restarted.

3.3.1 Monitorable (Read-Only) Properties

Monitorable properties allow you to view information related to the database, but you cannot change the values of these properties. These properties can be very helpful when you are trying to diagnose problems in the broker configuration. For example, view the InconsistentLogXptProps property to determine where there is a discrepancy for log transport services properties whose values are inconsistent between the broker configuration file and the actual value currently used by the database.

You can view all of the monitorable properties using the CLI SHOW command. For example:

DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentLogXptProps';
INCONSISTENT LOG TRANSPORT PROPERTIES

INSTANCE_NAME    STANDBY_NAME    PROPERTY_NAME    MEMORY_VALUE    BROKER_VALUE
sales1          DR_Sales       DelayMins        30               -1

The Data Guard GUI displays the information obtained from these properties on the Edit Properties page in the GUI.

3.3.2 Configurable (Changeable) Database Properties

Configurable properties affect the operation or configuration of the database. When you use the CLI or the Data Guard GUI to create a primary database object and import existing standby databases into a new broker configuration, the property values are initially imported from the database settings.

You can update many property values when the database is either disabled or enabled. When a new database is added into the configuration, the broker connects to the database and imports initial values for the database properties from the current database settings. For example:

DGMGRL> SHOW DATABASE 'North_Sales' 'ArchiveLagTarget';
  ArchiveLagTarget = '0'

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'ArchiveLagTarget'=1200;
  Property "ArchiveLagTarget" updated.

DGMGRL> SHOW DATABASE 'North_Sales' 'ArchiveLagTarget';
  ArchiveLagTarget = '1200'

When the configuration is enabled, the broker keeps the database property values in the broker configuration file consistent with the values being used in the database. For those that are related to initialization parameter properties, the broker maintains the consistency among the value in the broker configuration file, the current database value, and the initialization parameter value in the server parameter file, as follows:

• For dynamic parameters, the broker keeps the value of the database parameter consistent in the system global area (SGA) for the instance, in the broker configuration file, and in the server parameter file.

• For static parameters and properties, the database parameter value in the system global area (SGA) for the instances may temporarily differ from what is in the broker configuration file and in the server parameter file. Typically, the database value becomes the same as the server parameter file value and the broker configuration file value the next time the database instance is stopped and restarted.

Even when the configuration is disabled, you can update database property values through the broker. The broker retains the property settings (without validating the values) and updates the database initialization parameters in the server parameter file and the in-memory settings the next time you enable the broker configuration.

3.4.1 Managing Log Transport Services for Data Protection Modes

Section 3.6 describes how the broker handles data protection modes. As a part of the overall configuration protection mode, you must ensure that log transport services are also properly set up for the data protection mode that you choose.

You use the LogXptMode property to set the SYNC, ASYNC, or ARCH mode for log transport services. See Table 3-2 for additional information about protection modes and log transport modes.

The values for the LogXptMode property are described in the following list:

Configures log transport services for this standby database using the LGWR, SYNC, and AFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. This mode, along with standby redo log files, is required for the maximum protection or maximum availability protection modes. This log transport mode enables the highest grade of data protection to the primary database, but also incurs the highest performance impact.

Configures log transport services for this standby database using the LGWR, ASYNC, and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. This mode, along with standby redo log files, enables a moderate grade of protection to the primary database, and lower performance impact.

Configures log transport services for this standby database using the ARCH attribute of the LOG_ARCHIVE_DEST_n initialization parameter. Standby redo log files are not required. This mode enables the lowest grade of protection to the primary database, and the lowest performance impact.

3.4.2 Turning On and Off Log Transport Services

Turn log transport services on and off by setting the state of the primary database. Setting the primary database state to ONLINE turns on log transport services to the standby databases, and setting the primary database state to LOG-TRANSPORT-OFF turns off log transport services to all the standby database.

Turn log transport services on and off to an individual standby database using the LogShipping property on the standby database. The LogShipping property accepts values ON and OFF. If you set the LogShipping property to OFF for a standby database, log transport services to this standby database are turned off, while log transport services to other databases are not affected. You can set LogShipping to ON to turn back on log transport services to the standby database.

The relationship between setting the primary database state and setting the LogShipping property is as follows:

• If the primary database state is set to LOG-TRANSPORT-OFF, log transport services to all the standby databases are turned off regardless of the individual LogShipping property values of the individual standby databases.

• If the primary database state is set to ONLINE, log transport services to each standby database are determined by the LogShipping property of that database.

Example 3-1 and Example 3-2 show how to turn off log transport services in two different scenarios.

DGMGRL> EDIT DATABASE 'North_Sales' SET STATE="LOG-TRANSPORT-OFF";
Succeeded.
DGMGRL> SHOW DATABASE 'North_Sales';

Database
  Name:            North_Sales
  Role:            PRIMARY
  Enabled:         YES
  Intended State:  LOG-TRANSPORT-OFF
  Instance(s):
    dgr

Current status for "North_Sales":
SUCCESS

DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'LogShipping'='OFF';
Property "LogShipping" updated.

DGMGRL> SHOW DATABASE 'DR_Sales' 'LogShipping';
  LogShipping = 'OFF'

3.4.3 Managing Standby Locations to Archive the Online Redo Log Files From the Primary Database

You can set up locations on the standby database to store the archived redo log files to be used by log apply services on the standby database. This is done by setting the StandbyArchiveLocation and AlternateLocation properties on the standby database.

StandbyArchiveLocation specifies a standby location where the archived redo log files will be stored. The broker ensures that the archived redo log files are stored in the same specified location whether or not the standby database has standby redo log files. The broker only manages the location on the standby database to store archived redo log files received from the primary database. For archived redo log files generated locally when the database is either the primary database or a logical standby database, you need to set up local destinations directly through the LOG_ARCHIVE_DEST_n initialization parameter. The broker allows the value of StandbyArchiveLocation to be the same as the location you set up for locally generated logs, in which case the broker sets up the VALID_FOR attribute of the destination appropriately so that it can be used for both the archived redo log files received from the primary database and archived redo log files generated locally.

The broker does not manage the local destinations for locally-generated archived redo log files, but the broker does ensure that the location specified by StandbyArchiveLocation is not used to store locally-generated archived redo log files. (This is done by setting the VALID_FOR attribute of the destination to be (STANDBY_ROLE,STANDBY_LOGFILE).)

You can also set up an alternate location to store archived redo log files on the standby using the AlternateLocation property on the standby database. This is useful for avoiding disk capacity problems or disk errors when archiving the online redo log files on the standby database. AlternateLocation specifies a standby location where the archived redo log files will be stored if the location specified by the StandbyArchiveLocation fails. The broker sets up the alternate location properly using the ALTERNATE attribute of the LOG_ARCHIVE_DEST_n initialization parameter.

3.4.4 Setting a Dependent Standby Database

You can use the Dependency property to set up a standby database whose incoming archived redo log files depends on another standby database or on the primary database. This is useful when two standby databases are on the same system (for example, one physical and one logical standby database). This is also useful if the standby database is on the same system as the primary database, in which case one standby database can share the log files with the other database on the same system, and there is no need to archive the log files separately to this standby database.

If you want standby database B to depend on another database A (either a standby database or the primary database), you can set the Dependency property of standby database B to be the database object name (same as its DB_UNIQUE_NAME initialization parameter) of database A. The broker sets up log transport services properly through the DEPENDENCY attribute of the LOG_ARCHIVE_DEST_n initialization parameter.

3.4.5 Other Log Transport Settings

You can use properties AsyncBlocks, Binding, MaxFailure, NetTimeout, and ReopenSecs to tune the performance of log transport services and to set up log transport services failure policies. These properties correspond to the
LOG_ARCHIVE_DEST_n initialization parameter attributes. See Chapter 8 for the detailed explanations of these properties.

When creating a new standby database, the broker sets these properties with the default values. When importing an existing standby database, the broker imports existing settings corresponding to these properties if the broker finds a match between the service string of a current destination and the initial connect identifier supplied by you when you add the standby database using the command-line interface DGMGRL.

For most cases, the default values or the imported values should be sufficient for normal operations. If for some reason you need to change these property values, you can use the Data Guard broker command-line interface (DGMGRL) to set up these properties. The Data Guard GUI does not provide an interface for these properties.

3.4.6 Managing Connections to the Standby Databases for Log Transport Services

The broker automatically manages the Oracle Net connections used by log transport services to the standby databases. Log transport services managed by the broker do not rely on any Oracle Net Services naming method.

The broker constructs the connect descriptor to the standby apply instance and uses it as the value of the SERVICE attribute of the LOG_ARCHIVE_DEST_n initialization parameter. The broker uses the following information to construct the connect descriptor:

• The LOCAL_LISTENER initialization parameter of the standby apply instance

• The DB_UNIQUE_NAME initialization parameter of the standby database

• The INSTANCE_NAME parameter of the standby apply instance from V$INSTANCE

On the standby database, the broker registers a special service name <DB_UNIQUE_NAME>_XPT with the standby listeners for log transport services. On the primary database, the broker extracts the listener address from the LOCAL_LISTENER initialization parameter, and uses the service name <DB_UNIQUE_NAME>_XPT and the value of INSTANCE_NAME to construct the connect descriptor so that log transport services transmit archived redo log files to the standby apply instance.

3.4.7 Log Transport Services in a RAC Database Environment

If your database is a RAC database, the broker sets up log transport services in the following manner:

• If the primary database is a RAC database, the broker ensures that log transport services are identical on each of the primary database instances. Each instance has the same remote destinations, and for each remote destination, all instances are set up the same in terms of log transport mode, performance related settings, and so on. If an instance has different settings, the broker raises a health check warning on that particular instance.

• If the standby database is a RAC database, only the apply instance receives log files from the primary database. If the primary database is also a RAC database, all instances of the primary database transmit log files to the same apply instance on the standby database. If the apply service is moved to a different standby instance either by the user or by the broker, the broker resets log transport services on the primary database to transmit log files to the new apply instance. See Section 3.5 for more details.

Settings relative to log transport services are saved in the broker configuration file as properties. When you update a log transport-related property on a standby database, the corresponding change is also made automatically by the broker to the LOG_ARCHIVE_DEST_n initialization parameter on all of the primary database instances. If a new instance comes up on the primary database, the broker sets up log transport services for the new instance using the log transport-related properties of all the standby databases currently being managed by the broker. After the new instance is opened for activity, all archived redo log files generated on this instance will begin to transmit to the standby databases.

3.5.1 Managing Real-Time Apply

Data Guard log apply services can recover from standby redo log files in real time (as the log files are being filled), without requiring them to be archived at the standby database. You can turn the real-time apply feature of log apply services on and off using the RealTimeApply property. Setting RealTimeApply property to ON on the standby database turns on the feature and setting it to OFF turns off the feature.

The real-time apply feature requires the standby database to have standby redo log files configured. It applies the redo directly from standby redo log files as they are being received, instead of waiting for the log files to be archived and then applying them from the archived redo log files. This allows the standby database to be much more closely synchronized with the primary database. If the standby redo log files are not present on the standby database, the real-time apply feature is automatically turned off. When the standby database is in the real-time apply mode, any apply delay setting is automatically ignored.

Because real-time application of standby redo log files generally keeps the standby database caught up, this feature provides a number of benefits including:

• Quicker switchover and failover operations

• Having physical standby databases be instantly up-to-date after you change from Redo Apply to read-only operations

See Oracle Data Guard Concepts and Administration for details on the real-time apply feature.

3.5.2 Managing Delayed Apply

You can set up log apply services in a delayed apply mode. This allows the standby database to lag behind the primary database, and if a user error (for example, dropping a table) occurs during this window of time, the standby database will still contain the correct data that can be transmitted back to the primary database to repair the data.

You can set the delay time window using the DelayMins property which specifies, in number of minutes, how long log apply services on the standby database needs to wait before applying a log file received from the primary database. Note that only log apply services is delayed. Log transport services are not delayed and thus the primary database data is still well protected by the standby database.

If you want log apply services to ignore the delay and apply the archived redo log files immediately when they become available, you can use the ApplyNoDelay property. Setting ApplyNoDelay to YES overrides any delay setting in DelayMins, and log apply services immediately start applying all available log files. If you want to use the delay setting again, set the ApplyNoDelay property to NO. Note that it is not enough to set DelayMins to zero to force log apply services to start immediately applying log files. When you set DelayMins to zero, all the log files transmitted to the standby database (after the DelayMins is set) will be applied on the standby database in their turn without any additional delay, but for the log files already accumulated on the standby database while the delay setting is on, log apply services still respect the delay setting and wait until after the delay period to apply those log files.

For a physical standby database, while log apply services is in the delayed apply mode, if you want log apply services to apply a few log files immediately and then go back to the delayed mode again, you can use the ApplyNext property to specify the number of log files you want to apply immediately, temporarily overriding the delay. You cannot use the ApplyNext property on a logical standby database, because the SQL apply mechanism of a logical standby database is different. A logical standby database applies transaction by transaction rather than log file by log file as in the physical standby database.

3.5.3 Managing Parallel Apply in Physical Standby Databases

For a physical standby database, you can configure the number of parallel processes for log apply services to tune its performance by using the ApplyParallel property. The default value of ApplyParallel is AUTO, which means log apply services automatically choose the number of parallel processes based on the number of CPUs in the system. This should be sufficient in most cases. If you want to manually configure the parallel apply setting, you can set the ApplyParallel property either to NO, which means no parallel apply processes, or a positive integer to specify the number of parallel processes you want.

3.5.4 Allocating Resources to SQL Apply in Logical Standby Databases

You can control how much SGA memory is available for the SQL apply service on a logical standby database. This can be set using the LsbyMaxSga property.

To control the number of parallel query servers used by the SQL apply service, you can use the LsbyMaxServers property.

Users can control the trade off between SQL apply performance and transaction consistency level. For a higher transaction consistency level, the SQL apply service will have a higher performance impact. To control the transaction consistency level, use the LsbyTxnConsistency property.

Changing any property pertaining to the SQL apply service will result in restarting the SQL apply service if the current database state is ONLINE (for example, SQL apply is currently running). If the current database state is LOG-APPLY-OFF, the property changes will take effect the next time the database state is changed to ONLINE.

3.5.5 Managing SQL Apply Filtering in Logical Standby Databases

One of the benefits of a logical standby database is to allow control of what to apply and what not to apply. This is done by setting up SQL apply filters. The granularity of the filtering ranges from a specific transaction to database objects to a particular class of SQL statement on a particular schema.

To add a SQL apply filter in Data Guard broker, use the LsbyASkip* properties (for example, LsbyASkipTxnCfgPr or LsbyASkipCfgPr). To delete a previously added SQL apply filter, use the LsbyDSkip* properties (for example, LsbyDSkipTxnCfgPr or LsbyDSkipCfgPr).

Changing these properties results in restarting the SQL apply service if the current database state is ONLINE. If the current database state is LOG-APPLY-OFF, the property changes take effect the next time the database state is changed to ONLINE.

3.5.6 Managing SQL Apply Error Handling in Logical Standby Databases

You can fine-tune SQL apply to handle apply errors on a specified set of SQL statements on particular schemas. When such SQL apply errors are encountered, Data Guard can either skip the error to continue the SQL apply operation or call a specified stored procedure at the time when the error is encountered.

To add this error handling capability, use the LsbyASkipErrorCfgPr property. To delete a previously added error handling specification, use the LsbyDSkipErrorCfgPr property.

Changing these properties results in restarting the SQL apply service if the current database state is ONLINE. If the current database state is LOG-APPLY-OFF, the property changes take effect the next time the database state is changed to ONLINE.

3.5.7 Managing the DBA_LOGSTDBY_EVENTS Table in Logical Standby Databases

On a logical standby database, the DBA_LOGSTDBY_EVENTS table records important events that happen to SQL apply. Because every logical standby database might have a different interest in the set of events to be recorded in this table, Data Guard provides a means to control the event recording. From the Data Guard broker, you can use the LsbyRecord* properties (for example, LsbyRecordSkipDdl or LsbyRecordSkipErrors) to control recording of a particular set of events. The value of these properties are either TRUE or FALSE, indicating the turning on or off of the event recording.

Changing these properties results in restarting the SQL apply service if the current database state is ONLINE. If the current database state is LOG-APPLY-OFF, the property changes take effect the next time the database state is changed to ONLINE.

3.5.8 Log Apply Services in a RAC Database Environment

If a standby database is a RAC database, only one instance of the RAC database can have log apply services running at any time. This instance is called the apply instance. The broker manages the selection of the apply instance. If the apply instance fails, the broker automatically moves log apply services to a different instance; this is called apply instance failover. In order for the apply instance to continuously apply archived redo log files received from the primary database, the broker also manages log transport services such that the archived redo log files generated on the primary database are always transmitted to the apply instance.

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

This protection mode guarantees that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover each transaction must be written to both the local online redo log and to the standby redo log on at least one standby database before the transaction commits. To ensure that data loss cannot occur, the primary database shuts down if a fault prevents it from writing its redo stream to at least one remote standby redo log.

This protection mode provides the highest level of data protection that is possible without compromising the availability of the primary database. Like maximum protection mode, a transaction will not commit until the redo needed to recover that transaction is written to the local online redo log and to at least one remote standby redo log. Unlike maximum protection mode, the primary database does not shut down if a fault prevents it from writing its redo stream to a remote standby redo log. Instead, the primary database operates in maximum performance mode until the fault is corrected, and all gaps in redo log files are resolved. When all gaps are resolved, the primary database automatically resumes operating in maximum availability mode.

This mode guarantees that no data loss will occur if the primary database fails, but only if a second fault does not prevent a complete set of redo data from being sent from the primary database to at least one standby database.

This protection mode (the default) provides the highest level of data protection that is possible without affecting the performance of the primary database. This is accomplished by allowing a transaction to commit as soon as the redo data needed to recover that transaction is written to the local online redo log. The primary database's redo data stream is also written to at least one standby database, but the redo stream is written asynchronously with respect to the commitment of the transactions that create the redo data.

When network links with sufficient bandwidth are used, this mode provides a level of data protection that approaches that of maximum availability mode with minimal impact on primary database performance.

The maximum protection and maximum availability modes require that a standby redo log is configured on at least one standby database in the configuration. All three protection modes require that specific log transport attributes be specified on the LOG_ARCHIVE_DEST_n initialization parameter to send redo data to at least one standby database. See Oracle Data Guard Concepts and Administration for complete information about the data protection modes.

Step 2 Set up standby redo log (SRL) files, if needed.

If the data protection mode that you need requires a standby database to use the SYNC or ASYNC log transport mode, you need to add standby redo log files to at least one standby database. (Note that the maximum performance mode does not require standby redo log files.)

The Data Guard GUI automatically prompts you to select one or more standby databases in the configuration and sets up standby redo log (SRL) files on them and on the primary database in preparation for a future switchover. See Section 5.4.3 for additional information about changing the database protection mode.

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 3.4 for more information about setting the log transport mode. Table 3-2 shows the protection modes, the corresponding log transport mode, and indicates whether or not SRLs are needed.

The Data Guard GUI automatically specifies the correct log transport mode on the primary database in preparation for a future switchover. See Section 5.4.3 for additional information about changing the database protection mode.

Step 4 Set the protection mode.

Select the protection mode using the CLI or the Data Guard GUI. See Section 6.5 for additional information about setting the configuration protection mode.

With the CLI:

1. If you plan to set the protection mode to either the MAXPROTECTION or MAXAVAILABILITY, ensure that standby redo log files are configured on the standby database. Do this also for the primary database or another standby database in the configuration to ensure that it can support the chosen protection mode after a switchover.

2. Use the EDIT DATABASE (property) command and specify the standby database whose log transport mode should be changed to correspond 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 EDIT DATABASE command to set the SYNC mode for log transport services. For example:

   DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'LogXptMode'='SYNC';
   
   

   Do this also for the primary database or another standby database in the configuration to ensure that it can support the chosen protection mode after a switchover.

3. Use the EDIT CONFIGURATION SET PROTECTION MODE AS protection-mode command to set the overall configuration protection mode. For example:

   DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
   
   

With the Data Guard GUI:

1. From the Data Guard GUI overview page, click the link to the right of the Protection Mode label.

2. Select Maximum Protection, Maximum Availability, or Maximum Performance and click Continue.

3. If prompted, log in to the database with SYSDBA privileges and click Login.

4. Select one or more standby databases to support the protection mode that you selected. If standby redo log files are needed, verify the names of the log files. Click OK.

5. From the Confirmation page, click Yes.

After you upgrade the protection mode using either the CLI or the Data Guard GUI, the primary database will be restarted automatically. The primary database need not be restarted following a downgrade of the protection mode.

3.6.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 effect on the configuration's protection mode and 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 a Database from the Configuration

• Requirements On Other Operations