One of the prerequisites for using DGMGRL is that a primary database and any standby databases must already exist.

CREATE SPFILE='spfilename' FROM PFILE='pfilename';

These examples create a broker configuration named DRSolution that includes a primary and standby database named North_Sales and South_Sales.

After you create the configuration with DGMGRL, you can set database properties at any time.

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogArchiveFormat'='log_%t_%s_%r_%d.arc';
Property "LogArchiveFormat" updated.

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'StandbyArchiveLocation'='/archfs/arch/';
Property "StandbyArchiveLocation" updated.

DGMGRL> SHOW DATABASE VERBOSE 'South_Sales'

Database - South_Sales

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 0 seconds ago)
  Apply Lag:          0 seconds (computed 0 seconds ago)
  Average Apply Rate: 2.00 KByte/s
  Active Apply Rate:  0 Byte/s
  Maximum Apply Rate: 0 Byte/s
  Real Time Query:    ON
  Instance(s):
    South_sales1

  Properties:
    DGConnectIdentifier             = 'South_Sales.example.com'
    ObserverConnectIdentifier       = ''
    FastStartFailoverTarget         = ''
    PreferredObserverHosts          = ''
    LogShipping                     = 'ON'
    RedoRoutes                      = ''
    LogXptMode                      = 'ASYNC'
    DelayMins                       = '0'
    Binding                         = 'optional'
    MaxFailure                      = '0'
    ReopenSecs                      = '300'
    NetTimeout                      = '30'
    RedoCompression                 = 'DISABLE'
    PreferredApplyInstance          = ''
    ApplyInstanceTimeout            = '0'
    ApplyLagThreshold               = '0'
    TransportLagThreshold           = '0'
    TransportDisconnectedThreshold  = '0'
    ApplyParallel                   = 'AUTO'
    ApplyInstances                  = '0'
    StandbyFileManagement           = ''
    ArchiveLagTarget                = '0'
    LogArchiveMaxProcesses          = '0'
    LogArchiveMinSucceedDest        = '0'
    DataGuardSyncLatency            = '0'
    LogArchiveTrace                 = '0'
    LogArchiveFormat                = ''
    DbFileNameConvert               = 'dbs/cdb1_, dbs/cdb2_, dbs/t, dbs/bt, dbs/cdb4_, dbs/cdb2_, dbs/dt, dbs/bt'
    LogFileNameConvert              = 'dbs/cdb1_, dbs/cdb2_, dbs/t, dbs/bt, dbs/cdb4_, dbs/cdb2_, dbs/dt, dbs/bt'
    ArchiveLocation                 = ''
    AlternateLocation               = ''
    StandbyArchiveLocation          = ''
    StandbyAlternateLocation        = ''
    InconsistentProperties          = '(monitor)'
    InconsistentLogXptProps         = '(monitor)'
    LogXptStatus                    = '(monitor)'
    SendQEntries                    = '(monitor)'
    RecvQEntries                    = '(monitor)'
    HostName                        = 'South_Sales.example.com'
    StaticConnectIdentifier         = '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=South_Sales.example.com)(PORT=2879)))(CONNECT_DATA=(SERVICE_NAME=South_Sales_DGMGRL.example.com)(INSTANCE_NAME=south_sales1)(SERVER=DEDICATED)))'
    TopWaitEvents                   = '(monitor)'
    SidName                         = '(monitor)'

  Log file locations:
    Alert log               : /db/oracle/log/diag/rdbms/South_Sales/south_sales1/trace/alert_south_sales1.log
    Data Guard Broker log   : /db/oracle/log/diag/rdbms/South_Sales/south_sales1/trace/drcsouth_sales1.log

Database Status:
SUCCESS

So far, the DRSolution configuration is disabled, which means it is not under the control of the Data Guard broker.

DGMGRL> ENABLE CONFIGURATION;
Enabled.

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution
 
  Protection Mode: MaxPerformance
  Members:
    North_Sales  - Primary database
      South_Sales  - Physical standby database
 
Fast-Start Failover: DISABLED
 
Configuration Status:
SUCCESS

DGMGRL> ENABLE DATABASE 'South_Sales';
Enabled.

DGMGRL> SHOW DATABASE 'South_Sales';

Database - South_Sales
 
  Role:             PHYSICAL STANDBY
  Intended State:   APPLY-ON
  Transport Lag:    0 seconds (computed 1 second ago)
  Apply Lag:        0 seconds (computed 1 second ago)
  Apply Rate:       1.54 MByte/s
  Real Time Query:  OFF
  Instance(s):
    south_sales1
 
Database Status:
SUCCESS

You can change the protection mode of the configuration at any time.

This scenario sets the protection mode of the configuration to the MAXAVAILABILITY mode. Note that this protection mode requires that there be at least one standby configured to use standby redo log files and it must receive redo via SYNC or FASTSYNC mode if it receives redo directly from the primary database. If the standby receives redo via a far sync instance, then the far sync instance must receive redo via SYNC or FASTYSYNC mode and the standby must receive redo from the far sync instance via ASYNC mode.

1. Configure standby redo log files, if necessary.

   Because you will be setting the protection mode to the MAXAVAILABILITY mode, it is important to ensure that sufficient standby redo log files are configured on the standby database. For more information on setting up redo transport, see Oracle Data Guard Concepts and Administration.

2. Configure redo transport mode appropriately.

   Configure the standby to receive redo via SYNC or FASTSYNC mode, if the standby receives redo directly from the primary database. If the standby receives primary redo via a far sync instance, then configure the far sync instance to receive redo via SYNC or FASTSYNC mode and configure the standby to receive redo via ASYNC mode. For example:

   DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogXptMode'='SYNC';
   Property "LogXptMode" updated
   

   The broker will not allow this command to succeed unless the standby database is configured with standby redo log files in the configuration.

3. Change the overall protection mode for the configuration.

   Use the EDIT CONFIGURATION command to upgrade the broker configuration to the MAXAVAILABILITY protection mode:

   DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
   Succeeded.
   

   If the configuration is disabled when you enter this command, the actual protection mode change is not applied until you enable the configuration with the ENABLE CONFIGURATION command. The broker will not allow you to enable the configuration if it does not find a standby database in the configuration that can support the requirements of the protection mode.

4. Verify the protection mode has changed.

   Use the SHOW CONFIGURATION command to display the current protection mode for the configuration:

   DGMGRL> SHOW CONFIGURATION;
    
   Configuration - DRSolution
    
     Protection Mode: MaxAvailability
     Members:
       North_Sales  - Primary database
         South_Sales  - Physical standby database
    
   Fast-Start Failover: DISABLED
    
   Configuration Status:
   SUCCESS

   See Also:

   Managing Data Protection Modes

A far sync instance can be used with maximum availability protection mode if the primary and standby database are geographically far enough apart to make the use of synchronous transport mode impractical.

1. Issue the following commands to add the far sync instance named FS to the broker configuration:

   DGMGRL> ADD FAR_SYNC 'FS' AS CONNECT IDENTIFIER IS FS.EXAMPLE.COM;
   DGMGRL> ENABLE FAR_SYNC 'FS';
   DGMGRL> SHOW CONFIGURATION;
     
   Configuration - DRSolution
    
     Protection Mode: MaxPerformance
     Members:
     North_Sales - Primary database
       South_Sales - Physical standby database
       FS - Far Sync
    
   Fast-Start Failover: DISABLED
    
   Configuration Status:
   SUCCESS
   

   In this output, South_Sales and FS are indented under North_Sales. This indicates that the primary is sending redo data to both South_Sales and FS.

2. Issue the following commands so that the current primary (North_Sales) sends redo data to the far sync instance only, and the far sync instance sends redo data to South_Sales when North_Sales is a primary:

   DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY RedoRoutes='(LOCAL : FS SYNC)';
   DGMGRL> EDIT FAR_SYNC 'FS' SET PROPERTY RedoRoutes='(North_Sales : South_Sales');
   DGMGRL> SHOW CONFIGURATION;
    
   DGMGRL> SHOW CONFIGURATION;
    
   Configuration - DRSolution
    
     Protection Mode: MaxPerformance
     Members:
     North_Sales - Primary database
       FS - Far Sync
         South_Sales - Physical standby database
    
   Fast-Start Failover: DISABLED
    
   Configuration Status:
   SUCCESS
   

   The indentation scheme in the output above indicates that North_Sales sends redo data to FS and FS sends redo data to South_Sales.

3. Issue the following commands to upgrade the protection mode to maximum availability:

   DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
   DGMGRL> SHOW CONFIGURATION;
    
   Configuration - DRSolution
    
     Protection Mode: MaxAvailability
     Members:
     North_Sales - Primary database
       FS - Far Sync
         South_Sales - Physical standby database
    
   Fast-Start Failover: DISABLED
    
   Configuration Status:
   SUCCESS

   If South_Sales ever becomes the primary and North_Sales becomes a standby database that receives redo data from the far sync instance, FS, then the RedoRoutes property must be set for South_Sales. Additionally, a new rule must be included in the RedoRoutes property for FS to allow it to send redo data to North_Sales when South_Sales is the primary database.

   If these rules are not created, then North_Sales will not be able to receive redo data. To check whether the proper rules have been set, use the SHOW CONFIGURATION WHEN PRIMARY IS command to see what the redo transport configuration would be if South_Sales were the primary database. For example:

   DGMGRL> SHOW CONFIGURATION WHEN PRIMARY IS 'South_Sales';
    
   Configuration when South_Sales is primary - DRSolution
    
     Members:
     South_Sales  - Primary database
       FS     - Far Sync 
         North_Sales  - Physical standby database 
    
     Members Not Receiving Redo:
     North_FS - Physical standby database
     Warning: ORA-16685: database does not receive redo data
   

   To correct this error, set the RedoRoutes property for South_Sales and FS as follows:

   DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY RedoRoutes='(LOCAL : FS SYNC)';
   DGMGRL> EDIT FAR_SYNC 'FS' SET PROPERTY RedoRoutes=('North_Sales : South_Sales)(South_Sales : North_Sales)';
   

   After the change to the RedoRoutes property for South_Sales and FS is complete, use the SHOW CONFIGURATION WHEN PRIMARY IS command to confirm that the error has been cleared:

   DGMGRL> SHOW CONFIGURATION WHEN PRIMARY IS 'South_Sales';
    
   Configuration when South_Sales is primary - DRSolution
    
     Members:
     South_Sales  - Primary database
       FS     - Far Sync 
         North_Sales  - Physical standby database 

You can enable fast-start failover from any site, including the observer site, while connected to any database in the broker configuration.

1. Ensure standby redo logs are configured on the primary and target standby databases. You must stop log apply services prior to configuring standby redo logs.

   See Also:

   Oracle Data Guard Concepts and Administration for instructions on configuring standby redo log files

2. Configure the primary and standby databases to receive redo via SYNC or FASTSYNC mode, if they receive redo directly rather than via a far sync instance. If either database receives redo via a far sync instance, then configure the far sync instance to receive redo via SYNC or FASTSYNC mode and configure the database to receive redo via ASYNC mode. For example:

   DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogXptMode'='SYNC';
   Property "LogXptMode" updated
   

   DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogXptMode'='SYNC';
   Property "LogXptMode" updated
   

   The broker does not allow these commands to succeed unless the databases are configured with standby redo log files.

3. If you have two or more standby databases, set up the FastStartFailoverTarget configuration property on the primary database to indicate the desired target standby database. The broker reciprocally sets this property for the target standby database to indicate the primary database as its future target standby database when fast-start failover is actually enabled. There is no need for you set this property on the target standby as this is done for you automatically. For example:

   DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY FastStartFailoverTarget='South_Sales';
   Property "FastStartFailoverTarget" updated
   

4. If it is necessary to upgrade the protection mode, use the following DGMGRL EDIT CONFIGURATION command. For example:

   DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
   

5. If it is not already enabled on the primary and standby databases, enable Flashback Database by issuing the following statements on each database:

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;
   ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320 SCOPE=BOTH;
   ALTER DATABASE ARCHIVELOG;
   ALTER SYSTEM SET db_recovery_file_dest_size=<size>;
   ALTER SYSTEM SET db_recovery_file_dest=<directory-specification>;
   ALTER DATABASE FLASHBACK ON;
   ALTER DATABASE OPEN;
   

   Ensure that the DB_FLASHBACK_RETENTION_TARGET initialization parameter is set to a sufficiently large value so that reinstatement is still possible after a prolonged outage.

6. Start up to three observers by logging into the observer computers and running DGMGRL. Connect to the configuration as a user who has the SYSDG or SYSDBA privilege and then issue the START OBSERVER command. Note that the command does not return; that is you will not get the DGMGRL prompt after issuing the command.

   DGMGRL> CONNECT sysdg@North_Sales.example.com;
   Password: password
   Connected to "North_Sales"
   Connected as SYSDG.
   
   DGMGRL> START OBSERVER observer1 IN BACKGROUND
   > FILE IS /net/sales/dat/oracle/broker/fsfo.dat
   > LOGFILE IS /net/sales/dat/oracle/broker/observer.log
   > CONNECT IDENTIFIER IS North_Sales
   Submitted command "START OBSERVER" using connect identifier "North_Sales"
   

   Oracle recommends using this command format for security reasons; no credentials are visible. This practice prevents other users on the system from using a utility (for example, the UNIX ps utility) to display connection credentials. It also prevents clear-text passwords from being visible on the user's terminal.

   When starting the observer from a script, Oracle recommends that you use a method that supports 'connect /', so that database connection credentials do not have to be embedded within the script. If you choose to use a client-side Oracle Wallet as a secure external password store (see Oracle Database Enterprise User Security Administrator's Guide), be sure to add credentials for both the primary and fast-start failover target standby databases. The database connect string that you specify when adding the credentials for each database must match the ObserverConnectIdentifer or DGConnectIdentifier database property.

   When multiple observers are started, one observer is the master observer after fast-start failover is enabled, and the remaining observers are backup observers. Only the master observer can coordinate fast-start failover with Data Guard broker. If the primary and target standby databases stay connected but the connection to the master observer is lost, then the broker tries to nominate a backup observer as the new master observer.

7. Enable fast-start failover. You can enable fast-start failover while connected to any database system in the broker configuration. For example:

   DGMGRL> ENABLE FAST_START FAILOVER;
   Enabled.
   

8. Verify the fast-start failover configuration. Use the SHOW FAST_START FAILOVER command to display the fast-start failover settings:

   DGMGRL> SHOW FAST_START FAILOVER;
    
   Fast-Start Failover: DISABLED
    
     Threshold: 30 seconds
     Target: South_Sales
     Observer: observer.example.com
     Lag Limit: 30 seconds (not in use)
     Shutdown Primary: TRUE
     Auto-reinstate: TRUE
     Observer Reconnect: (none)
     Observer Override: FALSE
    
   Configurable Failover Conditions
    Health Conditions:
     Corrupted Controlfile  YES
     Corrupted Dictionary   YES
     Inaccessible Logfile    NO
     Stuck Archiver          NO
     Datafile Write Errors  YES
    
   Oracle Error Conditions:
   (none)
   

   The following commands show that the FastStartFailoverTarget property is set up reciprocally once fast-start failover is enabled. The first command, issued for the current primary database North_Sales, shows the value of the FastStartFailoverTarget property to be the current target standby, South_Sales. The second command, issued for the target standby South_Sales, shows the current primary, North_Sales, as the target standby's future target standby should it ever take over as a primary.

   DGMGRL> SHOW DATABASE 'North_Sales' FastStartFailoverTarget;
    FastStartFailoverTarget='South_Sales';
    
   DGMGRL> SHOW DATABASE 'South_Sales' FastStartFailoverTarget;
    FastStartFailoverTarget='North_Sales';

Fast-start failover can be enabled in maximum availability mode when the fast-start failover target is a logical or physical standby database that receives redo data from a far sync instance.

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY FastStartFailoverTarget='South_Sales';
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY FastStartFailoverTarget='North_Sales';

DGMGRL> ENABLE FAST_START FAILOVER;

There may be situations in which you want to change the state or properties of the databases in a broker configuration to perform routine maintenance on one or more databases.

You might also need to temporarily disable broker management of databases in a configuration.

You can switch the role of the primary database and a standby database using the SWITCHOVER command.

Before you issue the SWITCHOVER command, you must ensure:

• The state of the primary and standby databases are TRANSPORT-ON and APPLY-ON, respectively.

• All participating databases are in good health, without any errors or warnings present.

• The standby database properties were set on the primary database, so that the primary database can function correctly when transitioning to a standby database (shown in the following examples in boldface type).

• Standby redo log files are configured on the primary database.

• If the configuration is in maximum availability mode, then the current primary is configured to receive redo via SYNC or FASTSYNC mode if it will receive redo directly from the new primary. If it will receive redo via a far sync instance, then the far sync instance is configured to receive redo via SYNC or FASTSYNC mode and the current primary is configured to receive redo via ASYNC mode. If the configuration is in maximum protection mode, then the current primary is configured to receive redo via SYNC mode.

• If fast-start failover is enabled, you can perform a switchover only to the standby database that was specified as the target standby database.

The following are the tasks necessary to perform a switchover using the SWITCHOVER command:

• Using the SWITCHOVER Command Task 1: Check the Primary Database

• Using the SWITCHOVER Command Task 2: Check the Standby Database That is the Target of the Switchover

• Using the SWITCHOVER Command Task 3: Confirm That the Database Is Ready for a Role Change

• Using the SWITCHOVER Command Task 4: Issue the Switchover Command

• Using the SWITCHOVER Command Task 5: Show the Configuration

You invoke a failover operation in response to an emergency situation, usually when the primary database cannot be accessed or is unavailable.

1. (Optional) Check the readiness of the target standby.

   To validate the target standby database to ensure that it's ready to become the new primary database, use the VALIDATE DATABASE command, as shown in the following example:

   DGMGRL> VALIDATE DATABASE 'South_Sales';
    
   Database Role: Physical standby database
   Primary Database: South_Sales
    
   Ready for Switchover: Yes
   Ready for Failover: Yes
   

2. To perform the failover operation, you must connect to the standby database to which you want to fail over as a user that has the SYSDG or SYSDBA privilege. For example:

   DGMGRL> CONNECT sysdg@South_Sales.example.com;
   Password: password
   Connected to "South_Sales"
   Connected as SYSDG.
   

3. Now you can issue the failover command to make the target standby database the new primary database for the configuration.

   DGMGRL> FAILOVER TO 'South_Sales';
   Performing failover NOW, please wait...
   Failover succeeded, new primary is "South_Sales"
   

   Note that after the failover completes, the original primary database cannot be used as a standby database of the new primary database unless it is reinstated or re-created (as described in Reenabling Disabled Databases After a Role Change).

4. Issue the SHOW CONFIGURATION command to verify the failover.

   DGMGRL> SHOW CONFIGURATION;
    
   Configuration - DRSolution
    
     Protection Mode: MaxAvailability
     Members:
       South_Sales  - Primary database
         Warning: ORA-16629: database reports a different protection level from the protection mode
    
         North_Sales - Physical standby database (disabled)
           ORA-16661: the standby database needs to be reinstated
    
   Fast-Start Failover: DISABLED
    
   Configuration Status:
   WARNING
   

   Note that in this example, the configuration was operating in maximum availability mode. The protection mode was preserved after the failover. The configuration also has a warning status. The SHOW DATABASE command for the new primary shows that the warning is the result of not having an enabled physical standby database. As a result, the warning status indicates that the protection level of the configuration is not the same as the configured mode.

5. Show the new primary database.

   DGMGRL> SHOW DATABASE South_Sales;
   Database - South_Sales
    
     Role:            PRIMARY
     Intended State:  TRANSPORT-ON
     Instance(s):
       south_sales1
    
     Database Warning(s):
       ORA-16629: database reports a different protection level from the protection mode
    
   Database Status:
   WARNING
   

6. Issue the SHOW DATABASE command to see that the former (failed) primary database was disabled by the broker as a consequence of the failover. It must be reinstated (as described in Reenabling Disabled Databases After a Role Change).

   DGMGRL> SHOW DATABASE 'North_Sales';
   Database - North_Sales
    
     Role: PHYSICAL STANDBY
     Intended State: APPLY-ON
     Transport Lag: (unknown)
     Apply Lag: (unknown)
     Apply Rate: (unknown)
     Real Time Query: OFF
     Instance(s):
       north_sales1
    
   Database Status:
   ORA-16661: the standby database needs to be reinstated

If your former primary database was configured with Flashback Database, you can easily reinstate the failed primary database as a standby database of the new primary database.

1. Restart the old primary database:

   % dgmgrl connect sysdg
   Password: password
   Connected to "North_Sales"
   Connected as SYSDG.
   
   DGMGRL> startup mount;
   ORACLE instance started.
   Database mounted.
   

2. Reinstate the old primary database:

   % dgmgrl connect sysdg
   Password: password
   Connected to "North_Sales"
   Connected as SYSDG.
   
   DGMGRL> REINSTATE DATABASE 'North_Sales';
   Reinstating database "North_Sales", please wait...
   Reinstatement of database "North_Sales" succeeded
    
   Database dismounted.
   ORACLE instance shut down.
   Operation requires startup of instance "north_sales1" on database "North_Sales"
   Starting instance "north_sales1"...
   ORACLE instance started.
   Database mounted.
   Continuing to reinstate database "North_Sales" ...
   Reinstatement of database "North_Sales" succeeded
   

   After the primary has been reinstated, issue the SHOW CONFIGURATION and SHOW DATABASE commands to confirm that the old primary has been successfully reinstated.

3. Show the configuration and its members:

   DGMGRL> SHOW CONFIGURATION
    
   Configuration - DRSolution
    
     Protection Mode: MaxAvailability
     Members:
       South_Sales  - Primary database
         North_Sales  - Physical standby database
    
   Fast-Start Failover: DISABLED
    
   Configuration Status:
   SUCCESS
   
   DGMGRL> SHOW DATABASE 'South_Sales';
    
   Database - South_Sales
    
     Role:            PRIMARY
     Intended State:  TRANSPORT-ON
     Instance(s):
       south_sales1
    
   Database Status:
   SUCCESS
    
   DGMGRL> SHOW DATABASE 'North_Sales'
    
   Database - 'North_Sales'
    
     Role: PHYSICAL STANDBY
     Intended State: APPLY-ON
     Transport Lag: 0 seconds (computed 1 second ago)
     Apply Lag: 0 seconds (computed 1 second ago)
     Apply Rate: 0 Byte/s
     Real Time Query: OFF
     Instance(s):
       north_sales1
    
   Database Status:
   SUCCESS

If you have a physical standby database that you would like to convert to a snapshot standby database, use the DGMGRL CONVERT DATABASE command.

DGMGRL> convert database 'South_Sales' to snapshot standby;
Converting database "South_Sales" to a Snapshot Standby database, please wait...
Database "South_Sales" converted successfully

DGMGRL> SHOW CONFIGURATION;
 
Configuration - DRSolution
 
  Protection Mode: MaxPerformance
  Members:
    North_Sales  - Primary database
      South_Sales  - Snapshot standby database
 
Fast-Start Failover: DISABLED
 
Configuration Status:
SUCCESS

DGMGRL> CONVERT DATABASE 'South_Sales' to PHYSICAL STANDBY;
 
Converting database "South_Sales" to a Physical Standby database, please wait...
Operation requires shutdown of instance "south_sales1" on database "South_Sales"
Shutting down instance "south_sales1"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "south_sales1" on database "South_Sales"
Starting instance "south_sales1"...
ORACLE instance started.
Database mounted.
Continuing to convert database "South_Sales" ...
Database "South_Sales" converted successfully

These steps demonstrate the tasks necessary to use the SHOW command and monitorable properties to identify and resolve a failure situation.

• Monitoring a Configuration Task 1: Check the Configuration Status

• Monitoring a Configuration Task 2: Check the Database Status

• Monitoring a Configuration Task 3: Check the LogXptStatus Monitorable Property

• Monitoring a Configuration Task 4: Check the InconsistentLogXptProps Monitorable Property

These steps show how to add a Zero Data Loss Recovery Appliance (Recovery Appliance) to a broker configuration.

1. Add the Recovery Appliance to the broker configuration.

   DGMGRL> ADD RECOVERY_APPLIANCE EnterpriseRecoveryAppliance AS CONNECT IDENTIFIER IS
   EnterpriseRecoveryAppliance.example.com;
   Oracle Recovery Appliance "EnterpriseRecoveryAppliance" added
    
   DGMGRL> SHOW RECOVERY_APPLIANCE 'EnterpriseRecoveryAppliance';
    Oracle Recovery Server - EnterpriseRecoveryAppliance
      Transport Lag: 0 seconds
     Redo Source: North_Sales
    
   Oracle Recovery Appliance Status:
   DISABLED
   

2. Enable the Recovery Appliance

   DGMGRL> ENABLE RECOVERY_APPLIANCE 'EnterpriseRecoveryAppliance';
    
   DGMGRL> SHOW RECOVERY_APPLIANCE 'EnterpriseRecoveryAppliance';
    Oracle Recovery Server - EnterpriseRecoveryAppliance
      Transport Lag: 0 seconds
     Redo Source: North_Sales
    
   Oracle Recovery Appliance Status:
   SUCCESS