General Problems and Solutions

ORA-16596: database not part of the Oracle Data Guard broker configuration

A request was issued to the broker, but the database instance through which you have connected is no longer a part of the broker configuration.

Solution

Reconnect to the configuration through another database that you know is part of the broker configuration. Confirm that a database exists in the broker configuration that has a name that matches the db_unique_name value of the database that returned the ORA-16596 error.

This problem can also occur if you attempt to enable a configuration, but the broker configuration file for one of its databases was accidentally removed or is outdated. In this case, remove the database from the broker configuration, manually delete the configuration file for that standby database (not for the primary database), and try again to enable the configuration. After the configuration is enabled, you can either use the Cloud Control Add Standby Database wizard and choose the Add existing standby database option, or you can use the DGMGRL command-line interface and issue the ADD DATABASE command.

Redo Accumulating on the Primary Is Not Sent to Some Standby Databases

By viewing the Log File Details page in Cloud Control, you have determined that log files are accumulating on the primary database and are not being archived to some of the standby databases in the broker configuration.

Solution

To narrow down the problem, do the following:

Verify that the state of the primary database is in the TRANSPORT-ON state (not TRANSPORT-OFF).
Verify that the value of the LogShipping database property of the standby database in question is ON.
Check the status of the redo transport services on the primary database using the LogXptStatus monitorable property. If redo transport services have an error, then use the error message to determine further checking and resolution action. For example:
- If the error indicates the standby database is not available, you need to restart the standby database.
- If the error indicates no listener, you need to restart the listener.
- If the error indicates the standby database has no local destination, you need to set up a standby location to store archived redo log files from the primary database.

Many Log Files Are Received on a Standby Database But Not Applied

By viewing the Performance page or Log File Details page in Cloud Control, you have determined that the standby database accumulates too many log files without applying them.

Solution

There are many possible reasons why archived redo log files might not be applied to the standby database. Investigate why the log files are building up and rule out the valid reasons.

If the current status of the standby database is not normal:

Determine whether or not the log apply services might be unexpectedly stopped. See the ORA-16766 (for physical standby databases) or ORA-16768 (for logical standby databases) error description and solution statement for more help.
If this is a logical standby database, check to see if a failed transaction has occurred.
If you want to suppress the error while you investigate the problem, you can temporarily disable broker management of the database.

See Also:

Oracle Data Guard Command-Line Interface Reference for additional information about disabling the database using the DGMGRL command-line interface

If the current status of the standby database is normal:

Verify the state of the standby database is APPLY-ON (not in the APPLY-OFF state).
Verify the state of the primary database is TRANSPORT-ON (not in the TRANSPORT-OFF state).

See Also:

Oracle Data Guard Broker Properties for additional information about the LogShipping database property
Verify the standby database is not in the snapshot role (logs are received but not applied until the standby is converted back to a physical standby).
Check to see if log files are building up because the value of the DelayMins property is set too large. (Log apply services will delay applying the archived redo log files on the standby database for the number of minutes specified.)

See Also:

Oracle Data Guard Broker Properties for additional information about the DelayMins database property
If you cannot see any errors, compare the redo generation rate to the apply rate to see if the apply rate is lower than the archive rate. The primary database redo generation rate is available in the SHOW DATABASE command output. Similarly, the standby's apply rate is available in the SHOW DATABASE output.

The Request Timed Out or Cloud Control Performance Is Sluggish

If the broker requests are not completing within the normal timeout parameters, try these actions to solve the problem.

Verify the network is operating appropriately.
Try to ping all of the nodes in the configuration.
Try reconnecting through another database to retry the operation.
Run the VERIFY command to determine on which database the broker is unable to process the requests.

The Primary Database is Flashed Back

If the primary database is flashed back, then the standby databases in the configuration must be also be flashed back or re-created to be viable targets for switchovers or failovers.

The broker will report errors for the standby databases if the primary database has been flashed back.

For more information about restoring the viability of a standby database that was disabled by the broker, see Reenabling Disabled Databases After a Role Change.

Standby Fails to Automatically Start Up Due to Unknown Service (ORA-12514)

An ORA-12514 error may be generated if the DGMGRL CLI fails to automatically start up an instance after a broker operation (for example, a switchover, reinstatement, or convert to physical standby).

The full error text is ORA-12514: Cannot connect to database. Service %s is not registered with the listener at %s. (CONNECTION_ID=%s). If you receive this error, and your database is not managed by Oracle Clusterware, then you must manually start the instance to complete or continue the broker operation.

Note:

The troubleshooting information in this section applicable only to databases that are not managed by Oracle Clusterware.

You can restart the instance before or after completing the following steps:

Issue the following DGMGRL CLI command to check the value of the StaticConnectIdentifer configurable property for the instance the DGMGRL CLI was unable to restart. (You will have to connect to another running instance to issue this command):
```
SHOW DATABASE db_unique_name StaticConnectIdentifier;
```
The static service name specified in the value of the StaticConnectIdentifer instance property should be registered with the listener specified in the property value. The default value for the static service name is of the following form:
```
<db_unique_name>_DGMGRL.<db_domain>
```
See Prerequisites for more information about this, and other prerequisites, for using the broker.
Confirm that the static service name is registered with the listener specified in the StaticConnectIdentifer configurable property value by using the Listener Control utility's status command.
```
lsnrctl status
```
The value of the StaticConnectIdentifer configurable property can be validated using the VALIDATE STATIC CONNECT IDENTIFIER command.