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.

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.

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

• 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 archive rate to the apply rate on the Performance page in Cloud Control to see if the apply rate is lower than the archive rate.

1. Verify the network is operating appropriately.

2. Try to ping all of the nodes in the configuration.

3. Try reconnecting through another database to retry the operation.

4. Run the VERIFY command to determine on which database the broker is unable to process the requests.

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.

The full error text is ORA-12514: TNS:listener does not currently know of service requested in connect descriptor. 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.

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

1. 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;

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

3. 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. If the static service name is properly registered with the listener, it will be included in the output generated by the following command:

   lsnrctl status
   

1. Examine the alert log file and the broker log file (drc*.log) on the target standby database to determine the cause of the failure and correct the problem.

2. Connect to the target standby database and disable fast-start failover using the FORCE option if it is enabled.

3. Retry the broker failover.

4. Reinstate the old primary database. All bystander standby databases will be re-created from a copy of the new primary database.

5. Reenable fast-start failover if it was disabled in step 1.

If broker failover continues to fail, you should stop the broker on all databases in the Oracle Data Guard configuration (set the DG_BROKER_START initialization parameter to FALSE). Remove the Oracle Data Guard broker configuration files from all databases. Attempt a manual failover using the guidelines for role transitions in Oracle Data Guard Concepts and Administration.

In this case, you may have to move the observer to a new host if the original host machine cannot be repaired in a timely fashion.

1. Issue the DGMGRL STOP OBSERVER command to sever the link between the original observer and the broker configuration:

   DGMGRL> STOP OBSERVER;
   Done.
   

2. Issue the DGMGRL SHOW CONFIGURATION VERBOSE command to verify that the configuration is no longer being observed:

   DGMGRL> SHOW CONFIGURATION VERBOSE;
    
   Configuration - DRSolution
    
     Protection Mode: MaxAvailability
     Members:
       North_Sales - Primary database
       Warning: ORA-16819: fast-start failover observer not started
    
       South_Sales - (*) Physical standby database
       Warning: ORA-16819: fast-start failover observer not started
    
   (*) Fast-Start Failover target
    
   Properties:
     FastStartFailoverThreshold     = '30'
     OperationTimeout               = '30'
     TraceLevel                     = 'USER'
     FastStartFailoverLagLimit      = '30'
     CommunicationTimeout           = '180'
     ObserverReconnect              = '0'
     FastStartFailoverAutoReinstate = 'TRUE'
     FastStartFailoverPmyShutdown   = 'TRUE'
     BystandersFollowRoleChange     = 'ALL'
     ObserverOverride               = 'FALSE'
     ExternalDestination1           = ''
     ExternalDestination2           = ''  
     PrimaryLostWriteAction         = 'CONTINUE'
     ConfigurationWideService       = 'North_Sales_CFG' 
   
   Fast-Start Failover: ENABLED
    
     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
    
   Configuration Status:
   WARNING
   

3. Note that you do not need to issue the DGMGRL SHOW CONFIGURATION command to verify that the observer has actually stopped. Successful completion of the DGMGRL STOP OBSERVER command will allow a new observer to become associated with the configuration.

For example:

% dgmgrl START OBSERVER observer1 IN BACKGROUND LOGFILE IS observer.log CONNECT IDENTIFIER IS North_Sales TRACE_LEVEL IS SUPPORT;

All the observer output is then recorded in a file named observer.log in the current working directory where you issued the DGMGRL command. If the specified log file is not accessible, then the observer output is sent to standard output as though a log file had not been specified.