4 Managing Databases

4.2.1 Database State Transitions

You can use the DGMGRL EDIT DATABASE command to explicitly change the state of a database. For example, the EDIT DATABASE command in the following example changes the state of the North_Sales database to TRANSPORT-OFF.

DGMGRL> EDIT DATABASE 'North_Sales' SET STATE='TRANSPORT-OFF';
Succeeded.

The following sections describe in more detail the possible state transitions for primary and standby databases.

Primary database state transitions

When transitioning the primary database to the TRANSPORT-ON state, the broker sets up redo transport services to all broker-managed standby databases using the redo transport-related properties of the standby databases (see Section 4.4 for the list of all redo transport-related properties). Redo transport services setup is done by setting the LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_DEST_STATE_n initialization parameters on the primary database, and the LOG_ARCHIVE_CONFIG initialization parameter on all databases (primary or standby). If necessary, the broker also sets up the data protection mode of the database to match the protection mode recorded in the broker configuration file. Finally, if the database is open, the broker switches a log for each thread to initiate redo transport services.

When transitioning the primary database to the TRANSPORT-OFF state, the broker turns off redo transport services to all broker-managed standby databases by resetting the LOG_ARCHIVE_DEST_STATE_n initialization parameter. Transmission of redo data to all broker-managed standby databases is stopped. Log files continue to be archived at the primary database.

If the primary database is an Oracle RAC database, the broker configures redo transport services on all primary instances with the exact same settings.

Physical standby database state transitions

When transitioning a physical standby database to the APPLY-ON state, the broker starts Redo Apply with options specified by the Redo Apply-related properties (see Section 4.5 for the property list). If the standby database is an Oracle RAC database, the broker starts Redo Apply on one standby instance, called the apply instance.

If a license for the Oracle Active Data Guard option has been purchased, a physical standby database can be open while Redo Apply is active. This capability is known as real-time query. See Oracle Data Guard Concepts and Administration for more details.

When transitioning to the APPLY-OFF state, the broker stops Redo Apply.

Snapshot standby database state transitions

A snapshot standby database does not have states. It only receives redo data.

Logical standby database state transitions

When transitioning a logical standby database to the APPLY-ON state, the broker will wait until the database is open, and then enable the database guard to prevent modifications to tables in the logical standby database, and start SQL Apply with options specified by the log apply-related properties. If the logical standby database is an Oracle RAC database, the broker starts SQL Apply on one standby instance, the apply instance.

When transitioning to the APPLY-OFF state, the broker stops SQL Apply.

4.3.1 Monitorable (Read-Only) Properties

Monitorable database properties allow you to view information related to the database, but you cannot change the values of these properties. These properties can be very helpful when you are trying to diagnose problems in the broker configuration. For example, you can view the InconsistentLogXptProps monitorable database property to determine where there is a discrepancy in redo transport services properties between the broker configuration file and the actual value currently used by the database.

You can list all monitorable database properties using the DGMGRL SHOW DATABASE VERBOSE command. Use the SHOW DATABASE command to obtain more details about a particular property. For example, the following shows the InconsistentLogXptProps property:

DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentLogXptProps';

INCONSISTENT LOG TRANSPORT PROPERTIES

 INSTANCE_NAME     STANDBY_NAME  PROPERTY_NAME  MEMORY_VALUE  BROKER_VALUE 
  south_sales1      South_Sales     ReopenSecs           600           300

Enterprise Manager displays the information obtained from these properties on the Edit Properties page.

4.3.2 Configurable (Changeable) Database Properties

Configurable database properties affect the operation or configuration of the database. When you use DGMGRL or Enterprise Manager to create a primary database object and import existing standby databases into a new broker configuration, the property values are initially imported from the database settings.

You can update many property values when the database is either disabled or enabled. When a new database is added into the configuration, the broker connects to the database and imports initial values for the database properties from the current database settings. For example:

DGMGRL> SHOW DATABASE 'North_Sales' 'ArchiveLagTarget';
  ArchiveLagTarget = '0'

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'ArchiveLagTarget'=1200;
  Property "ArchiveLagTarget" updated

DGMGRL> SHOW DATABASE 'North_Sales' 'ArchiveLagTarget';
  ArchiveLagTarget = '1200'

When the configuration is enabled, the broker keeps the database property values in the broker configuration file consistent with the values being used in the database. For those that are related to initialization parameter properties, the broker maintains the consistency among the value in the broker configuration file, the current database value, and the initialization parameter value in the server parameter file, as follows:

• For dynamic parameters, the broker keeps the value of the database parameter consistent in the system global area (SGA) for the instance, in the broker configuration file, and in the server parameter file.

• For static parameters and properties, the database parameter value in the system global area (SGA) for the instances may temporarily differ from what is in the broker configuration file and in the server parameter file. Typically, the database value becomes the same as the server parameter file value and the broker configuration file value the next time the database instance is stopped and restarted.

Even when the configuration is disabled, you can update database property values through the broker. The broker retains the property settings (without validating the values) and updates the database initialization parameters in the server parameter file and the settings in memory the next time you enable the broker configuration.

4.4.1 Setting Up For Redo Transport

Redo data is transported to a standby database using Oracle Net. An Oracle Net service name is specified with the SERVICE attribute of the LOG_ARCHIVE_DEST_n initialization parameter and is used to transmit redo data to the standby database. The Oracle Net service name is translated into a connect descriptor that contains the information necessary for connecting to the standby database.

The SERVICE attribute can be set or changed by using the DGConnectIdentifier database property. The DGConnectIdentifier property is set when a database is first added to the configuration. Its initial value is the connect identifier that is specified in the optional CONNECT IDENTIFIER IS clause of the ADD DATABASE command. If that optional clause is not specified, the initial value of the DGConnectIdentifier property is extracted from the SERVICE attribute of the LOG_ARCHIVE_DEST_n initialization parameter whose DB_UNIQUE_NAME attribute matches the DB_UNIQUE_NAME of the database specified in the ADD DATABASE command.

The DGConnectIdentifier property value is also used to set up the FAL_SERVER initialization parameter. If the DGConnectIdentifier property for any database is changed, the SERVICE attribute of the corresponding LOG_ARCHIVE_DEST_n initialization parameter will also be changed. In addition, the FAL_SERVER initialization parameter will also be updated on every enabled standby database in the configuration.

4.4.2 Managing Redo Transport Services for Data Protection Modes

Section 4.6 describes how the broker handles data protection modes. As a part of the overall configuration protection mode, you must ensure that redo transport services are also properly set up for the data protection mode that you choose.

You use the LogXptMode database property to set the SYNC or ASYNC mode for redo transport services. See Table 4-2 for additional information about protection modes and redo transport services.

The values for the LogXptMode property are described in the following list:

SYNC

Configures redo transport services for this standby database using the SYNC and AFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. This mode, along with standby redo log files, is required for configurations operating in either maximum protection mode or maximum availability mode. This redo transport service enables the highest grade of data protection to the primary database, but also can incur a higher performance impact.

ASYNC

Configures redo transport services for this standby database using the ASYNC and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. This mode, along with standby redo log files, enables a moderate grade of protection to the primary database, and lower performance impact.

4.4.3 Turning Redo Transport Services On and Off

Turn redo transport services on and off by setting the state of the primary database. Setting the primary database state to TRANSPORT-ON starts redo transport services to the standby databases, and setting the primary database state to TRANSPORT-OFF stops redo transport services to all the standby database.

Turn redo transport services on and off to an individual standby database using the LogShipping database property on the standby database. The LogShipping property accepts values ON and OFF. If you set the LogShipping property to OFF for a standby database, redo transport services to this standby database are turned off, while redo transport services to other databases are not affected. You can set LogShipping to ON to turn back on redo transport services to the standby database.

The relationship between setting the primary database state and setting the LogShipping property is as follows:

• If the primary database state is set to TRANSPORT-OFF, redo transport services to all the standby databases are stopped regardless of the LogShipping property values of the individual standby databases.

• If the primary database state is set to TRANSPORT-ON, redo transport services to each standby database are determined by the LogShipping property of that database.

Example 4-2 and Example 4-3 show how to turn off redo transport services in two different scenarios.

DGMGRL> EDIT DATABASE 'North_Sales' SET STATE='TRANSPORT-OFF';
DGMGRL> SHOW DATABASE 'North_Sales';
 
Database - North_Sales
 
  Role:            PRIMARY
  Intended State:  TRANSPORT-OFF
  Instance(s):
    north_sales1
 
Database Status:
SUCCESS

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogShipping'='OFF';
Property "LogShipping" updated

DGMGRL> SHOW DATABASE 'South_Sales' 'LogShipping';
  LogShipping = 'OFF'

4.4.4 Specifying Locations for Archived Redo Log Files

You can set up locations on the standby database to store the archived redo log files to be used by log apply services on the standby database. This is done by setting the StandbyArchiveLocation and AlternateLocation database properties on the standby database.

StandbyArchiveLocation specifies a standby location where the archived redo log files will be stored. The broker only manages the location to store archived redo log files received from the primary database. For archived redo log files generated locally when the database is either the primary database or a logical standby database, you need to set up local destinations directly through the LOG_ARCHIVE_DEST_n initialization parameter. The broker allows the value of StandbyArchiveLocation to be the same as the location you set up for locally generated logs, in which case the broker sets up the VALID_FOR attribute of the destination appropriately so that it can be used for both the archived redo log files received from the primary database and archived redo log files generated locally.

You can also set up an alternate location to store archived redo log files on the standby using the AlternateLocation property on the standby database. This is useful for avoiding disk capacity problems or disk errors when archiving the online redo log files on the standby database. AlternateLocation specifies a standby location where the archived redo log files will be stored if the location specified by the StandbyArchiveLocation fails. The broker sets up the alternate location properly using the ALTERNATE attribute of the LOG_ARCHIVE_DEST_n initialization parameter.

4.4.5 Other Redo Transport Settings

You can use the Binding, MaxFailure, MaxConnections, NetTimeout, RedoCompression, and ReopenSecs database properties to tune the performance of redo transport services and to set up redo transport services failure policies. These properties correspond to attributes on the LOG_ARCHIVE_DEST_n initialization parameter.

When creating a new standby database, the broker sets these properties with default values. When importing an existing standby database, the broker imports existing settings corresponding to these properties if it finds a match between the service string of a current destination and the connect identifier that was specified when the database was added to the configuration. If that fails, it finds a match between the db_unique_name of a current destination and the name that was specified when the database was added to the configuration.

For most cases, the default values or the imported values should be sufficient for normal operations. If for some reason you need to change these property values, you can use DGMGRL commands to set up these properties. Enterprise Manager does not provide an interface for modifying these properties.

4.4.6 Redo Transport Services in an Oracle RAC Database Environment

If the primary database is an Oracle RAC database, the broker ensures that redo transport services are set up identically on each of the primary database instances. Each instance has the same remote destinations, and for each remote destination, all instances are set up the same in terms of redo transport service, performance related settings, and so on. If an instance has different settings, the broker raises a health check warning on that particular instance

Settings relative to redo transport services are saved in the broker configuration file as properties. When you update a redo transport-related property on a standby database, the corresponding change is also made automatically by the broker to the LOG_ARCHIVE_DEST_n initialization parameter on all of the primary database instances. If a new instance comes up on the primary database, the broker sets up redo transport services for the new instance using the redo transport-related properties of all the standby databases currently being managed by the broker. After the new instance is opened for activity, all archived redo log files generated on this instance will begin to transmit to the standby databases.

4.4.7 Transport Lag

Transport lag is a measure of the degree to which the transport of redo to the standby database lags behind the generation of redo on the primary database.

If there are one or more redo gaps on the standby database, the transport lag is calculated as if no redo has been received after the beginning of the earliest redo gap.

Both Enterprise Manager and the DGMGRL client display the redo transport lag for each managed standby database. Enterprise Manager displays the transport lag on the Data Guard home page. The DGMGRL client displays the transport lag in the SHOW DATABASE output for a standby database. There is no transport lag displayed for a primary database. For example:

DGMGRL> show database 'South_Sales';
Database - South_Sales
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
  Real Time Query: OFF
  Instance(s):
  south_sales1
 
Database Status:
SUCCESS

The transport lag can help you identify any problems that may exist with the redo transport services.

4.5.1 Managing Delayed Apply

You can set up Apply Services so that the application of redo to the standby database is delayed. This allows the standby database to lag behind the primary database, and if a user error (for example, dropping a table) occurs during this window of time, the standby database will still contain the correct data that can be transmitted back to the primary database to repair the data.

By default, no delay is configured and the redo data is applied on a standby database as soon as possible. If the standby database has standby redo logs configured, the broker will enable real-time apply. When Redo Apply and SQL Apply apply redo in real time, the redo data is recovered directly from the standby redo log files as they are being filled. This means that the standby database does not have to wait for the log files to be archived before applying redo data from the archived redo log files. This minimizes the transactional lag between the primary and the standby.

Use the DelayMins database property to specify the number of minutes that log apply services must wait before applying redo data to the standby database. Note that only log apply services on the standby database are delayed. Redo transport services on the primary database are not delayed, thus the primary database data is still well protected by the standby database.

4.5.2 Managing Parallel Apply with Redo Apply

For Redo Apply, you can configure whether multiple parallel processes are used to apply redo data received from the primary database by using the ApplyParallel database property. Parallelism is enabled by default, which means Redo Apply automatically chooses the optimal number of parallel processes based on the number of CPUs in the system. (This is equivalent to setting the ApplyParallel property to AUTO.) You can disable parallelism by setting the ApplyParallel property to NO.

4.5.3 Allocating Resources to SQL Apply

You can control how much SGA memory is available for SQL Apply. This can be set using the LsbyMaxSga database property.

To control the number of parallel query servers used by SQL Apply, you can use the LsbyMaxServers database property.

You can control the trade off between SQL Apply performance and the commit order of transactions. The LsbyPreserveCommitOrder database property controls whether transactions are committed on the logical standby database in the exact same order in which they were committed on the primary database. Preserving commit order may affect performance.

4.5.4 Managing SQL Apply Filtering

One of the benefits of a logical standby database is to allow control of what to apply and what not to apply. This is done by setting up SQL Apply filters. The granularity of the filtering ranges from a specific transaction to database objects to a particular class of SQL statement on a particular schema.

To add a SQL Apply filter in Data Guard broker, use the LsbyASkip* database properties (for example, LsbyASkipTxnCfgPr or LsbyASkipCfgPr). To delete a previously added SQL Apply filter, use the LsbyDSkip* database properties (for example, LsbyDSkipTxnCfgPr or LsbyDSkipCfgPr).

4.5.5 Managing SQL Apply Error Handling

You can fine-tune SQL Apply to handle apply errors on a specified set of SQL statements on particular schemas. When such SQL Apply errors are encountered, Data Guard can either skip the error to continue SQL Apply or call a specified stored procedure at the time when the error is encountered.

To add this error handling capability, use the LsbyASkipErrorCfgPr database property. To delete a previously added error handling specification, use the LsbyDSkipErrorCfgPr database property.

Changing these properties results in restarting SQL Apply if the current database state is APPLY-ON. If the current database state is APPLY-OFF, the property changes take effect the next time the database state is changed to APPLY-ON.

4.5.6 Managing the DBA_LOGSTDBY_EVENTS Table

The DBA_LOGSTDBY_EVENTS table records important events that affect SQL Apply. Because every logical standby database might have a different interest in the set of events to be recorded in this table, Data Guard provides a means to control the event recording. From the Data Guard broker, you can use the LsbyRecord* database properties (for example, LsbyRecordSkipDdl or LsbyRecordSkipErrors) to control recording of a particular set of events. The value of these properties are either TRUE or FALSE, indicating the turning on or off of the event recording.

4.5.7 Apply Services in an Oracle RAC Database Environment

If a standby database is an Oracle RAC database, only one instance of the Oracle RAC database can have log apply services running at any time. This instance is called the apply instance. If the apply instance fails, the broker automatically moves log apply services to a different instance; this is called apply instance failover.

4.5.8 Apply Lag

Apply lag is a measure of the degree to which the data in a standby database lags behind the data in the primary database, due to delays in propagating and applying redo to the standby database.

Both Enterprise Manager and the DGMGRL client display the apply lag for each managed standby database. Enterprise Manager displays the apply lag on the Data Guard home page. The DGMGRL client displays the apply lag in the SHOW DATABASE output for a standby database. There is no apply lag displayed for a primary database. For example:

DGMGRL> show database 'South_Sales';
Database - South_Sales
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
  Real Time Query: OFF
  Instance(s):
    south_sales1
 
Database Status:
SUCCESS

The apply lag can help you identify any problems that may exist with both the redo transport services and the log apply services.

4.6.1 Setting the Protection Mode for Your Configuration

To set the protection mode, perform the following steps:

Step 1   Determine which data protection mode you want to use.

Each data protection mode provides a different balance of data protection, data availability, and database performance. To select the data protection mode that meets the needs of your business, carefully consider your data protection requirements and the performance expectations of your users.

Maximum Availability This protection mode provides the highest level of data protection that is possible without compromising the availability of a primary database. Transactions do not commit until all redo data needed to recover those transactions has been written to the online redo log and to the standby redo log on at least one synchronized standby database. If the primary database cannot write its redo stream to at least one synchronized standby database, it operates as if it were in maximum performance mode to preserve primary database availability until it is again able to write its redo stream to a synchronized standby database.

This mode ensures that no data loss will occur if the primary database fails, but only if a second fault does not prevent a complete set of redo data from being sent from the primary database to at least one standby database.

You can enable fast-start failover if the protection mode is maximum availability.

Maximum Performance This protection mode provides the highest level of data protection that is possible without affecting the performance of a primary database. This is accomplished by allowing transactions to commit as soon as all redo data generated by those transactions has been written to the online log. Redo data is also written to one or more standby databases, but this is done asynchronously with respect to transaction commitment, so primary database performance is unaffected by delays in writing redo data to the standby database(s).

This protection mode offers slightly less data protection than maximum availability mode and has minimal impact on primary database performance.

This is the default protection mode.

You can enable fast-start failover if the protection mode is maximum performance.

Maximum Protection This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover a transaction must be written to both the online redo log and to the standby redo log on at least one synchronized standby database before the transaction commits. To ensure that data loss cannot occur, the primary database will shut down, rather than continue processing transactions, if it cannot write its redo stream to at least one synchronized standby database.

Transactions on the primary are considered protected as soon as Data Guard has written the redo data to persistent storage in a standby redo log file. Once that is done, acknowledgment is quickly made back to the primary database so that it can proceed to the next transaction. This minimizes the impact of synchronous transport on primary database throughput and response time. To fully benefit from complete Data Guard validation at the standby database, be sure to operate in real-time apply mode so that redo changes are applied to the standby database as fast as they are received. Data Guard signals any corruptions that are detected so that immediate corrective action can be taken.

Because this data protection mode prioritizes data protection over primary database availability, Oracle recommends that a minimum of two standby databases be used to protect a primary database that runs in maximum protection mode to prevent a single standby database failure from causing the primary database to shut down. If only one standby database is supporting maximum protection mode, Data Guard broker will disallow the shutdown of the apply instance. This prevents the primary database from shutting down.

You cannot enable fast-start failover if the protection mode is maximum protection.

Step 2   Set up standby redo log files.

You must add standby redo log files on all standby databases, regardless of the protection mode you are using. Also, Oracle requires that you add standby redo log files on the primary database in preparation for a future switchover or failover. Standby redo log files are required on the primary database if you want to enable fast-start failover.

Enterprise Manager automatically prompts you to select one or more standby databases in the configuration and sets up standby redo log (SRL) files on them and on the primary database in preparation for a future role change.

See Also:

If you are using the DGMGRL command-line interface, follow the instructions in Oracle Data Guard Concepts and Administration to configure standby redo log files.

Step 3   Set the LogXptMode configurable database property, if necessary.

If the data protection mode requires that you change the redo transport service used by any of the standby databases, change the setting of the LogXptMode database property appropriately on each standby database. See Section 4.4 for more information about setting the redo transport service. Table 4-2 shows the protection modes and the corresponding redo transport service.

Enterprise Manager automatically specifies the correct redo transport service on the primary database in preparation for a future switchover.

Table 4-2 Data Guard Protection Modes and Requirements

Protection Mode	Redo Transport	Standby Redo Log Files Needed?	Usable with Fast-Start Failover?
MAXPROTECTION	SYNC	Yes	No
MAXAVAILABILITY	SYNC	Yes	Yes
MAXPERFORMANCE	ASYNC	Yes	Yes

Step 4   Set the protection mode.

Set the protection mode using DGMGRL commands or Enterprise Manager.

With DGMGRL:

1. Use the EDIT DATABASE (property) command and specify the standby database whose redo transport service should be changed to correspond to the protection mode you plan to set. For example, if you plan to set the overall Data Guard configuration to operate in maximum availability mode, you must use the EDIT DATABASE command to set the SYNC mode for redo transport services. For example:

   DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogXptMode'='SYNC';
   

   Do this also for the primary database or another standby database in the configuration to ensure that it can support the chosen protection mode after a switchover.

2. Use the EDIT CONFIGURATION SET PROTECTION MODE AS protection-mode command to set the overall configuration protection mode. For example:

   DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
   

See Section 6.5 for a DGMGRL scenario showing how to set the protection mode.

With Enterprise Manager:

1. On the Data Guard overview page, click the link to the right of the Protection Mode label.

2. Select Maximum Protection, Maximum Availability, or Maximum Performance and click Continue.

3. If prompted, log in to the database with SYSDBA privileges and click Login.

4. Select one or more standby databases to support the protection mode that you selected. If standby redo log files are needed, verify the names of the log files. Click OK.

5. On the Confirmation page, click Yes.

After upgrading the protection mode from maximum performance mode to maximum protection mode using either DGMGRL or Enterprise Manager, the primary database will be restarted automatically if you are upgrading to maximum protection mode. The primary database need not be restarted following a downgrade of the protection mode.

No restart is required when upgrading the protection mode from maximum performance to maximum availability or from maximum availability to maximum protection.

Note:

You can avoid a restart of the primary database when upgrading from maximum performance mode to maximum protection mode by first upgrading to maximum availability. Once in maximum availability mode, then upgrade to maximum protection.

Note:

Online database relocation with Oracle RAC One Node cannot be performed on the only physical standby database that supports maximum protection mode.

If online database relocation must be performed, then you must first downgrade the protection mode to maximum availability. After the online database relocation of the physical standby database is performed, you can upgrade the protection mode back to maximum protection. A restart of the primary database is not required.

4.6.2 How the Protection Modes Influence Broker Operations

This section describes how operations such as switchover, failover, disabling, or enabling the Data Guard configuration can have an effect on the configuration's protection mode and redo transport services. This section contains the following sections:

• Upgrading or Downgrading the Current Protection Mode

• Switchover Operations

• Failover Operations

• Disable and Enable Operations

• Requirements For Removing a Database from the Configuration

• Requirements On Other Operations

4.7.1 Configure Properties to Tune Fast-Start Failover

The configurable properties for fast-start failover include:

• FastStartFailoverThreshold

  Set the FastStartFailoverThreshold configuration property to specify the number of seconds you want the observer and target standby database to wait (after detecting the primary database is unavailable) before initiating a failover. See Section 5.5.2, "Enabling Fast-Start Failover" for more information and an example.

• FastStartFailoverPmyShutdown

  The FastStartFailoverPmyShutdown configuration property controls whether the primary database will shut down if redo generation has been stalled (FS_FAILOVER_STATUS column of V$DATABASE contains a value of STALLED) and the primary database has lost connectivity with the observer and target standby database for longer than the number of seconds specified by the FastStartFailoverThreshold configuration property. The default value for FastStartFailoverPmyShutdown is TRUE.

  Note:

  The primary database is always shut down if a user configurable fast-start failover condition is detected or if an application initiated a fast-start failover by calling the DBMS_DG.INITIATE_FS_FAILOVER function.

• FastStartFailoverLagLimit

  The fast-start failover feature can be configured on databases operating in maximum performance mode. Destinations that receive redo in ASYNC mode will be acceptable fast-start failover target standby databases, and these destinations can lag the primary in terms of redo received and applied. A configurable time-based limit can be specified through the FastStartFailoverLagLimit configuration property. If the standby database's applied redo point is within this many seconds of the primary's redo generation point, a fast-start failover will be allowed. If its applied point lags beyond this limit, a fast-start failover is not allowed. The FastStartFailoverLagLimit configuration property is not used if fast-start failover is enabled when the configuration is operating in maximum availability mode.An ASYNC destination is only a valid fast-start failover target in a configuration operating in maximum performance mode. If you want to change protection mode or change the destination to sync, you must first disable fast-start failover. Likewise, changing the protection mode from MAXAVAILABILITY to MAXPERFORMANCE will require first disabling fast-start failover and changing the LogXptMode property of the primary and target standby to ASYNC.Reinstatement of an old primary will be possible after a fast-start failover to an ASYNC target standby. If the observer rediscovers the old primary, it will automatically reinstate the old primary and any redo generated within the specified lag will be lost.

  See Also:

  Chapter 8, "Data Guard Broker Properties" for more information

• FastStartFailoverAutoReinstate

  The FastStartFailoverAutoReinstate configuration property controls whether the former primary database is automatically reinstated if a fast-start failover occurred because the primary database crashed or was stalled for longer than FastStartFailoverThreshold seconds. The default value for FastStartFailoverAutoReinstate is TRUE.

  If you want to perform diagnostic or repair work after failover has completed, you can avoid an automatic reinstatement by setting the FastStartFailoverAutoReinstate configuration property to FALSE.

  Note:

  The former primary database is never automatically reinstated if a fast-start failover occurred because a user configurable fast-start failover condition was detected or because an application initiated a fast-start failover by calling the DBMS_DG.INITIATE_FS_FAILOVER function.

4.7.2 Configure Conditions for Fast-start Failover

By default, a fast-start failover is done when neither the observer nor the standby can reach the primary after the configured time threshold (FastStartFailoverThreshold) has passed. There are also other conditions under which you might want a fast-start failover to occur.

The configurable conditions fall into two classes: those detected through the database health-check mechanism and those detected through errors raised by the Oracle server (such as ORA errors). When a specified condition occurs, the observer will initiate a fast-start failover without waiting for FastStartFailoverThreshold to expire, assuming the standby is in a valid state to accept a failover.

Each condition may be enabled or disabled individually. The Data Guard configuration persists all user specified configurable fast-start failover conditions in the broker configuration file.

The observer will detect when the primary database has signaled any of the enabled health-check conditions and will immediately initiate a fast-start failover, assuming the standby is in a valid fast-start failover state (observed and either synchronized or within lag limits) to accept a failover.

For specified Oracle ORA-Error conditions, the primary database will notify the observer if the error is signaled and the observer will immediately initiate a fast-start failover, assuming the standby is in a valid fast-start failover state (observed and either synchronized or within lag limits) to accept a failover.

4.7.3 Application Initiated Fast-Start Failover

Use the DBMS_DG PL/SQL package to enable an application to initiate a fast-start failover when it encounters specific conditions. When a condition uniquely known to the application is detected, it may call the DBMS_DG.INITIATE_FS_FAILOVER procedure, thus alerting the primary database that it wants a fast-start failover to occur immediately. The primary database will notify the observer of this and the observer will immediately initiate a fast-start failover, assuming the standby is in a valid fast-start failover state (observed and either synchronized or within lag limits) to accept a failover.If the configuration is not failable, the DBMS_DG.INITIATE_FS_FAILOVER procedure will return an ORA error number (not signal an exception) informing the caller that a fast-start could not be performed.