- The string operands(other than an nlsparams argument) to an operator or built-in function do not have the same character set.
- An nlsparams operand is not in the database character set.
- String data with character set other than the database character set is passed to a built-in function not expecting it.
- The second argument to CHR() or CSCONVERT() is not CHAR_CS or NCHAR_CS.
- A string expression in the VALUES clause of an INSERT statement, or the SET clause of an UPDATE statement, does not have the same character set as the column into which the value would be inserted.
- A value provided in a DEFAULT clause when creating a table does not have the same character set as declared for the column.
- An argument to a PL/SQL function does not conform to the character set requirements of the corresponding parameter.
- it is a typed table
- it is a temporary table
- it contains ADT columns
- it contains nested-table columns
- it contains REF columns
- it contains array columns
- it is an index-organized table
- it contains LOB columns
- it is a nested table
- it is created with row dependency and the partitioned table is not
- it is created without row dependency and the partitioned table is
- both the HOT and the COLD keywords
- both the MIRRORHOT and the MIRRORCOLD keywords
- the HOT keyword more than once
- the COLD keyword more than once
- the MIRRORHOT keyword more than once
- the MIRRORCOLD keyword more than once
2. ALTER DATABASE START LOGICAL STANDBY APPLY;
3. Examine the current_scn column in the DBA_LOGSTDBY_EVENTS view to determine which log file contains the unsupported record.
4. Provide the log file to Oracle Support Services.
- The databases changing roles are shut down.
- The primary database is not shipping redo data.
- The standby database that will become the primary database is not applying redo data. If this error was returned for database state change operations, the database state specified was invalid.
- The databases changing roles are started.
- The primary database is shipping redo data.
- The standby database is applying redo data. If this error is returned when attempting a database state change operation, make sure a valid database state is specified.
- A failover operation was submitted or was in progress.
- A switchover operation was submitted or was in progress.
- An instance restart was pending for one or more databases.
- An attempt was made to alter the DG_BROKER_CONFIG_FILE[1|2] initialization parameters while the broker was running.
- Non-broker access (such as DBMS_FILE_TRANSFER) to the configuration files was attempted. See the alert log for additional information.
- the broker detects an inconsistency in the block count of configuration file when the file is transmitted between databases.
- the broker encountered an error when writing the configuration file.
- Remove and re-add the erroneously defined database(s) to resolve the ambiguity.
- Ensure that the DGConnectIdentifier database property for each database allows the broker to properly connect to that database.
- Could not locate itself in the broker configuration file.
- Failed to distinguish itself from two or more databases in the configuration file.
- Determined it missed a role change within the configuration.
- Confirm that the host and SID names for the database exactly match the values in the HOST_NAME and INSTANCE_NAME columns of V$INSTANCE.
- Confirm that there are not two or more databases with the same connect identifier. That is, multiple databases in the broker configuration should not reach the same database.
- If a failover had been performed and the old primary database has been re-created (or a standby database has been re-created), make sure the 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.
- The broker rejected an attempt to change the overall configuration protection mode since it could not find any enabled standby databases that supported the proposed protection mode.
- The broker rejected an attempt to enable the configuration if it determined that there were no enabled standby databases that supported the overall protection mode.
- The broker rejected an attempt to disable or remove a database that, if disabled or deleted, would result in no remaining standby databases 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 standby datbases supported the overall protection mode.
- For enable failures, confirm that at least one standby database has a LogXptMode configurable property setting that supports the current overall protection mode.
- For delete and disable failures, confirm that at least one other standby database has a LogXptMode configurable property setting that supports 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 standby database has its LogXptMode configurable property set to the value "SYNC". 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 health check error, confirm that at least one standby database has a LogXptMode configurable property setting that supports the current overall protection mode.
- The Data Guard configuration must be in either MaxAvailability or MaxPerformance protection mode.
- The LogXptMode property for both the primary database and the fast-start failover target standby database must be set to SYNC if the configuration protection mode is set to MaxAvailability mode.
- The LogXptMode property 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.
- The primary database and the fast-start failover target standby database must both have flashback enabled.
- 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 Data Guard configuration.
- Set the Data Guard configuration to either MaxAvailability or MaxPerformance protection mode.
- Ensure that the LogXptMode property for both the primary database and the fast-start failover target standby database are set to SYNC 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.
- Ensure that both the primary database and the fast-start failover target standby database have flashback enabled.
- Set the primary database FastStartFailoverTarget property to the DB_UNIQUE_NAME value of the desired target standby database and the desired target standby database FastStartFailoverTarget property to the DB_UNIQUE_NAME value of the primary database.
- 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.
- 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.
- The values of redo transport-related properties contain syntax syntax errors.
- The value of the LogArchiveTrace property was out of range.
- The Oracle Net service name specified in DGMGRL CREATE CONFIGURATION or ADD DATABASE command was not one that provides access to the database being added.
- There were no instances running for the database being added.
- Shut down all instances of the primary database and restart one instance with the initialization parameter CLUSTER_DATABASE set to FALSE. Downgrade the redo transport mode of the standby database of interest. Then, shutdown the instance, set the the CLUSTER_DATABASE initialization parameter to TRUE, and restart all primary database instances.
- Downgrade the protection mode to Maximum Performance mode and then, downgrade the redo transport mode of the standby database of interest. Finally, upgrade the protection mode. This will require a restart of all primary database instances if upgrading to Maximum Protection mode. Note that the above only works when there is at least one standby database in the configuration that has its redo transport mode set to SYNC.
- The AlternateLocation property was empty, but the redo transport to the standby database had an ALTERNATE setting.
- The AlternateLocation property was not empty and the redo transport to the standby database had no ALTERNATE setting.
- The AlternateLocation property did not match the ALTERNATE setting in the redo transport. The mismatch may include service string, directory specification of the alternate location, or the DB_UNIQUE_NAME attribute.
- The LOG_ARCHIVE_DEST_STATE_n parameter corresponding to the alternate location was not set to ALTERNATE.
- The flash recovery area was being used by the standby database for archived logs, but the redo transport to the standby database still had an ALTERNATE setting for the AlternateLocation property. Data Guard broker logs provide more details on which of the above cases caused the error.
- The AlternateLocation property was empty, but the redo transport to the standby database had an ALTERNATE setting.
- The AlternateLocation property was not empty and the redo transport to the standby database had no ALTERNATE setting.
- The AlternateLocation property did not match the ALTERNATE setting in the redo transport. The mismatch may include service string, directory specification of the alternate location, or the DB_UNIQUE_NAME attribute.
- The LOG_ARCHIVE_DEST_STATE_n parameter corresponding to the alternate location was not set to ALTERNATE.
- The flash recovery area was being used by the standby database for archived logs, but the redo transport to the standby database still had an ALTERNATE setting for the AlternateLocation property. Data Guard broker logs provide more details on which of the above cases caused the error.
- The host where the observer was running was not available.
- The network connection between the observer and this database was not available.
- The observer process was terminated unexpectedly.
- The apply service was started without specifying the real-time apply option or without the NODELAY option when the DelayMins property was set to zero.
- The apply service was started with the real-time apply option or with the NODELAY option when the DelayMins property was set to a value greater than zero.
- reinstate a database that required reinstatement.
- convert a physical standby database to a snapshot standby database.
- convert a snapshot standby database to a physical standby database. Flashback Database may been disabled manually with the ALTER DATABASE FLASHBACK DATABASE OFF command or automatically by the database in the event of an error.