Descriptions of the ALL and NONE options are as follows:

• ALL - During the failover process, the broker determines whether the bystander standby databases are ahead of or behind the failover target standby (that is, the standby that will be the new primary).

  If the bystander standbys are ahead, they will be disabled with a status of ORA-16661 as part of the failover operation. The bystander standbys must be reinstated after failover completes. The broker reinstates a standby through a flashback to the SCN at which the target standby became a primary database, and sets up the redo transport configuration from the new primary to the standby.

  If the bystander standbys are behind, then the broker simply sets up the redo transport configuration from the soon-to-be-new-primary to these standbys and completes the failover process.

• NONE - During the failover process, the broker does NOT evaluate the status of the bystander standbys as part of the failover operation. They are marked as disabled with a status of ORA-16661 so that they can be evaluated later. The broker simply completes the failover to produce a new primary database as soon as possible.

  After the failover is completed, you can reinstate the bystander standbys. During reinstatement of a bystander, the broker determines whether the bystander is ahead of, or behind, the new primary. If the bystander is ahead of the new primary, then the broker automatically flashes back the standby to the SCN at which the target standby became a primary database and sets up redo transport from the new primary to the standby. (Even if a flashback is not required, the broker sets up the redo transport configuration from the new primary to these standbys.)

  The NONE option decreases the processing time for failover, but disables broker management of all bystander databases in the configuration. If fast-start failover is enabled, then the observer automatically reinstates the standby databases after failover has completed. Otherwise, you will have to manually reinstate the standby databases after failover has completed.

A value of zero indicates that a network communication should never be timed out.

To set up transport of redo data to the specified destination, the broker uses the values specified for this parameter to define a LOG_ARCHIVE_DEST_n initialization parameter on the primary database. The broker also monitors the health of the transport to the specified destination.

After a role change, the broker automatically sets up a LOG_ARCHIVE_DEST_n initialization parameter on the new primary database to ship redo data to the specified destination.

To set up transport of redo data to the specified destination, the broker uses the values specified for this parameter to define a LOG_ARCHIVE_DEST_n initialization parameter on the primary database. The broker also monitors the health of the transport to the specified destination.

After a role change, the broker automatically sets up a LOG_ARCHIVE_DEST_n initialization parameter on the new primary database to ship redo data to the specified destination.

To prevent automatic reinstatement of the former primary database in these cases, set this configuration property to FALSE.

The broker never automatically reinstates the former primary database if a fast-start failover was initiated because a user configuration condition was detected or was requested by an application calling the DBMS_DG.INITIATE_FS_FAILOVER function.

If the limit is reached, then a fast-start failover is not allowed. The lowest possible value is 5 seconds.

This property is used when fast-start failover is enabled and the configuration is operating in maximum performance mode.

The primary database shuts down if fast-start failover is enabled and V$DATABASE.FS_FAILOVER_STATUS indicates the primary has been STALLED for longer than FastStartFailoverThreshold seconds. In such a situation, it is likely that the primary has been isolated and a fast-start failover has already occurred. A value of TRUE helps to ensure that an isolated primary database cannot satisfy user queries.

Setting this property to FALSE will not prevent the primary database from shutting down if a fast-start failover occurred because a user configuration condition was detected or was requested by an application by calling the DBMS_DG.INITIATE_FS_FAILOVER function.

(If there is only one observer, then by default it is considered the master. The time interval starts when the observer first loses connection with the primary database. If the observer is unable to regain a connection to the primary database within the specified time, then the observer initiates a fast-start failover to the target standby database. See Task 4 in Enabling Fast-Start Failover for more information about setting this property.

The observer ignores the threshold completely if a configurable fast-start failover condition is detected or an application has requested that fast-start failover be initiated.

For help in determining an appropriate value for this property, you can use the information provided in the V$FS_OBSERVER_HISTOGRAM view. This view displays statistics that are based on the frequency of successful pings between the observer and primary database for different time intervals. (This view is available in Oracle Database 12c Release 1 (12.1.0.2) and later. It is also available in Oracle Database 11g Release 2 (11.2.0.4), but not in Oracle Database 12c Release 1 (12.1.0.1).) See Oracle Database Reference for a description of the V$FS_OBSERVER_HISTOGRAM view.

This is the behavior even if the standby has a healthy connection to the primary.

When this property is set to the default value of 0, the observer creates and maintains a connection to the primary database, but it does not periodically create a new connection to the primary database. While this eliminates the processing overhead associated with periodically establishing a new observer connection to the primary database, it also prevents the observer from detecting that it is not possible to create new connections to the primary database. Oracle recommends that this property be set to a value that is small enough to allow timely detection of faults at the primary database, but large enough to limit the overhead associated with periodic observer connections to an acceptable level.

The possible actions are as follows:

• CONTINUE - The primary database continues operating even if a standby database detects that a lost write has occurred at the primary database. This is the default action.

• SHUTDOWN - If a standby database detects that a lost write has occurred at the primary database, then fast-start failover is disabled and the primary database performs a shutdown abort. Automatic failover will not occur.

• FAILOVER - If fast-start failover is enabled in maximum performance mode, and the configuration is within the acceptable limit specified for the FastStartFailoverLagLimit property, then the observer initiates a failover.

• FORCEFAILOVER - If fast-start failover is enabled (in either maximum performance or maximum availability mode), then the observer initiates a failover. This option results in a data loss failover.

For both the FAILOVER and FORCEFAILOVER options, if fast-start failover is disabled then no failover occurs, but the primary is shut down.

If a standby detects that a lost write has occurred at the primary database, fast-start failover is disabled if any of the following conditions are true:

• PrimaryLostWriteAction is set to CONTINUE
• PrimaryLostWriteAction is set to SHUTDOWN
• PrimaryLostWriteAction is set to FAILOVER and protection mode is set to either maximum availability or maximum protection

Diagnostic information is written to the database alert and broker logs at the primary database and at the standby database where the lost write was detected.

If a lost write occurs at the primary database, then follow the guidelines in "Resolving ORA-752 or ORA-600 [3020] During Standby Recovery" in My Oracle Support Note 1265884.1 located at http://support.oracle.com.

Setting the property to USER limits the tracing to completed operations and to any warning or error messages resulting from an operation or health check. Setting the property to SUPPORT increases the amount of tracing to include lower-level information needed by Oracle Support Services.

Although the properties reported in this table are database-specific or far sync instance-specific properties, the inconsistency is reported on an instance-specific basis. A database or far sync instance-specific property only ensures that there is one value in the broker's configuration file for all instances of the database or far sync instance, but the runtime values can be different. This means that a database or far sync instance-specific property may be inconsistent only on some instances.

This property pertains to the primary database, a physical standby database that ships redo data, or a far sync instance. The table contains the following columns:

• INSTANCE_NAME

  The value identifying the SID for the instance.

• STANDBY_NAME

  The database unique name (DB_UNIQUE_NAME) of the standby database or far sync instance to which this redo transport services property pertains.

• PROPERTY_NAME

  The name of the redo transport services property with an inconsistent value.

• MEMORY_VALUE

  The runtime value being used in the database or far sync instance.

• BROKER_VALUE

  The value of the redo transport services property saved in the broker configuration file.

The information is shown in table format. Although the properties reported in this table are database-specific or far sync instance-specific properties, the inconsistency is reported on an instance-specific basis. A database or far sync instance-specific property only ensures that there is one value in the broker's configuration file for all instances of the database or far sync instance, but the runtime values can be different. This means that a database or far sync instance-specific property may be inconsistent only on some instances

Each individual configuration member has this property. The table contains the following columns:

• INSTANCE_NAME

  The value identifying the SID for the instance.

• PROPERTY_NAME

  The name of the property with the inconsistent value.

• MEMORY_VALUE

  The corresponding runtime value being used.

• SPFILE_VALUE

  The corresponding value saved in the server parameter file (SPFILE).

• BROKER_VALUE

  The value of the property saved in the broker configuration file.

This property pertains to the primary database, a physical standby database that ships redo data, or a far sync instance.

The table contains the following columns:

• PRIMARY_INSTANCE_NAME

  The value identifying the SID for the instance on the primary database.

• STANDBY_DATABASE_NAME

  The database unique name (DB_UNIQUE_NAME) of the standby database or far sync instance.

• ERROR

  The text of the redo transport error. If there is no error, the field is empty.

Each entry in the table indicates the status of redo transport services on one redo source to one redo destination.

The error status can be an empty string, which indicates there is no error.

In the following example, the STATUS from South_Sales is empty because there is no error for the South_Sales destination. The South_Report destination returned the ORA-01034 message.

DGMGRL> SHOW DATABASE 'North_Sales' 'LogXptStatus' ;
LOG TRANSPORT STATUS
PRIMARY_INSTANCE_NAME STANDBY_DATABASE_NAME               STATUS
         north_sales1          South_Sales
         north_sales1          South_Report    ORA-01034: ORACLE not available

This property contains a string with the following values from the DBA_LOGSTDBY_EVENTS view:

• XIDUSN: Transaction ID undo segment number

• XIDSLT: Transaction ID slot number

• XIDSQN: Transaction ID sequence number

• STATUS_CODE: Status (or Oracle error code) belonging to the STATUS message

• STATUS: Description of the current activity of the process or the reason why log apply services stopped

The transaction IDs and status information are separated by a string of number signs (###).

This property pertains to a logical standby database.

The MAX_SGA is the maximum system global area and MAX_SERVERS is the maximum number of parallel query servers. These values are separated by a string of number signs (###) in the LsbyParameters property.

This property pertains to a logical standby database.

If no rows are returned, it implies all log files received have been applied. This property pertains to a standby database.

The table contains the following columns in the order shown:

• STATUS

  The STATUS column is set to one of the following values for a log file on a logical standby database:

  • NOT_APPLIED: No redo records in this log file have been applied.

  • PARTIALLY_APPLIED: Some of the redo records in this log file have been applied while others have not.

  • COMMITTED_TRANSACTIONS_APPLIED: This status value only applies to a logical standby database. All redo records belonging to the committed transactions have been applied. Redo records belonging to uncommitted transactions have not been read by LogMiner and may still be needed when the transactions are committed in the future. Therefore, it is not safe yet to discard this online redo log file.

• RESETLOGS_ID

  Resetlogs identifier associated with the archived redo log file

• THREAD

  The redo thread number

• LOG_SEQ

  The online redo log file sequence number

• TIME_GENERATED

  The first time when the online redo log file was written to the primary database

• TIME_COMPLETED

  The next time when the log file was archived on the primary database (corresponds to the NEXT_CHANGE# column)

• FIRST_CHANGE#

  First change number in the archived redo log file

• NEXT_CHANGE#

  First change in the next log file

• SIZE (KBs)

  The SIZE of the online redo log file in kilobytes

For example:

DGMGRL> SHOW DATABASE 'South_Sales' 'RecvQEntries' ;
              STATUS     RESETLOGS_ID           THREAD
LOG_SEQ          TIME_GENERATED       TIME_COMPLETED    FIRST_CHANGE#
NEXT_CHANGE#        SIZE (KBs)
         NOT_APPLIED        497198843                1                    5
06/20/2003 14:55:38  06/20/2003 16:31:26           202138
210718             7364
         NOT_APPLIED        497198843                1                    6
06/20/2003 16:31:26  06/20/2003 16:31:39           210718
210753               13
         NOT_APPLIED        497198843                1                    7
06/20/2003 16:31:39  06/20/2003 16:31:54           210753
210758                1
         NOT_APPLIED        497198843                1                    8
06/20/2003 16:31:54  06/20/2003 16:31:59           210758
210789               11

This property pertains to the primary database.

The table contains the following columns:

• STANDBY_NAME

  The value can be empty or it can contain the database unique name (DB_UNIQUE_NAME) of a standby database. If empty, the STATUS column will contain a value of CURRENT or NOT_ARCHIVED.

• STATUS

  The STATUS column is set to one of the following values:

  • CURRENT: A log file to which online redo is currently being written.

  • NOT_ARCHIVED: A completed online redo log file that has not been archived locally.

  • ARCHIVED: A completed log file that has been archived locally but has not been transmitted to the standby database specified in the STANDBY_NAME column.

  The table contains exactly one row with the value of STATUS=CURRENT. There can be multiple rows with the value STATUS=ARCHIVED or STATUS=NOT_ARCHIVED.

• RESETLOGS_ID

  Resetlogs identifier associated with the archived redo log file

• THREAD

  The redo thread number.

• LOG_SEQ

  The log sequence number. Multiple rows may have the same LOG_SEQ value (for different STANDBY_NAME values).

• TIME_GENERATED

  The first time when the online redo log file was written to the primary database.

• TIME_COMPLETED

  The next time when the log file was archived on the primary database (corresponds to the NEXT_CHANGE# column).

• FIRST_CHANGE#

  First change number in the archived redo log file.

• NEXT_CHANGE#

  First change in the next log file.

• SIZE (KBs)

  The SIZE of the online redo log file in kilobytes.

For example, the following shows output from a SHOW DATABASE command:

DGMGRL> SHOW DATABASE 'North_Sales' 'SendQEntries' ;
PRIMARY_SEND_QUEUE
        STANDBY_NAME       STATUS     RESETLOGS_ID
THREAD              LOG_SEQ       TIME_GENERATED       TIME_COMPLETED
FIRST_CHANGE#     NEXT_CHANGE#       SIZE (KBs)
       South_Sales   ARCHIVED        497198843
1                    9  06/20/2003 16:31:59  06/20/2003 16:39:57
210789           211411              186
       South_Sales   ARCHIVED        497198843
1                   10  06/20/2003 16:39:57  06/20/2003 16:40:01
211411           211415                1
       South_Sales   ARCHIVED        497198843
1                   11  06/20/2003 16:40:01  06/20/2003 16:40:07
211415           211418                1
                          CURRENT        497198843
1                   12  06/20/2003 16:40:07
211418                                 1

The events and their waiting time are retrieved from V$SYSTEM_EVENT. Each instance in the configuration has this property. This property is an instance-specific monitorable property. The table contains the following columns in the order shown:

• Event

  The system wait event.

• Wait Time

  The total amount of time waited for this event in hundredths of a second.

The following example shows output from a SHOW INSTANCE command:

DGMGRL> SHOW INSTANCE north_sales1 'TopWaitEvents';
TOP SYSTEM WAIT EVENTS
               Event            Wait Time
   rdbms ipc message               671350
SQL*Net message from client         62390
          pmon timer                47897
  Queue Monitor Wait                43016
 wakeup time manager                38508

The property value is expressed in seconds. A value of 0 seconds results in no warnings being generated when an apply lag exists.

If Redo Apply is shut off, then setting the property has no immediate effect. However, when Redo Apply is running again, the value of the property is used to determine the parallel apply behavior of Redo Apply.

In effect, limiting the amount of data that can be lost increases the availability of the standby database by forcing a log switch after the amount of time you specify (in seconds) elapses. That way, the standby database will not miss redo records generated from a time range longer than the value set for the ARCHIVE_LAG_TARGET initialization parameter.

If you add a datafile to the primary database, this property converts the datafile name on the primary database to the datafile on the physical standby database.

This property is used in the following situations:

• At physical standby mount time, it is used to rename primary datafile filenames to standby datafile filenames if the datafile file path on the physical standby system is different from the primary database system.

• When a new data file is created on the primary database, a corresponding new data file will be created on the physical standby database if the StandbyFileManagement configurable property is set to 'AUTO'. Oracle uses the data-file file-path mapping information from the DbFileNameConvert property to determine the standby file path of the new standby data file. If the StandbyFileManagement property is set to 'MANUAL', you must add a corresponding file to the physical standby database.

When the DelayMins property is set to the default value of 0 minutes, log apply services apply redo data as soon as possible.

If the DelayMins property is set to 0, start log apply services as follows:

• Start Redo Apply on physical standby databases using the following SQL statement:

  ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
  

• Start SQL Apply on logical standby databases using the following SQL statement:

  ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
  

If you are using DGMGRL, then you supply the value when you enter the CREATE CONFIGURATION, ADD DATABASE, or ADD FAR_SYNC command. If you are using Cloud Control, the value is supplied automatically. The connect identifier for a configuration member must:

• Allow all other members in the configuration to reach it.

• Allow the member to reach itself.

• Allow all instances of an Oracle RAC database to be reached.

• Specify a service that all instances dynamically register with the listeners so that connect-time failover on an Oracle RAC database is possible.

  Caution:

  The service should NOT be one that is defined and managed by Oracle Clusterware.

• Have failover attributes set to allow the primary database's Redo Transport Services to continue shipping redo data to an Oracle RAC standby database, even if the receiving instance of that standby database has failed.

The value of this property is specified in the SERVICE attribute of the LOG_ARCHIVE_DEST_n parameter when the broker configures redo transport services on the primary database.

These possible target databases are referred to as candidate fast-start failover targets. See Task 2 in Enabling Fast-Start Failover for more information about setting this property.

The FastStartFailoverTarget configuration property can only be set to the name of physical or logical standbys. It cannot be set to the name of a snapshot standby database, far sync instance, or Zero Data Loss Recovery Appliance.

To specify the format, it uses a database ID (%d), thread (%t), sequence number (%s), and resetlogs ID (%r).

The actual number of archiver processes in use may increase subsequently based on the archiving workload.

For the online redo log files to be available for reuse, archiving must succeed to a minimum number of destinations.

The Oracle database writes an audit trail of the archived redo log files received from the primary database into process trace files.

The other member can be a physical, logical, or snapshot standby, or a far sync instance.

• If the primary database is in the TRANSPORT-ON state and the value of the LogShipping property is ON, then redo transport services are enabled to send redo data to the particular configuration member. If the LogShipping property is OFF, then redo transport services are disabled to that member.

• If a configuration member that forwards redo data has its LogShipping property set to ON and the member to which it sends redo data also has its LogShipping property set to ON, then redo transport services are enabled from the member sending redo data to the member that is to receive redo data.

  If a member that forwards redo data has its LogShipping property set to ON but the member to which it sends redo data has its LogShipping property set to OFF, then redo transport services are disabled from the member sending redo data to the member that is to receive redo data.

You set the redo transport services on each configuration member to one of the following modes:

• SYNC

  Configures redo transport services for this configuration member using the SYNC and AFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. Standby redo log files are required. This mode is required for the maximum protection or maximum availability data protection modes. This redo transport service enables the highest grade of data protection to the primary database, but also incurs the highest performance impact.

• ASYNC

  Configures redo transport services for this configuration member using the ASYNC and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. Standby redo log files are required. This mode enables a moderate grade of data protection to the primary database, and incurs a lower performance impact than SYNC.

• FASTSYNC

  Configures redo transport services for this configuration member using the SYNC and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. This mode is only available in maximum availability protection mode. Because FASTSYNC transport mode uses the NOAFFIRM attribute of the LOG_ARCHIVE_DEST_n parameter, data loss is possible.

If the value is 0, then SQL Apply uses all available parallel query servers to read the log files and apply changes.

If the value is 0, SQL Apply uses one quarter of the value set for the SHARED_POOL_SIZE initialization parameter.

Specify one of the following values:

• TRUE: Transactions are applied to the logical standby database in the exact order in which they were committed on the primary database.

• FALSE: Transactions containing non-overlapping sets of rows may be committed in a different order than they were committed on the primary database.

Specify one of the following values:

• TRUE: DDL statements applied to the logical standby database are recorded in the DBA_LOGSTDBY_EVENTS table. This is the default setting.

• FALSE: Applied DDL statements are not recorded.

Specify one of the following values:

• TRUE: Skipped DDL statements are recorded in the DBA_LOGSTDBY_EVENTS table. This is the default setting.

• FALSE: Skipped DDL statements are not recorded in the DBA_LOGSTDBY_EVENTS table.

Specify one of the following values:

• TRUE: Skipped errors are recorded in the DBA_LOGSTDBY_EVENTS table.

• FALSE: Skipped errors are not recorded in the DBA_LOGSTDBY_EVENTS table.

A value of zero indicates that an unlimited number of failures are allowed.

It is used to bypass the long connection timeout in TCP.

The connect identifier can pertain only to the primary database, or to the target standby database when fast-start failover is enabled.

It is only used when the database is a standby Oracle RAC database. The value could be an empty string (default) which means the broker chooses the apply instance.

You can use the RedoRoutes property to create a more complex redo transport topology, such as one in which a physical standby database or a far sync instance forwards redo received from the primary database to one or more destinations, or one in which the redo transport mode used for a given destination is dependent on which database is in the primary role.

The RedoRoutes property is set to a character string that contains one or more redo routing rules. Each rule contains one or more redo sources and one or more redo destinations. A redo routing rule becomes active when one of the redo sources in the rule is in the primary role. This results in redo from the primary database being sent to every redo destination in that rule.

The property has database-specific scope, and the location that it specifies is applicable to all instances in a database.

If this property is set to AUTO, in conjunction with valid settings in the DbFileNameConvert configurable property, a corresponding new datafile is automatically created on the standby database. The location of this new standby datafile is determined by the value of the DbFileNameConvert property.

If this property is set to MANUAL, you have to create the correct new datafile on the standby database manually.

If this property has a null value, then the DGConnectIdentifier value is used for operations that involve shutting down and starting up the instance.

The property value is expressed in seconds. A value of 0 seconds results in no warnings being generated.

The property value is expressed in seconds. A value of 0 seconds results in no warnings being generated when a transport lag exists.