Database Status

In general, the broker checks the health of a database by verifying that the actual database state and settings match those described in the broker configuration file.

This is done by checking if any component of the Oracle Data Guard configuration is functioning incorrectly (for example, if redo transport services have an error), and by checking if other required database settings are correctly set (for example, if the server parameter files are available and if the ARCHIVELOG mode is turned on). The following is a detailed list of what is being checked by the broker on a primary database and a standby database.

On a primary database, the health check determines whether the following conditions are met:

  • Database is in the state specified by the user, as recorded in the broker configuration file

  • Database is in the correct data protection mode

  • Database is using a server parameter file

  • Database is in the ARCHIVELOG mode

  • Database guard is turned off

  • Supplemental logging is turned on when there is a logical standby database in the configuration

  • Redo transport services do not have any errors

  • Database settings match those specified by the broker configurable properties

  • Redo transport settings match those specified by the redo transport-related properties of the standby databases

  • Current data protection level is consistent with configured data protection mode

  • Primary database is able to resolve all gaps for all standby databases

On a standby database, the health check determines whether the following conditions are met:

  • Database is in the state specified by the user, as recorded in the broker configuration file

  • Database is using a server parameter file

  • Database settings match those specified by the broker configurable properties

  • Database guard is turned on when the database is a logical standby database

  • Primary and target standby databases are synchronized or within lag limits if fast-start failover is enabled

Querying Database Status

Certain monitorable properties can be used to query the database status.

The following properties are directly accessed through the DGMGRL command-line interface:

  • LogXptStatus

  • InconsistentLogXptProps

    Note:

    Cloud Control rearranges the values of these properties for presentation in the GUI.

You can use the SHOW DATABASE <db_unique_name> command to get a brief description of the database (name, role, and so on), database status, and information about any health check problems. For example, the output of the following SHOW DATABASE command shows two problems: some redo transport services errors and an inconsistent redo transport-related property 

DGMGRL> SHOW DATABASE 'North_Sales';
 
Database - North_Sales
  Role: PRIMARY
  Intended State: TRANSPORT-OFF
  Instance(s):
    north_sales1
      Error: ORA-16737: the redo transport service for standby
        database "South_Sales" has an error
 
    north_sales2
      Error: ORA-16737: the redo transport service for standby
        database "South_Sales" has an error
      Warning: ORA-16715: redo transport-related property
        ReopenSecs of standby "South_Sales" is inconsistent
Database Status:
ERROR

To further check the details about the database status, you can use the following monitorable properties:

  • LogXptStatus — lists all log transport errors detected on all instances of the primary database.

  • InconsistentLogXptProps — lists all redo transport-related properties of standby databases that have inconsistent values between the broker configuration file and the redo transport settings.

Issue the following SHOW DATABASE commands to obtain further details about the problems. 

DGMGRL> SHOW DATABASE 'North_Sales' 'LogXptStatus';
LOG TRANSPORT STATUS
PRIMARY_INSTANCE_NAME  STANDBY_DATABASE_NAME  STATUS 
         north_sales1            South_Sales  ORA-12541: TNS:no listener
         north_sales2            South_Sales  ORA-12541: TNS:no listener
 
DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentLogXptProps';
INCONSISTENT LOG TRANSPORT PROPERTIES
 INSTANCE_NAME  STANDBY_NAME  PROPERTY_NAME  MEMORY_VALUE  BROKER_VALUE 
  north_sales2   South_Sales     ReopenSecs           600           300

See Also:

Oracle Data Guard Broker Properties for detailed information about database properties

Validating a Database Before a Role Change

You can use the VALIDATE DATABASE command to perform a comprehensive set of database checks prior to performing a role change.

The command checks the following items:

  • Whether there is missing redo data on a standby database

  • Whether flashback is enabled

  • The number of temporary tablespace files configured

  • Whether an online data file move is in progress

  • Whether online redo logs are cleared for a physical standby database

  • Whether standby redo logs are cleared for a primary database

  • The online log file configuration

  • The standby log file configuration

  • Apply-related property settings

  • Transport-related property settings

  • Whether there are any errors in the Automatic Diagnostic Repository (for example, control file corruptions, system data file problems, user data file problems)

In addition, the role change readiness evaluation for the primary and standby databases does the following:

  • If Fast Start Failover (FSFO) is enabled for the broker configuration, the following conditions must be satisfied for the primary database to be ready for switchover:
    • For SYNC FSFO, the FSFO state must be SYNC.
    • For ASYNC FSFO, the FSFO state must be NOT LAGGING, or the lag must be less than or equal to FastStartFailoverLagLimit.
    • FSFO is not SUSPENDED
    • The PDB SAVE STATE is not configured.
  • If Fast Start Failover (FSFO) is enabled for the broker configuration, the following conditions must be satisfied for the standby database to be ready for switchover:
    • For SYNC FSFO, the FSFO state must be SYNC.
    • For ASYNC FSFO, the FSFO state must be NOT LAGGING, or the lag must be less than or equal to FastStartFailoverLagLimit.
    • FSFO is not SUSPENDED
  • If Fast Start Failover (FSFO) is enabled for the broker configuration, the following conditions must be satisfied for the standby database to be ready for failover:
    • For SYNC FSFO, the FSFO state must be SYNC.
    • For ASYNC FSFO, the FSFO state must be NOT LAGGING, or the lag must be less than or equal to FastStartFailoverLagLimit.
    • FSFO is not SUSPENDED
    • FSFO state is OBSERVED.

See Also:

  • "VALIDATE DATABASE" for a description of the command and for examples that show command output for various scenarios

Validating the Server Parameter Files Before a Role Change

Use the VALIDATE DATABASE SPFILE command to compare the contents of the server parameter file (SPFILE) between the primary and standby database.

Comparing the primary to the standby lets you determine whether there are any missing parameters in either database’s SPFILE, or whether the entries contain different values.

See Also:

Validating the Network Configuration Before a Role Change

Use the VALIDATE NETWORK CONFIGURATION command to perform network connectivity checks between members of a configuration.

Performing a network connectivity check identifies potential network configuration problems before a role change is attempted.

See Also:

Validating the Static Connect Identifier Before a Role Change

A single-instance database on which Oracle Restart is not configured must have a static service registered with the listener so that the DGMGRL CLI can automatically start the instance when necessary (for example, for the new standby after a switchover).

The broker sets up a default value for the StaticConnectIdentifier property that uses that static service (assuming the default value of db_unique_name_DGMGRL is used for the static service name). This connect identifier is used for instance restart.

Use the VALIDATE STATIC CONNECT IDENTIFIER command to confirm that the connect identifier specified by the StaticConnectIdentifier property can be used to restart an instance. The command does not restart the database, but rather checks that the service specified in the connect identifier is registered with the listener.

See Also:

Validating the DGConnectIdentifier Property

The DGMGRL command VALIDATE DGConnectIdentfier enables users to check to see whether a connection string is valid for the DGConnectidentifier property or not.

The VALIDATE DGConnectIdentifier command checks if it is able to be translated to something useful and makes a connection using it on all configuration members. This can also be used prior to adding a member to the configuration. If no configuration exists, the command checks a connection string at the database DGMGRL is connected to. If a configuration exists, all members use the specified connection string to see that the connection works.

This command performs the following for each instance of all members.
  • Prints a network translation of the connection string at the instance.
  • Prints environment variables related to network configuration at the instance.
  • Makes a new connection using the translated network address at the instance.
  • If a connection test succeeds, the instance name and db_unique_name of the connected database will be printed.
  • Checks that the service name specified in the connect identifier is the db_unique_name service for the database that the command connected to.

See Also: