Oracle 12c R2 Error Codes and Solution Suggestions from ORA-16600 to ORA-16800
- ORA-16600: not connected to target standby database for failover
Cause: The failover command failed because the client was not connected to the target standby database.
Action: Explicitly connect to the standby database to be failed over to and retry the failover command.
Cause: An attempt was made to edit a member property while the member was enabled.
Action: Disable the member and retry the command.
Cause: The member was part of another Data Guard broker configuration. This could occur if the original configuration was re-created while this member was disconnected from the network or the same member was added to two different Data Guard broker configurations.
Action: Ensure that the member belongs to only one broker configuration. Shut down the broker by setting the DG_BROKER_START initialization parameter to ‘false’. Then, remove the Oracle Data Guard broker configuration files. Finally, restart the broker by setting the DG_BROKER_START initialization parameter to ‘true’.
Cause: The Oracle Data Guard broker was unable to access the configuration file specified by the DG_BROKER_CONFIG_FILE[1|2] initialization parameters.
Action: Verify space, permissions and file name as indicated by the DG_BROKER_CONFIG_FILE[1|2] initialization parameters.
Cause: The specified property did not exist.
Action: Specify a valid property name and reissue the command.
Cause: A failure was detected for one or more members in the Data Guard broker configuration.
Action: Locate the member or members with a failure status and correct it.
Cause: A warning was detected for one or more members in the Data Guard broker configuration.
Action: Locate the member or members with a warning status and correct it.
Cause: A command was attempted on a database that was being disabled. For example, attempting to reinstate the old primary database, the database that was the primary database prior to the most recent failover, before it was ready to be reinstated.
Action: Wait for the Oracle Data Guard broker to disable the database and then retry the command.
Cause: The specified broker command was already running and the command issued could not be completed.
Action: Wait for the specified command to finish and then retry the command.
Cause: The command was aborted at the user’s request.
Action: No action required.
Cause: The string value for the named attribute was too long.
Action: Specify a shorter string value.
Cause: A request was made that required access to the Oracle Data Guard broker configuration before the Oracle Data Guard broker had completed initialization.
Action: Wait until the Oracle Data Guard broker has completed initialization, then reissue the command.
Cause: An attempt to enable a member failed because the Oracle Data Guard broker configuration was disabled.
Action: Enable the Oracle Data Guard broker configuration and issue the DGMGRL CLI SHOW CONFIGURATION command to see if there are any members that are still disabled. If the member you tried to enable is still disabled, issue the DGMGRL CLI SHOW command to check the status of the member. If the member is a database whose status indicates that the database needs to be reinstated, then issue the DGMGRL CLI REINSTATE DATABASE command to reinstate and enable the database. If the member does not require reinstatement, then issue the DGMGRL CLI ENABLE command to enable the member.
Cause: Object identifier specified in the request was invalid or unknown.
Action: Verify that a valid object identifier is specified and reissue the command.
Cause: The condition specified for fast-start failover was already enabled.
Action: No action is required. Use the DGMGRL CLI SHOW FAST_START FAILOVER command to see the conditions that are enabled.
Cause: One or more members could not be reached for either a DGMGRL CLI REMOVE DATABASE, REMOVE FAR_SYNC or a REMOVE CONFIGURATION command.
Action: This typically indicates a network problem where the member is unable to respond to the primary database. If this is the case, examine the primary database Data Guard broker log file to determine which members could not be reached. For each mmeber not reached, connect to that member and shut down the broker by setting the DG_BROKER_START initialization parameter to ‘false’. After the broker has been shut down for the member, locate the Data Guard broker configuration files from the member’s DG_BROKER_CONFIG_FILE[1|2] initialization parameter values and delete them. Then restart the broker by setting DG_BROKER_START to ‘true’.
Cause: An attempt was made to add a member to the broker configuration that already included a member with the specified name. The member names must be unique.
Action: Verify that a unique name is specified for the new member to be added. Also, the member name must match the DB_UNIQUE_NAME initialization parameter of the member.
Cause: Multiple member objects referred to the same member.
Action: Examine the details of all members in the broker configuration and verify that two or more members are not referring to the same member. If two or more members in the broker configuration have the same value for the DGConnectIdentifier configurable property, either: – Remove and re-add the erroneously defined member or members to resolve the ambiguity. – Ensure that the DGConnectIdentifier configurable property for each member allows the broker to properly connect to that member.
Cause: A successful switchover or failover operation had been completed and was detected during member startup or broker health check. If this member was a database that was unavailable during a switchover or failover operation, it may not be a viable standby database for the new primary database and was disabled by the Oracle Data Guard broker.
Action: Connect to the new primary database and examine the broker configuration for databases that were disabled and that may require reinstatement or re-creation.
Cause: A network protocol version number mismatch was detected. This could happen if the members in the broker configuration were not running the same version of Oracle. The broker would disable members that were not running the same version of Oracle as the primary database if this situation was detected.
Action: Examine the version of Oracle installed on all members in the broker configuration to ensure they are identical. Once all of the members in the broker configuration are running the same version of Oracle, reenable the members that were disabled.
Cause: The command could not be executed because the member noted in the error text was not reachable from the member where the command was issued.
Action: See accompanying messages for more information. Check the network connections to the specified member. Alternatively, connect to a different member in the Oracle Data Guard broker configuration and retry the command.
Cause: This status was returned when attempting to enable a member that: – Could not locate itself in the broker configuration file. – Failed to distinguish itself from two or more members in the configuration file. – Determined it missed a role change within the configuration.
Action: To correct the problem, try one of these actions: – Confirm that the host and SID names for the member exactly match the values in the HOST_NAME and INSTANCE_NAME columns of the V$INSTANCE view. – Confirm that two or more members do not have the same connect identifier. That is, multiple members in the broker configuration should not reach the same member. – If a failover has been performed and the old primary database has been re-created (or a standby database has been re-created), ensure that the Oracle Data Guard broker configuration files have been removed for that database. Do not remove the configuration files that are in use by the new primary database.
Cause: This status was returned because of one of the following: – The broker rejected an attempt to change the overall configuration protection mode since it could not find any enabled members that supported the proposed protection mode, or could not find any enabled members that were synchronized. – The broker rejected an attempt to enable the configuration if it determined that there were no enabled members that supported the overall protection mode. – The broker rejected an attempt to disable or remove a member that, if disabled or deleted, would result in no remaining member that could support the overall configuration protection mode. – The broker rejected an attempt to switchover if doing so would violate the overall configuration protection mode. – Performing automatic health check if the broker determined that no members supported the overall protection mode.
Action: – If changing the overall protection mode, confirm that at least one member satisfies the new protection mode and is synchronized with the primary database. – For enable failures, confirm that at least one member receives redo data in a mode that supports the current overall protection mode. – For delete and disable failures, confirm that at least one other member receives redo data in a mode that suppports the the overall protection mode. – For switchover failures that occur when the configuration is operating in maximum protection or maximum availability mode, confirm that at least one other member receives redo data in synchronous mode. If the configuration contains a primary database and a single standby database and is operating in either maximum protection or maximum availability mode, ensure that the LogXptMode configurable property of the primary database is set to the value “SYNC”. Since the old primary database will become the standby database after switchover completes, its LogXptMode configurable property setting must support the configuration protection mode. – For a health check error, confirm that at least one member receives redo data in a mode that supports the current overall protection mode.
Cause: The Oracle Data Guard broker protection mode saved in the broker configuration file was inconsistent with the actual database setting.
Action: Reset the protection mode through the Oracle Data Guard broker.
Cause: The current database protection level was different from the configured protection mode. This typically was caused by redo transport problems, or the primary database was not open.
Action: Check the database alert log files and Data Guard broker log files for more details. Also, check the redo transport status. Ensure that one standby database supports the configured protection mode and that the network to that standby database is working properly. Ensure the primary database is open.
Cause: The property that was specified in the command was deprecated.
Action: Check the broker documentation to identify a replacement property or DGMGRL CLI command for the deprecated property.
Cause: The Oracle Data Guard broker operation required a shutdown of the database or instance.
Action: If database or instance has not been shutdown by the DGMGRL CLI or Enterprise Manager, shutdown the database or instance manually.
Cause: The Oracle Data Guard broker determined that an instance successfully found its member profile within the broker configuration file, but lacked an instance-specific profile. The broker automatically created an instance-specific profile and associated the instance with its database profile.
Action: No user action is required. The broker will automatically associate the instance with its member profile and incorporate the instance into broker activity.
Cause: The instance to be removed was the only instance of the corresponding member that was known to the broker.
Action: Remove the corresponding member from the broker configuration instead of the individual instance of the member.
Cause: The Oracle Data Guard broker detected a connection failure to a member in the broker configuration. This failure happened in the middle of a transmission session. A transmission session usually requires more than one send operation for sending a large amount of data (for example, the broker configuration file) to another member in the configuration.
Action: In most cases, no user action is required. The Oracle Data Guard broker always tries to resend the data. This error will be reported if the problem persists. This error indicates there are some problems with the network connection between broker managed members. Further network troubleshooting should be done to identify and correct the actual problem.
Cause: A STOP OBSERVER operation could not be completed when fast-start failover was enabled because the target standby database could not participate in the STOP OBSERVER operation.
Action: Additional information about this failure is recorded in the Data Guard broker log file for the primary database. This information helps to identify the reason why the target standby database was unable to participate in the STOP OBSERVER operation. If the problem can be corrected by the information in the broker log file, retry the operation. Alternatively, fast-start failover may be forcibly disabled by connecting to the primary database and issuing the DISABLE FAST_START FAILOVER FORCE command from the DGMGRL CLI. Once fast-start failover has been forcibly disabled, the observer can be stopped regardless of the current state of the target standby database.
Cause: The broker could not enable any more Oracle error numbers for initiating a fast-start failover.
Action: Use the DGMGRL CLI SHOW FAST_START FAILOVER command to help identify an Oracle error number that can be disabled before attempting to enable an additional error number for initiating a fast-start failover.
Cause: The broker could not determine whether the specified instance was running.
Action: See the next error message in the error stack for more detailed information. If the situation described in the next error in the stack can be corrected, do so; otherwise, contact Oracle Support Services.
Cause: An attempt was made to perform an operation on an instance that was not running or was unavailable.
Action: Ensure that the instance specified in the operation is running and then retry the operation.
Cause: The expected DB_UNIQUE_NAME value did not match the actual DB_UNIQUE_NAME value for the member that the broker contacted using the connect identifier that was associated with that member.
Action: Verify that the connect identifier correctly connects to the intended member. Verify that the name of the member the broker expects to find by that connect identifier matches the actual DB_UNIQUE_NAME for that member.
Cause: The Oracle Data Guard broker was unable to determine the location of its configuration files from the DG_BROKER_CONFIG_FILE[1|2] initialization parameters.
Action: Retry the operation and, if the error persists, contact Oracle Support Services.
Cause: The broker operation could not finish, because it requires a running apply instance for the standby database, and either there was no such instance designated for the standby database or the designated apply instance was not currently available.
Action: Start the designated apply instance or wait until the broker specifies an instance to be the apply instance and reissue the command.
Cause: The startup of an instance that is not part of the broker configuration prevented the operation from completing.
Action: Reissue the operation after the new instance has joined the Data Guard configuration.
Cause: The operation was not allowed because fast-start failover was disabled.
Action: Enable fast-start failover and retry the operation.
Cause: The observer could not start because there were three observers already observing the Oracle Data Guard configuration for which fast-start failover may have been enabled.
Action: Stop one of the existing observers and retry the command.
Cause: The observer was registered with the Oracle Data Guard broker and will begin observing the Oracle Data Guard configuration for conditions that warrant doing a fast-start failover.
Action: None
Cause: An attempt to open the primary database was made either after a failover occurred, or when it was likely to have occurred as the result of the primary being isolated from the fast-start failover target standby database and from the fast-start failover observer.
Action: Check if a failover did occur. If fast-start failover is enabled, and a failover did not occur, ensure that connectivity exists between the primary database and either the observer or the target standby database. Then, try opening the database again.
Cause: An unrecognized database or far sync instance was specified in the command.
Action: Try the command again using a valid object name. Use the SHOW CONFIGURATION command to identify the members in the configuration.
Cause: An upgrade to maximum protection mode was attempted when the current protection mode was maximum performance mode.
Action: To upgrade the protection mode to maximum protection mode, first upgrade the protection mode to maximum availability mode, then upgrade the protection mode to maximum protection mode.
Cause: The command to enable or disable fast-start failover could not be completed because Data Guard broker management of the fast-start failover target standby database is currently disabled.
Action: Enable broker management of the target standby database and reissue the command. If an attempt was made to disable fast-start failover when this error was reported, disable fast-start failover forcibly using the DGMGRL DISABLE FAST_START FAILOVER FORCE command. Consult the documentation for more information.
Cause: The Oracle Data Guard broker failed to reinstate the specified database because the reinstatement could not be completed or the database was already enabled.
Action: Additional information about this failure is recorded in the primary database or the specified database Data Guard broker log files. This information is helpful in determining how to proceed.
Cause: The attempted command was not allowed while fast-start failover was enabled: – The FastStartFailoverTarget property may not be modified. – The LogXptMode property for either the primary database or the fast-start failover target standby database may not be modified. – The configuration’s protection mode may not be modified. – Neither the broker configuration nor the fast-start failover target standby database may be disabled using the DGMGRL CLI DISABLE command. – Neither the broker configuration nor the fast-start failover target standby database may be removed using the DGMGRL CLI REMOVE command. – The FAILOVER IMMEDIATE command is not allowed. – The DG_BROKER_START initialization parameter may not be set to FALSE.
Action: Disable fast-start failover, using the FORCE option if required. Then retry the attempted command.
Cause: The attempted command was not allowed because fast-start failover was enabled for this Data Guard broker configuration and the standby database specified in the command was not the current fast-start failover target standby associated with the current primary database.
Action: Retry the attempted command by specifying the current fast-start failover target standby database. Alternatively, disable fast-start failover and retry the command using the originally specified target standby database.
Cause: The Oracle Data Guard broker detected a role change during database startup or health check.
Action: Additional information about this failure is recorded in the Oracle Data Guard broker log files, one for the primary database and one for each standby database in the Oracle Data Guard configuration. This information is helpful in determining how best to proceed from this failure.
Cause: Reinstatement of this database was in progress.
Action: None
Cause: The fast-start failover configuration was currently unobserved therefore failover was disallowed.
Action: Ensure that the observer is running and has connectivity to both the primary and the target standby databases. Otherwise, disable fast-start failover to perform a failover in the absence of the observer process.
Cause: A primary database that restarted contacted a standby database that is being failed over to.
Action: Shut down the primary database and wait for failover to complete on the standby database. Once failover is complete, restart the old primary database. If the failover occurred due to fast-start failover, restarting the primary database after failover is complete allows it to be automatically reinstated as a standby database to the new primary database.
Cause: An attempt was made to enable or disable fast-start failover when connected to a standby database for which broker configuration details are currently unavailable. For instance, the standby database may currently require re-creation (or flashback reinstantiation) before it may respond to broker client commands.
Action: 1) An attempt to enable or disable (non-FORCE) fast-start failover at this standby database will be rejected until such time that the broker configuration details have been made available to that standby database from the primary database. This normally occurs when the standby database is successfully re-created or flashed back, and then reenabled at the primary database. 2) Use the FORCE option to override fast-start failover that has been enabled at the standby database even when the broker configuration details are currently unavailable to the standby database. In this case, this status message is only a warning. Note that fast-start failover is not formally disabled in the broker configuration. The effect of this command issued under these circumstances may or may not be permanent, depending upon when the primary and standby databases regain full communication between each other and if the state of fast-start failover has been altered at the primary database in the meantime.
Cause: A role change has caused this database to require reinstatement.
Action: Use the DGMGRL REINSTATE DATABASE command or Enterprise Manager to reinstate the database. Reinstate the database as soon as possible, because the database will have to be re-created if another role change occurs while it is in this state.
Cause: In response to the issued command, the Oracle Data Guard broker attempted to contact a member in the Oracle Data Guard configuration. That attempt failed because there was no response from that member after the period of time specified by the CommunicationTimeout configuration property.
Action: Check the Oracle Data Guard broker log file for the details of the failure. Fix the problem and try the command again.
Cause: During execution of a command, a member in the Oracle Data Guard broker configuration failed to return a result.
Action: Check Oracle Data Guard broker log files for the details of the failure. Ensure network communication is working properly amongst the members of the configuration. Fix any possible network problems and reissue the command.
Cause: The Oracle Data Guard broker was forced to time out a network connection to a remote member because: – The network call to the remote member did not complete in a timely manner. – The remote member was unable to execute the command due to an instance failure.
Action: Check Data Guard broker log files for the details of the failure. If the network call did not complete in a timely manner, increase the CommunicationTimeout configuration property value and reissue the command.
Cause: The request to initiate a fast-start failover using DBMS_DG.INITIATE_FS_FAILOVER was made on a bystander standby database. DBMS_DG.INITIATE_FS_FAILOVER can only be called on either the primary or fast-start failover target standby database.
Action: Call DBMS_DG.INITIATE_FS_FAILOVER on either the primary or fast-start failover target standby database.
Cause: The Oracle Data Guard broker operation required the same command be issued again from the client.
Action: If DGMGRL or Enterprise Manager has not already done so, reissue the same command to the Oracle Data Guard broker manually.
Cause: The database specified for the operation was the fast-start failover target standby database.
Action: Retry the operation on a different database. Alternatively, disable fast-start failover and retry the operation.
Cause: An attempt was made to set an instance-specific property to the same value for all instances of an Oracle RAC database for a property whose value must be unique for each instance.
Action: Use the EDIT INSTANCE command and specify the SID of each instance whose instance-specific property value is to be changed.
Cause: Switchover was attempted to a standby database that has a non-zero value for its DelayMins configurable property.
Action: Set the DelayMins configurable property to zero for the standby database to switchover to, wait for its apply lag to become zero seconds, and then retry the switchover command.
Cause: The standby member was running a different version of Oracle than the primary database.
Action: Ensure that all members of the configuration are running the same versions of Oracle.
Cause: An attempt to enable a database whose standby type changed from physical or snapshot to logical (or vice versa) was disallowed.
Action: If the intention is to retain the database conversion to the new type, the database must be removed and re-added to the configuration in order to obtain correct values for database properties specific to the new standby type.
Cause: One or more properties that correspond to static initialization parameters were modified, but the database instances were not restarted. Or, a static initialization parameter that corresponds to a broker property was modified using an ALTER SYSTEM SQL*Plus statement.
Action: Restart the database instances for the modified property values to take effect. If the error persists after having restarted the instance, use the DGMGRL CLI or Enterprise Manager to modify the property the static initialization parameter corresponds to.
Cause: The value of a RedoRoutes property for two or more members was set such that a member that sends redo also receives redo data data in the same route. For example, A sends to B, B sends to C, and C sends to A.
Action: Correct the setting of the RedoRoutes propety on one or more members to eliminate the circular route.
- ORA-16677: Standby database has the same or higher priority than other members specified in the RedoRoutes group.
Cause: A standby database with the same or higher priority than other members in the group was specified in the RedoRoutes property.
Action: Check the Oracle Data Guard broker log file for the reason for the failure and reissue the command. Ensure that a standby database was not specified to have the same or higher priority than other members in the group for the RedoRoutes property.
Cause: The specified value contained an unrecognized or duplicated attribute.
Action: Ensure the property string does not contain any undefined or duplicate attributes. See the Oracle Data Guard broker documentation for supported attributes.
Cause: The specified value contained one or more illegal keywords.
Action: See the Oracle Data Guard broker documentation for the supported keywords.
Cause: The specified value contained an unbalanced set of parentheses or a missing set of parentheses.
Action: Ensure the parentheses are correctly matched and specify parentheses when required. See the Oracle Data Guard broker documentation for more information.
Cause: The specified value did not contain a colon (:).
Action: Include the colon (:) in the value.
Cause: The specified value contained the same database or far sync instance multiple times.
Action: Ensure that a database or far sync instance is specified only once.
Cause: The value specified contained an illegal, empty string or substring, e.g. “()”.
Action: Remove the illegal empty strings and retry the command.
Cause: The value specified for the RedoRoutes property contained more than the 30 destinations.
Action: Ensure that no more than 30 destinations are specified.
Cause: The RedoRoutes property for all members of the configuration were set such that this database did not receive redo data. Or, the transport state of the database that sends redo data to this database is not valid.
Action: Check the setting of the RedoRoutes property for all members of the configuration. Ensure that at least one member’s RedoRoutes property value is set to ship redo data to this database. Also check the transport state of the database that sends redo data to this database.
Cause: This database may not receive redo data if the redo source is an alternate destination that does not ship redo to this database.
Action: Ensure that any alternates for the redo source for this database includes this database in its send to list.
Cause: Using the RedoRoutes properties, multiple redo sources were shipping redo to the standby.
Action: Using the RedoRoutes properties, ensure that only one redo source ships redo to the standby.
Cause: The command was issued on a member that was disabled.
Action: Connect to an enabled member of the configuration and retry the command.
Cause: A far sync instance or a recovery appliance was specified as the redo source in a RedoRoutes property rule.
Action: Check the setting of the RedoRoutes property and confirm that a far sync instance or a recovery appliance is not specified as the redo source in the RedoRoutes property rule.
Cause: A specified destination in a RedoRoutes rule either appears in the primary setting of the same rule or is the local database itself.
Action: Ensure that any specfifed destination in a RedoRoutes rule neither appears in the primary setting of the same rule nor be the local database itself.
Cause: An attempt was made to remove a database or far sync instance that is specified in another configuration member’s RedoRoutes property.
Action: First remove the database or far sync instance from all other member’s RedoRoutes property values. Then retry the remove command.
Cause: An attempt was made to delete, disable, or convert (physical standby database) a member that has a non-empty value set for its RedoRoutes property.
Action: Reset the value of the RedoRoutes property for the member to be deleted, disabled, or converted (physical standby database) to the empty string and then retry the operation.
Cause: The attempt to enable fast-start failover could not be completed because one or more requirements were not met: – The Oracle Data Guard configuration must be in either MaxAvailability or MaxPerformance protection mode. – The effective redo transport mode for both the primary database and the fast-start failover target standby database must be set to either SYNC or FASTSYNC if the configuration protection mode is set to MaxAvailability mode. – The effective redo transport mode for both the primary database and the fast-start failover target standby database must be set to ASYNC if the configuration protection mode is set to MaxPerformance mode. – No valid target standby database was specified in the primary database FastStartFailoverTarget property prior to the attempt to enable fast-start failover, and more than one standby database exists in the Oracle Data Guard configuration. – fast-start failover target standby database did not receive redo data directly from the primary database when the protection mode was set to maximum performance mode. – The primary database has multiple routes to the fast-start failover target standby database.
Action: Retry the command after correcting the issue: – Set the Oracle Data Guard configuration to either MaxAvailability or MaxPerformance protection mode. – Ensure that the effective redo transport mode for both the primary database and the fast-start failover target standby database are either SYNC or FASTSYNC if the configuration protection mode is set to MaxAvailability. – Ensure that the LogXptMode property for both the primary database and the fast-start failover target standby database are set to ASYNC if the configuration protection mode is set to MaxPerformance. – Set the primary database FastStartFailoverTarget property to the DB_UNIQUE_NAME value of the desired target standby database and set the desired target standby database FastStartFailoverTarget property to the DB_UNIQUE_NAME value of the primary database. – Ensure the RedoRoutes property of the primary includes the name of the fast-start failover target standby database when the protection mode is set to maximum performance mode. – Ensure the RedoRoutes property of the primary database has only one route to the fast-start failover target standby database.
Cause: An error occurred during the restart of either the old and the new primary databases or both in a switchover operation.
Action: Manually restart both the old and new primary databases, including all their Oracle RAC instances if it is an Oracle RAC database.
Cause: The member could not receive redo data from another standby database or a far sync instance because either a RedoRoutes rule for that standby or far sync instance did not specify asynchronous redo transport mode or the LogXptMode property of the receiving member was not set to asynchronous redo transport mode.
Action: A standby database or far sync instance can only send redo data in asynchronous mode. Set the LogXptMode for the receiving member to ASYNC before changing the RedoRoutes of the standby database or far sync instance that is to send redo data. Or, specify ASYNC in the RedoRoutes property of either the sending standby database or far sync instance to override the value specified in the LogXptMode property of the receiving member.
Cause: An attempt was made to enable a member whose redo source was disabled.
Action: Enable the redo source first and then retry the command.
Cause: A logical standby database or snapshot standby database was specified to send redo data.
Action: Check the setting of the RedoRoutes property and confirm that a primary database, physical standby database, or far sync instance is specified to send the redo data.
Cause: One or more LOG_ARCHIVE_DEST_n initialization parameters that contain a SERVICE attribute for another member in the configuration were set on the new member when attempting to add a standby database or far sync instance to the configuration.
Action: Clear all LOG_ARCHIVE_DEST_n initialization parameters that contain a SERVICE attribute for another member in the configuration on the new member to be added.
Cause: The connect identifier was not specified for the DGMGRL CLI ADD command.
Action: Retry the ADD command with a connect identifier for the object to be added.
Cause: The primary database may have been flashed back or restored from a backup set and then reopened with the RESETLOGS option.
Action: Re-create the standby database from the primary database or flash back the standby database to the same point the primary database had been flashed back to.
Cause: The command to modify or query the member failed.
Action: Check the Oracle Data Guard broker log file for the reason for the failure and reissue the command.
Cause: The command to modify or query the member resulted in a warning.
Action: Check the Oracle Data Guard broker log file for the warning and, if necessary, reissue the command.
Cause: An attempt was made to change a member property while the member was enabled.
Action: Disable the member first, update the property, and then reenable the member.
Cause: The standby database was not added to the Oracle Data Guard broker configuration because it was not a valid standby database for the primary database.
Action: Add a database to the Oracle Data Guard broker configuration that is a valid standby database to the primary database.
Cause: The Oracle Data Guard broker worker process was not available to service the request.
Action: Contact Oracle Support Services.
Cause: An invalid property value was specified while broker management of the member was disabled.
Action: Reset the property to a valid value.
Cause: The state name specified was invalid for the database.
Action: Check the state name and reissue the command.
Cause: The StandbyArchiveLocation or AlternateLocation property was set to USE_DB_RECOVERY_FILE_DEST, but the initialization parameter DB_RECOVERY_FILE_DEST did not specify a valid destination.
Action: Use a value other than USE_DB_RECOVERY_FILE_DEST for StandbyArchiveLocation or AlternateLocation, or set up a valid database recovery area by setting DB_RECOVERY_FILE_DEST to a valid destination.
- ORA-16710: snapshot standby database should be converted back to a physical standby database as soon as possible
Cause: A failover causes this snapshot standby database to enter a state that requires it to be re-created if another failover occurs before it is converted back to a physical standby database.
Action: Reenable the snapshot standby database if it is disabled and convert it back to a physical standby database as soon as possible because the snapshot standby database will have to be re-created if another failover occurs while it is in this state.
Cause: The Oracle Data Guard broker timed out the command.
Action: Verify that the command is valid for the member and then retry the command.
Cause: The value of the specified configuration property was inconsistent with member’s in-memory settings or server parameter file settings. This may be caused by changing an initialization parameter that corresponds to a configuration property.
Action: Query the InconsistentProperties property on the member to determine the which properties are set inconsistently and set the properties to make them consisent.
Cause: The value of the specified redo transport-related configuration property of the given member was inconsistent with the primary database redo transport service setting. This may be caused by changing an initialization parameter that corresponds to a configuration property.
Action: Query the InconsistentLogXptProps property on the primary database to determine which redo transport properties are set inconsistently. Reset the properties on the member to make them consistent with the primary database redo transport settings.
Cause: An attempt to clear the LOG_ARCHIVE_DEST parameter failed.
Action: Contact Oracle Support Services.
Cause: An attempt to clear the LOG_ARCHIVE_DUPLEX_DEST parameter failed.
Action: Contact Oracle Support Services.
Cause: The Oracle Data Guard broker was unable to locate the member in the broker configuration.
Action: Add the member to the broker configuration and then reissue the command.
Cause: The broker failed to query the V$ARCHIVE_DEST fixed view.”
Action: Test and clear the problem using SQL*Plus.
Cause: All LOG_ARCHIVE_DEST_n initialization parameters were in use, or all initialization parameters from LOG_ARCHIVE_DEST_1 through LOG_ARCHIVE_DEST_10 that can support SYNC were in use.
Action: Clear one or more LOG_ARCHIVE_DEST_n initialization parameters so that Data Guard broker can use them to set up the primary database redo transport.
Cause: The broker was unable to set one or more LOG_ARCHIVE_DEST_n initialization parameters.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log files for more details.
Cause: The broker was unable to set one or more LOG_ARCHIVE_DEST_STATE_n initialization parameters.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log files for more details.
Cause: The standby database was not using standby redo logs, and the redo transport service to the standby database is set to a nonzero value for the ReopenSecs property and a value of zero for the MaxFailure property. In this case, the redo transport service will attempt to send redo data to the standby database indefinitely and never switch to the alternate destination.
Action: Any one of the following actions will solve the problem: – add standby redo logs to the standby database. – set ReopenSecs property to zero. – set MaxFailure property to a nonzero value. After performing one of the above actions, reset the standby database AlternateLocation property.
Cause: The primary database could not resolve a gap request from one or more members.
Action: To see which member has an unresolvable gap, check the status of the primary database using either Enterprise Manager or the DGMGRL CLI SHOW DATABASE command. Copy the missing archived log files from either backups or from another member in the configuration that has the files for the member that is missing the files.
Cause: The Oracle Data Guard broker could not close the database.
Action: Terminate any active sessions connected to the database and then reissue the command.
Cause: The consistency check for the specified property failed due to the error shown.
Action: Check the error message and clear the error.
Cause: The property value validation failed due to the error shown.
Action: Check the error message and clear the error.
Cause: SQL Apply was not started because there were no pluggable databases opened in read/write mode.
Action: Open at least one pluggable database in read/write mode. Data Guard will then automatically start SQL Apply.
Cause: The operation failed because there were no pluggable databases opened in read/write mode.
Action: Open at least one pluggable database in read/write mode and retry the command.
Cause: The Oracle Data Guard broker operation required this database instance to be shut down and restarted.
Action: If Oracle Clusterware has not already done so, shut down the Oracle instance and then restart it.
Cause: Redo generation on the primary database was suspended because either the fast-start failover target was unavailable or the network connection between both databases was disrupted.
Action: Ensure that the fast-start failover target standby database is running and the network connection between both databases is restored.
Cause: Either the destination was manually changed or deleted out of Oracle Data Guard broker, or no entry was available for the Oracle Data Guard broker to use.
Action: Clean up the destination setting, remove the unused settings, and reset the redo transport service.
Cause: A communication problem with the member caused the redo transport to fail.
Action: Query the LogXptStatus property to see the error message. Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The redo transport service for the specified member was not running.
Action: Check the Oracle Data Guard broker log file or the Oracle alert log file for more details. If necessary, start the redo transport service for the member.
Cause: The redo transport service for the member was running.
Action: Check the Oracle Data Guard broker log file for more details. If necessary, stop the redo transport service for the member.
Cause: The redo transport service to the member was set to ALTERNATE when no other destination was set to alternate to this destination.
Action: Reenable the member or the entire configuration to allow the configuration property settings to be propagated to the initialization parameters.
Cause: The destination defined in the server parameter file of the primary database had incorrect syntax and Data Guard broker failed to update the destination when redo transport services were enabled.
Action: Fix the syntax error in the primary database server parameter file or remove the entry from the server parameter file. Also, check the values of the redo transport-related properties for the specified member.
Cause: The member exhausted its quota for storing archived redo logs.
Action: Remove some archived redo logs from the member or increase its quota.
Cause: The status of redo transport to the specified member could not be determined.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The DG_CONFIG list of the LOG_ARCHIVE_CONFIG attribute was full and the Oracle Data Guard broker was not able to add a new DB_UNIQUE_NAME to the list.
Action: Remove some unused entries in the DG_CONFIG list, then reenable the member.
Cause: The DG_CONFIG list of the LOG_ARCHIVE_CONFIG attribute was full and the Oracle Data Guard broker was not able to add the specified DB_UNIQUE_NAME to the list.
Action: Remove some unused entries in the DG_CONFIG list then reenable the member.
Cause: The Oracle Data Guard broker failed to mount the database.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The Oracle Data Guard broker could not turn on the logical standby database guard.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The Oracle Data Guard broker failed to open the primary database.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The Oracle Data Guard broker failed to switch a logical standby database over to a primary database.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The Oracle Data Guard broker failed to activate a logical standby database.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The Oracle Data Guard broker failed to switch a physical standby database over to a primary database.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The Oracle Data Guard broker failed to open the standby database.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The Oracle Data Guard broker failed to activate the physical standby database.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The Oracle Data Guard broker failed to set an initialization parameter using either the ALTER SYSTEM SET or ALTER SYSTEM RESET command.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The Oracle Data Guard broker failed to get the value for the specified property because the value for the specified property is not available for the current database role.
Action: If the value of the specified property is not available for the current role of the database, specify this property for a database for which the value is available. Otherwise, check the Oracle Data Guard broker log file for more details.
Cause: The Oracle Data Guard broker could not start apply services on the specified instance because that instance was not running.
Action: Start the instance and then retry the command.
Cause: The Oracle Data Guard broker failed to start SQL Apply with an initial system change number (SCN).
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The Oracle Data Guard broker failed to start SQL Apply.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The Oracle Data Guard broker failed to stop SQL Apply.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: Database was not in the intended state.
Action: Determine the reason why the database is not running in the intended state and reissue the command.
Cause: The redo transport service for a member was running.
Action: For more details, check the status of the primary database using either Oracle Enterprise Manager or the DGMGRL CLI SHOW DATABASE command. If necessary, stop the redo transport service to the member.
Cause: The redo transport service to a member was not running.
Action: For more details, check the status of the primary database using either Oracle Enterprise Manager or the DGMGRL CLI SHOW DATABASE command. If necessary, start the redo transport service to the member.
Cause: Redo Apply was running when it should have been stopped.
Action: If necessary, stop Redo Apply.
Cause: Redo Apply was stopped when it should have been running.
Action: Check the alert log to see why Redo Apply terminated, correct any problems that may exist, and restart Redo Apply by setting the physical standby database state to APPLY-ON.
Cause: SQL Apply was running when it should have been stopped.”
Action: If necessary, stop SQL Apply.
Cause: SQL Apply was stopped when it should have been running.”
Action: Check the alert log to see why SQL Apply terminated, correct any problems that may exist, and restart SQL Apply by setting the logical standby database state to APPLY-ON.
Cause: All instances in the physical standby database were put into a read-only state instead of APPLY-OFF.
Action: Issue the EDIT DATABASE SET STATE command to set the database to the APPLY-OFF state.
Cause: Redo Apply services could not be started on the physical standby database because it was being opened. The Oracle Data Guard broker will start Redo Apply services once the physical standby database has been opened.
Action: No action required.
Cause: The Oracle Data Guard broker encountered errors when converting a physical standby database to a primary database.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The Oracle Data Guard broker encountered errors when switching over to the specified standby database.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The Oracle Data Guard broker failed to start Redo Apply.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details. If the database is already open, the broker will not start Redo Apply if the Oracle Active Data Guard option is not enabled.
Cause: The Oracle Data Guard broker failed to stop Redo Apply.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The target standby database specified for the broker operation did not have all the redo data from the primary database.
Action: Confirm that the redo transport service on the primary database is functioning correctly by checking its status using either Enterprise Manager or the DGMGRL CLI SHOW DATABASE command. Reissue the broker command once all redo data is available on the target standby database.
Cause: The Oracle Data Guard broker could not complete the health check for the redo transport service.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: Either a destination was manually deleted or no entry was available for Oracle Data Guard.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details. The redo transport service may need to be reset.
Cause: The redo transport service was unable to send redo data to one or more members.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details. Query the LogXptStatus property to see the errors.
Cause: The destination was defined in the LOG_ARCHIVE_DEST_n server parameter file with incorrect syntax. The Oracle Data Guard broker failed to update the destination when the redo transport was turned on.
Action: Check the Oracle Data Guard broker log file to see which member has the problem. Fix the syntax error in the server parameter file or remove the entry from the server parameter file. Check if the syntax of the redo transport-related properties is correct.
Cause: A member has exhausted its quota for storing archived redo logs.
Action: Check the Oracle Data Guard broker log file to see which member has the problem. Remove some archived redo logs or increase the quota on the storage the member is using for archived redo logs.
Cause: The status of redo transport to the specified member could not be determined.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log file for more details.
Cause: The database was mounted on an instance but not opened for read and write access.
Action: For more details, check the status of the database using either Enterprise Manager or the DGMGRL CLI SHOW DATABASE command. If possible, open the instance manually.
Cause: The primary database could not resolve a gap request from the specified member or members.
Action: Copy the missing archived redo log files from either backups or from another member in the configuration that has the files for the member or members missing the files.
Cause: The member name that should be the value of the DB_UNIQUE_NAME initialization parameter specified in the Dependency property was incorrect.
Action: Reset the Dependency property to the correct name of the member.
Cause: The database was in NOARCHIVELOG mode when it was either a primary database or when it was a standby database that was being switched over to be a primary database.
Action: Set the database to ARCHIVELOG mode by issuing the ALTER DATABASE ARCHIVELOG command.
Cause: The Oracle Data Guard broker configuration files did not exist or or could not be accessed.
Action: Check the Oracle Data Guard broker log file for more details.
Cause: This situation occurred when the broker attempted to set member configurable property values into the member by issuing ALTER SYSTEM or ALTER DATABASE commands. Typical causes of this error are: – The values of redo transport-related properties contain syntax syntax errors. – The value of the LogArchiveTrace property was out of range.
Action: Check the Oracle Data Guard broker log file to see which property has the problem and set the property to the correct value.
Cause: Standby redo logs were not configured or were configured incorrectly for the member.
Action: Standby redo logs are required when the redo transport mode is set to SYNC or ASYNC. Check the Oracle Data Guard documentation to find more information about the correct configuration of standby redo logs.
Cause: An invalid property value was entered, or a RESET was attempted on a property for which no Broker default value exists.
Action: Set the property to a correct value.
Cause: The member may not be mounted, or the query of the V$STANDBY_LOG fixed view failed.
Action: Ensure the member is mounted and query the V$STANDBY_LOG fixed view to see if the problem has been corrected, and retry the operation.
Cause: The values of one or more configurable properties were inconsistent with the in-memory settings or server parameter file settings. This may happen by directly altering initialization parameters instead of editing configurable property values using Oracle Data Guard broker.
Action: Query the InconsistentProperties property on the member or check the Oracle Data Guard broker log file to find which properties are set inconsistently. Reset these properties to make them consistent with the database settings. Alternatively, enable the member or the entire configuration to allow the configurable property settings to be propagated to the initialization parameters.
Cause: The logical standby database guard was turned off.
Action: Issue the ALTER DATABASE GUARD ALL command to turn the guard on and verify that Data Guard health check error or warning is cleared.
Cause: The database guard was turned on for the primary database.
Action: Issue the ALTER DATABASE GUARD NONE command to turn off the guard and verify that Data Guard health check error or warning is cleared.
Cause: A switchover or failover operation caused this database to require re-creation. The database was marked for re-creation because it was not a viable standby database for the new primary database. Until this error status is resolved for this database, information about this database and the broker configuration to which it belongs is unavailable to a broker client that is connected to this database. Therefore, all commands directed by that client to this database cannot be completed.
Action: Re-create (or flash back) the standby database. Connect to the primary database in the broker configuration and reenable broker management of that database. Once enabled, it is possible to connect to that standby database and manage it with the broker. Alternatively, many client commands that cannot be completed at the standby database when in this error state can be completed successfully when issued to the primary database. In this case, simply reconnect to the primary database and retry the command.
Cause: The broker was unable to import property values for the member being added to the broker configuration. This error indicates: – The Oracle Net service name specified in DGMGRL CREATE CONFIGURATION, ADD DATABASE, ADD FAR_SYNC, or ADD RECOVERY_APPLIANCE command was not one that provides access to the member being added. – There were no instances running for the member being added.
Action: Remove the member from the configuration using the REMOVE CONFIGURATION, REMOVE DATABASE, REMOVE FAR_SYNC, or REMOVE RECOVERY_APPLIANCE command. Ensure that the member to be added has at least one instance running and that the Oracle Net service name provides access to the running instance. Also, check the broker log file for additional information. Then, reissue the CREATE CONFIGURATION, ADD DATABASE, ADD FAR_SYNC, or ADD RECOVERY_APPLIANCE command.
Cause: The member was not using a server parameter file or the broker was unable to access the server parameter file.
Action: Issue the CREATE SPFILE=’..’ FROM PFILE=’…’ command to create a server parameter file and then restart the member to use it.
Cause: The physical standby database could not complete recovery during failover.
Action: Check the Oracle Data Guard broker log file and the Oracle alert log files to see more details on the reason for the failure.
Cause: Either the Oracle Data Guard broker configuration indicated that Redo Apply was turned off, or the MRP0 recovery process was not running. As a result, Redo Apply-related properties could not be set.
Action: Turn on Redo Apply through Oracle Data Guard broker and reissue the command to set a Redo Apply-related property.
Cause: The redo transport service for a standby database was set to ALTERNATE when no other destination is set to alternate to this destination.
Action: Reenable the standby database or the entire configuration to allow the configuration property settings to be propagated to the initialization parameters.