How to Create an Oracle Data Guard Broker Configuration

Data Guard Broker: Requirements

To use the Data Guard broker, you must comply with the following requirements:

• Use the Enterprise Edition of Oracle Database.
• Use a single-instance or multi-instance environment
• Set the COMPATIBLE initialization parameter to 12.1 to take advantage of new Oracle Database 12c Release 1 (12.1) features.
• Enterprise Manager automatically configures the Oracle Net Services network files when it creates a standby database. If you configure an existing standby database in the broker configuration, you must configure the network files. You must use TCP/IP.
• To enable the Data Guard broker to restart instances during the course of broker operations, a service with a specific name must be statically registered with the local listener of each instance. The value of the GLOBAL_DBNAME attribute must be set to a concatenation of db_unique_name_DGMGRL.db_domain.
• Set the DG_BROKER_START initialization parameter to TRUE. This starts the DMON process. Note: When you use Enterprise Manager to create your configuration, this parameter is automatically set to TRUE.
• The primary database must be in ARCHIVELOG mode.
• Any database that is managed by the broker (including, for a RAC database, all instances of the database) must be mounted or open. The broker cannot start an instance.
• If any database in your configuration is a RAC database, you must configure the DG_BROKER_CONFIG_FILEn initialization parameters for that database so that they point to the same shared files for all instances of that database. You cannot use the default values for these parameters. Note: The shared files could be files on a cluster file system or on raw devices, or the files could be stored using Automatic Storage Management (ASM).
• As of Oracle Database 12c Release 1 (12.1), for all databases to be added to a broker configuration any configuration, any LOG ARCHIVE DEST n LOG_ARCHIVE_DEST_n parameters that have the parameters that have the SERVICE SERVICE attribute attribute set, but not the NOREGISTER attribute, must be cleared.

Data Guard Broker and the SPFILE

To ensure that the broker can update the values of parameters in both the database instance and the configuration file, you must use the persistent server parameter file (SPFILE) to control static and dynamic initialization parameters. Use of the SPFILE gives the broker a mechanism that enables it to reconcile property values that you have selected when using the broker with any related initialization parameter values that are recorded in the SPFILE. In addition, the SPFILE permits persistent Data Guard settings so that Data Guard continues to work even after the broker is disabled.

When you set definitions or values for database properties in the broker configuration, the broker records the changes in the configuration file and also propagates the changes to the related initialization parameters in the server parameter file in the Data Guard configuration. When the configuration is enabled, the broker keeps the database property values in the Data Guard configuration file consistent with the values of the database initialization parameters in the SPFILE.

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 SPFILE and the in-memory g settings the next time you enable the broker configuration.

For dynamic initialization parameters, the broker keeps the value of the database parameter consistent in the System Global Area (SGA) for the instance, in the Data Guard configuration files, and in the SPFILE. For static initialization parameters, the value in the SGA may differ from what is in the configuration files and in the SPFILE. Typically, the broker reconciles the differences by updating all parameter and property values the next time the database instance is stopped and restarted.

Summary

• You must use a server parameter file (SPFILE) for initialization parameters.
• Using the SPFILE enables the Data Guard broker to keep its configuration file and the database SPFILE consistent.
• If you use the broker, use Enterprise Manager Cloud Control or DGMGRL to update database parameter values.

Data Guard Monitor: Configuration File

The broker configuration file is: – Automatically created and named using a default path name and file name when the broker is started – Managed automatically by the DMON process

The configuration file and a copy are created at each managed site with default names: – dr1.dat – dr2.dat

Configuration file default locations are operating system–specific: – Default location for UNIX and Linux: ORACLE_HOME/dbs – Default location for Windows: ORACLE_HOME\database

Use DG_BROKER_CONFIG_FILEn to override the default path name and file name.

The DMON process maintains persistent configuration data about all the databases in the broker configuration in a broker configuration file. Every database that is part of the Data Guard broker configuration has two broker configuration files that are maintained and synchronized for each database in the broker configuration. One of the files is in use and the other acts as a backup. The configuration files are binary files and cannot be edited.

When the broker is started for the first time, the configuration files are created and named automatically by using a default name. You can override this default name by setting the DG_BROKER_CONFIG_FILEn initialization parameters. You can also change the configuration file names dynamically by issuing the ALTER SYSTEM SQL statement. You must disable the broker configuration and stop the disable the broker configuration and stop the DMON process before changing the names process before changing the names.

The configuration files contain entries that describe the state and properties of the databases in the configuration. For example, the files record the databases that are part of the configuration, the roles and properties of each of the databases, and the state of each of the databases in the configuration. Two files are maintained so that there is always a record of the last-known valid state of the configuration. 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 Enterprise Manager.

Data Guard Broker: Log Files

The broker log files contain information recorded by the DMON process. The DMON process records operational and status information in the broker log file for each instance in the Data Guard broker configuration. Broker log files are created in the same directory as the alert log and are named drc.log.

Creating a Broker Configuration

• Clear existing LOG_ARCHIVE_DEST_n entries on every instance that references network locations.
• Invoke DGMGRL and connect to the primary database.
• Define the configuration including a profile for the primary Define the configuration, including a profile for the primary database.
• Add standby databases to the configuration.
• Add Far Sync instances to the configuration.
• Enable the configuration, including the databases.
• Define routing rules for the configuration.

Detailed steps for creating a broker configuration will be shown in the following sections.

Clear Redo Transport Network Locations on Primary

Clear existing LOG_ARCHIVE_DEST_n entries on each instance that references network locations:

SQL> select name,value from v$parameter where value like '%SERVICE% %SERVICE% ;'

NAME                  VALUE
-------------------   --------------------------------
log_archive_dest_2    SERVICE=bostonFS SYNC REOPEN=15 valid_for=(ONLINE_LOGFILES, PRIMARY_ROLE) db_unique_name = bostonFS
log_archive_dest_3    SERVICE=london2 SYNC REOPEN=15 valid_for=(ONLINE_LOGFILES, PRIMARY_ROLE) db_unique_name = london2

SQL> alter system log_archive_dest_2='' scope=both;
SQL> alter system log_archive_dest_3='' scope=both;

As of Oracle Database 12c Release 1 (12.1), no database can be added to the Data Guard broker configuration if the database instance has a LOG_ARCHIVE_DEST_n parameter using the SERVICE attribute. For an existing Data Guard environment created with SQL, this includes the primary database, physical standby databases, logical standby databases, and Far Sync instances.

You must clear any remote redo transport destinations on the primary database that do not have the NOREGISTER attribute, before a configuration can be created. Otherwise, the following error message is returned when you attempt to create the configuration:

ORA-16698: LOG_ARCHIVE_DEST_n parameter set for object to be added Failed.

Connecting to the Primary Database with DGMGRL

Similar to SQL*Plus, DGMGRL can connect using operating system authentication (not shown in the above slide), local user authentication, and remote user authentication using the password file. The generic syntax is as follows:

DGMGRL> CONNECT username/password[@connect-identifier]

The username and password must be valid for the configuration member to which you are trying to connect. The username you specify must have the SYSDG or SYSDBA privilege. Do not include AS SYSDG or AS SYSDBA on the CONNECT command. DGMGRL first attempts an AS SYSDG connection. If that fails, it will then attempt an AS SYSDBA connection. Additional database account users can be added to the password file by granting them the SYSDG privilege The following query can show who has the privilege. The following query can show who has the SYSDG privilege:

SQL> select * from v$pwfile_users;
USERNAME           SYSDB SYSOP SYSAS SYSBA SYSDG SYSKM CON_ID
------------------ ----- ----- ----- ----- ----- ----- ----------
SYS                 TRUE  TRUE FALSE FALSE FALSE FALSE        0
SYSDG               FALSE FALSE FALSE FALSE TRUE FALSE        1
SYSBACKUP           FALSE FALSE FALSE TRUE FALSE FALSE        1
SYSKM               FALSE FALSE FALSE FALSE FALSE TRUE        1

Example of connecting to the primary database on the local system:

DGMGRL> connect sysdg/password

Example of connecting to the primary database remotely using the password file:

DGMGRL> connect sysdg/password@boston

Example of adding a database user to the password file:

SQL> grant sysdg to dguser;

Defining the Broker Configuration and the Primary Database Profile

Execute the CREATE CONFIGURATION command to define the broker creation and create a profile for the primar database.

DGMGRL> CREATE CONFIGURATION 'DRSolution' AS PRIMARY
        DATABASE IS 'boston' CONNECT IDENTIFIER IS
        boston;
Configuration "DRSolution" created with primary database "boston"

The following parameters must be specified:

• configuration-name: User-specified name for the configuration
• database-name: Used by the broker to reference the primary database. You must use the value of the DB_UNIQUE_NAME initialization parameter for the database name.
• connect-identifier: The value you specify for the connect identifier is a fully specified connect descriptor or a name to be resolved by an Oracle Net Services naming method. The broker uses this value to communicate with the other databases defined in the configuration. The DGConnectIdentifier database property is set to the connect identifier value.

To view the configuration:

DGMGRL> show configuration
Configuration - DRSolution

  Protection Mode: MaxPerformance
  Databases:
  boston - Pri db mary database

Fast-Start Failover: DISABLED

Configuration Status:
DISABLED

Adding a Standby Database to the Configuration

Use the ADD DATABASE DGMGRL command to define the standby database and create a broker configuration profile. The database name specified must be the same as the value of the DB_UNIQUE_NAME initialization parameter. The connect identifier is used by Oracle Net Services to access the database from all other databases in the configuration.

DGMGRL> add database 'london' as connect identifier is
    london;
Database "london" added

DGMGRL> show configuration
Configuration - DRSolution

  Protection Mode: MaxPerformance
  Databases:
  boston - Primary database
    london - Phy y sical standby database

Fast-Start Failover: DISABLED

Configuration Status:
DISABLED

The AS CONNECT IDENTIFIER clause is optional. If you do not specify this clause, the broker will search the LOG_ARCHIVE_DEST_n initialization parameters on the primary database for an entry that corresponds to the database being added.

The broker uses the specified connect-identifier to communicate with the specified database from other databases. Therefore, you must ensure that the connect-identifier can be used to address the specified database from all databases in your configuration. For example, if TNS is used as the naming method, you must ensure that the tnsnames.ora file on every database and instance that is part of the configuration contains an entry for the connect identifier. The connect identifier must resolve to the same connect descriptor.

Adding a Far Sync to the Configuration

Use the ADD FAR_SYNC DGMGRL command to define the Far Sync and create a broker configuration profile. The Far Sync name specified must be the same as the value of the DB_UNIQUE_NAME initialization parameter. The connect identifier is used by Oracle Net Services to access the database from all other databases in the configuration.

DGMGRL> add far_sync 'bostonFS' as connect identifier is
    bostonFS;
far sync instance "bostonFS" added

DGMGRL> show configuration
Configuration - DRSolution

  Protection Mode: MaxPerformance
  Databases:
  boston - Primary database
    bostonFS - Far Sync (inactive)
    london - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
DISABLED

Enabling the Configuration

After defining the databases in the configuration, you enable the configuration and its databases by executing the ENABLE CONFIGURATION DGMGRL command.

DGMGRL> ENABLE CONFIGURATION;
Enabled.

DGMGRL> SHOW CONFIGURATION
Configuration - DRSolution

  Protection Mode: MaxPerformance
  Databases:
  boston - Primary database
    bostonFS - Far Sync (inactive)
    london - Physical standby database
    london - logical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

Broker Support for Complex Redo Routing

By default, a primary database sends the redo that it generates to every other redo transport destination in the configuration. You can use the RedoRoutes property with Oracle Data Guard 12c to create a more complex redo transport topology, such as one in which a physical standby database or a Far Sync forwards redo received from the primary database to one or more destinations, or one in which the redo transport mode used for a given destination depends on which database is in the primary role.

The RedoRoutes broker property allows more complex routing to be defined.

• Supports cascaded configurations
• Supports Far Sync configurations
• Supports real-time cascading and without real-time cascading
• Supports rules dependent on which Supports rules dependent on which database is the current database is the current primary
• Supports the new Fast Sync configuration

Defining RedoRoutes by Using DGMGRL

(redo source : redo destination) (LOCAL : redo destination ATTRIBUTE)
(redo source : redo destination, redo destination ATTRIBUTE)

The RedoRoutes property is set to a character string that contains one or more redo routing rules.

DGMGRL> EDIT DATABASE database-name
        SET PROPERTY 'RedoRoutes' = '(redo routing rule 1)(redo routing rule n)';

Each rule contains one or more redo sources and one or more redo destinations. A redo routing rule becomes active when one of the redo sources in the rule is in the primary role. This results in redo from the primary database being sent to every redo destination in that rule. A redo routing rule contains a redo source field and a redo destination field, separated by a colon:

(redo source : redo destination)

The redo source field must contain the LOCAL keyword or a comma-separated list of DB_UNIQUE_NAME values:

{LOCAL | db_unique_name_1,[,db_unique_name_n]}

You cannot set the RedoRoutes property on a logical or snapshot standby database.

In summary:

• The RedoRoutes property is set to a character string that contains one or more redo routing rules.
• Each rule contains one or more redo sources and one or more redo destinations, separated by a colon.
• The redo source field must contain the LOCAL keyword or a comma-separated list of DB_UNIQUE_NAME values.
• The redo destination field must contain the keyword ALL or a comma-separated list of database names, each of which can be followed by an optional redo transport attribute.

RedoRoutes Usage Guidelines

The RedoRoutes property has a default value of NULL, which is treated as (LOCAL : ALL). A redo routing rule is active if its redo source field specifies the current primary database. If a rule is active, primary database redo is sent by the database at which the rule is defined to each destination specified in the redo destination field of that rule. The ASYNC redo transport attribute must be explicitly specified for a cascaded destination to enable real-time cascading to that destination. The RedoRoutes property cannot be set on a logical or snapshot standby database.

Summary

• The RedoRoutes property has a default value of NULL, which is treated as (LOCAL : ALL).
• A redo routing rule is active if its redo source field specifies the current primary database.
• If a rule is active, primary database redo is sent by the database at which the rule is defined to each destination specified in the redo destination field of that rule.
• The ASYNC redo transport attribute must be explicitly specified for a cascaded destination to enable real specified for a cascaded destination to enable real-time cascading to that destination.
• The RedoRoutes property cannot be set on a logical or snapshot standby database.

Far Sync Example with RedoRoutes

An example Far Sync configuration for a Maximum Availability broker configuration:

• Primary database in Boston, MA.
• Far Sync in Cambridge MA Far Sync in Cambridge, MA.
• Physical standby in Chicago, IL.
• Far Sync in Shaumburg, IL. (for role reversal)

DGMGRL> EDIT DATABASE Boston SET PROPERTY 'RedoRoutes' = '(LOCAL : Cambridge SYNC)';
DGMGRL> EDIT FAR SYNC Cambridge SET PROPERTY DGMGRL> EDIT FAR_SYNC Cambridge SET PROPERTY 'RedoRoutes RedoRoutes' = '(Boston : Chicago (Boston : Chicago ASYNC)';
DGMGRL> EDIT DATABASE Chicago SET PROPERTY 'RedoRoutes' = '(Local : Shaumburg SYNC)';
DGMGRL> EDIT FAR_SYNC Shaumburg SET PROPERTY 'RedoRoutes' = '(Chicago : Boston ASYNC)';

After Data Guard broker has been configured for a primary database, Far Sync, physical standby, and a second Far Sync for role reversal, the configuration will appear as follows:

DGMGRL> SHOW CONFIGURATION;
Configuration - The SUPER cluster
  Protection Mode: MaxAvailability
  Databases:
  Boston - Primary database
    Cambridge - Far Sync
      Chicago - Ph i l db d b Physical standby database
        Shaumburg – Far Sync (Inactive)
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

Notice that in the output of the show configuration command, indentation is used to show that a database or Far Sync instance is receiving redo from a source location The use of RedoRoutes overrides the LogXptMode Data Guard property.

Changing Database Properties and States

Configurable database properties can be viewed and dynamically updated by using the EDIT DATABASE SET PROPERTY DGMGRL command.

- To alter the state of only the primary database:

DGMGRL> EDIT DATABASE boston SET STATE='TRANSPORT-OFF';

The EDIT DATABASE SET STATE DGMGRL command is used to change the state of the primary database and standby databases.

- To alter the state of a physical or logical standby database:

DGMGRL> EDIT DATABASE boston SET STATE='APPLY-OFF';

- To alter a configurable database property:

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

When the broker configuration is enabled, the databases are in one of four states:

• TRANSPORT-ON (applicable only to the primary database): Redo transport services transmit redo data to the standby databases when the primary database is open in read/write mode.
• TRANSPORT-OFF (applicable only to the primary database): Redo transport services are stopped on the primary database.
• APPLY-ON (applicable only to a physical or logical standby database): Redo Apply is started on the physical standby database when it is mounted or in open read-only mode. SQL Apply is started on a logical standby database when it is opened and the logical standby database guard is on.
• APPLY-OFF (applicable only to a physical or logical standby database): Redo Apply is standby stopped on a physical standby database. SQL Apply is not running on a logical standby database.

Use the SHOW DATABASE VERBOSE command to obtain a complete list of database properties.

DGMGRL> SHOW DATABASE VERBOSE

Managing Redo Transport Services by Using DGMGRL

The properties that the Data Guard broker uses can be categorized into configuration properties that control the behavior of the broker configuration, monitorable (read-only) properties for information, and configurable properties. The properties listed below are configurable properties related to redo transport services specifically.

Managing Redo Transport Services by Using DGMGRL

The properties that the Data Guard broker uses can be categorized into configuration properties that control the behavior of the broker configuration, monitorable (read-only) properties for information, and configurable properties. The properties listed below are configurable properties related to redo transport services specifically.

Property	Purpose
AlternateLocation	Specifies an alternate disk location to store the archived redo log files in the standby when the location specified by the StandbyArchiveLocation configurable property fails
ApplyLagThreshold	Generates a warning status for a logical or physical standby when the member’s apply lag exceeds the value specified by the property
ArchiveLagTarget	Limits the amount of data that can be lost and, effectively, increases the availability of the standby database or Far Sync instance by forcing a log switch after the amount of time you specify (in seconds) elapses
Binding	Specifies whether the redo destination is MANDATORY or OPTIONAL
DGConnectIdentifier	Specifies the connection identifier the broker uses when making connections to a configuration member.
LogArchiveFormat	Specifies the format for filenames of archived redo log files using a database ID (%d), thread (%t), sequence number (%s), and resetlogs ID (%r)
LogArchiveMaxProcesses	Specifies the initial number of archiver processes (ARCn) that are invoked
LogArchiveMinSucceedDest	Controls when online redo log files are available for reuse provided archiving has succeeded to a minimum number of destinations
LogShipping	Specifies the ENABLE and DEFER values for the LOG_ARCHIVE_DEST_STATE_n initialization parameter of the database or Far Sync instance that is sending redo data
LogXptMode	Specifies the redo transport services on each configuration member to SYNC, ASYNC, or FASTSYNC
MaxConnections	Specifies how many ARCn processes will be used in parallel to transmit redo data from a single archived redo log on the database or Far Sync instance to the archived redo log at the remote site
MaxFailure	Specifies the maximum number of contiguous archiving failures before the redo transport services stop trying to transport archived redo log files to the standby database
NetTimeout	Specifies the number of seconds the LGWR waits for Oracle Net Services to respond to a LGWR request and is used to bypass the long connection timeout in TCP/IP
RedoCompression	Specifies whether redo data is transmitted to a standby database or Far Sync instance in compressed or uncompressed form
ReopenSecs	Specifies the minimum number of seconds before the archiver process (ARCn, foreground, or log writer process) should try again to access a previously failed destination
StandbyArchiveLocation	Specifies the location of archived redo log files arriving from a redo source
TransportDisconnectedThreshold	Used to generate a warning status for a logical, physical, or snapshot standby, or a Far Sync instance when the last communication from the primary database exceeds the value specified in seconds
TransportLagThreshold	Used to generate a warning status for a logical, physical, or snapshot standby, or a Far Sync instance when the member’s transport lag exceeds the value specified in seconds

Managing the Redo Transport Service by Using the by Using the LogXptMode Property

The redo transport service must be set up for the chosen data protection mode. Use the Data Guard broker LogXptMode property to set redo transport services.

• ASYNC: Configures redo transport services by setting the ASYNC and NOAFFIRM attributes of the LOG ARCHIVE DEST n initialization parameter
• SYNC: Configures redo transport services by setting the SYNC and AFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter
• FASTSYNC: Configures redo transport services by setting the SYNC and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter

Definitions of LOG_ARCHIVE_DEST_n Attributes

• ASYNC: Redo data that is generated by a transaction need not have been received at a destination that has this attribute before the transaction can commit.

• SYNC: Redo data that is generated by a transaction must have been received by every enabled destination that has this attribute before the transaction can commit.

• AFFIRM and NOAFFIRM: Control whether redo transport services use synchronous or asynchronous disk I/O to write redo data to the archived redo log files

  • AFFIRM: Specifies that a redo transport destination acknowledges received redo data after writing it to the standby redo log
  • NOAFFIRM: Specifies that a redo transport destination acknowledges received redo data before writing it to the standby redo log

Setting LogXptMode to ASYNC

When you set the LogXptMode property to ASYNC, the broker configures redo transport services for this standby database by using the ASYNC and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. ASYNC mode enables a moderate level of data protection for the primary database with a lower performance impact than SYNC mode.

Standby redo log files are required for ASYNC mode. In the diagram above, the solid line represents a synchronous operation (writing locally to the primary database online redo log files). The broken lines represent asynchronous operations with respect to the transaction commit on the primary database.

Setting LogXptMode to SYNC

When you set the LogXptMode database property to SYNC, the broker configures redo transport services for this standby database by using the SYNC and AFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. This mode enables the highest level of data protection to the primary database but also incurs the highest performance overhead.

Standby redo log files are required for SYNC mode. In the diagram above, the solid line represents a synchronous operation (writing locally to the primary database online redo log files). The broken lines represent asynchronous operations with respect to the transaction commit on the primary database.

Setting LogXptMode to FASTSYNC (New in Oracle Database 12c)

When you set the LogXptMode database property to FASTSYNC, the broker configures redo transport services for this standby database by using the SYNC and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. This mode is new for Oracle Database 12c. Standby redo log files are required for FASTSYNC mode.

In the diagram above, the solid line represents a synchronous operation (writing locally to the primary database online redo log files). The broken lines represent asynchronous operations with respect to the transaction commit on the primary database.

Disabling Broker Management of the Configuration or Standby Database

You can disable broker management of a configuration or a specific standby database. You may want to disable broker management to perform maintenance or to temporarily prevent automated actions for testing.

Disabling broker management does not affect the underlying Data Guard configuration. Rather, it removes the ability for you to manage the configuration by using DGMGRL or Enterprise Manager Cloud Control.

Use the DISABLE CONFIGURATION DGMGRL command to disable broker management of the configuration. Use the DISABLE DATABASE DGMGRL command to disable broker management of the named standby database.

- Disable broker management of the configuration:

DGMGRL> DISABLE CONFIGURATION;

- Disable broker management of a standby database:

DGMGRL> DISABLE DATABASE 'london';

- Disable broker management of a Far Sync:

DGMGRL> DISABLE FAR_SYNC 'londonFS';

Removing the Configuration or Standby Database

Use the REMOVE DATABASE command to delete the named standby database from the broker configuration. Use the REMOVE CONFIGURATION command to delete the configuration. When you execute the REMOVE CONFIGURATION command, the broker configuration is removed, all database profiles are removed, the Data Guard broker configuration files is removed, and broker management of all databases in the configuration is terminated. Execution of this command does not affect the underlying databases. You cannot remove the configuration when faststart failover is enabled.

The PRESERVE DESTINATIONS syntax is available for both the REMOVE DATABASE and REMOVE CONFIGURATIONS REMOVE CONFIGURATIONS commands By default broker settings for LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_CONFIG initialization parameters are removed when the REMOVE commands are issued, but PRESERVE DESTINATIONS maintains these initialization parameters. A common usage for this is to allow the Data Guard broker to perform all of the setup for the LOG_ARCHIVE_DEST_n initialization parameters and then remove the broker when it has finished.

- Remove a standby database from the configuration:

DGMGRL> REMOVE DATABASE 'london2' [PRESERVE DESTINATIONS];

- Remove a Far Sync from the configuration:

DGMGRL> REMOVE FAR_SYNC 'londonFS';

- Remove the configuration:

DGMGRL> REMOVE CONFIGURATION [PRESERVE DESTINATIONS];