Oracle Data Guard Protection Modes

6 Oracle Data Guard Protection Modes

Oracle Data Guard lets you set different data protection modes.

See the following topics for information about these modes and how to set them on a primary database:

Oracle Data Guard Protection Modes

Oracle Data Guard provides three protection modes: maximum availability, maximum performance, and maximum protection.

In the following descriptions of the protection modes, a synchronized standby database is meant to be one that meets the minimum requirements of the configured data protection mode and that does not have a redo gap. Redo gaps are discussed in Redo Gap Detection and Resolution.

Maximum Availability

This protection mode provides the highest level of data protection that is possible without compromising the availability of a primary database. Under normal operations, transactions do not commit until all redo data needed to recover those transactions has been written to the online redo log AND based on user configuration, one of the following is true:

redo has been received at the standby, I/O to the standby redo log has been initiated, and acknowledgement sent back to primary
redo has been received and written to standby redo log at the standby and acknowledgement sent back to primary

If the primary does not receive acknowledgement from at least one synchronized standby, then 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.

If the primary database fails, then this mode ensures no data loss occurs provided there is at least one synchronized standby in the Oracle Data Guard configuration. See "Performance Versus Protection in Maximum Availability Mode" for information about the redo transport settings necessary to support Maximum Availability and associated trade-offs.

Transactions on the primary are considered protected as soon as Oracle 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 Oracle 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. Oracle Data Guard signals any corruptions that are detected so that immediate corrective action can be taken.

Performance Versus Protection in Maximum Availability Mode

When you use Maximum Availability mode, it is important to understand the possible results of using the LOG_ARCHIVE_DEST_n attributes SYNC/AFFIRM versus SYNC/NOAFFIRM (FastSync) so that you can make the choice best suited to your needs.

When a transport is performed using SYNC/AFFIRM, the primary performs write operations and waits for acknowledgment that the redo has been transmitted synchronously to the physical standby and written to disk. A SYNC/AFFIRM transport provides an additional protection benefit at the expense of a performance impact caused by the time required to complete the I/O to the standby redo log.

When a transport is performed using SYNC/NOAFFIRM, the primary performs write operations and waits only for acknowledgement that the data has been received on the standby, not that it has been written to disk. The SYNC/NOAFFIRM transport can provide a performance benefit at the expense of potential exposure to data loss in a special case of multiple simultaneous failures.

With those definitions in mind, suppose you experience a catastrophic failure at the primary site at the same time that power is lost at the standby site. Whether data is lost depends on the transport mode being used. In the case of SYNC/AFFIRM, in which there is a check to confirm that data is written to disk on the standby, there would be no data loss because the data would be available on the standby when the system was recovered. In the case of SYNC/NOAFFIRM, in which there is no check that data has been written to disk on the standby, there may be some data loss.

See Also:

LOG_ARCHIVE_DEST_n Parameter Attributes for more information about the SYNC, AFFIRM, and NOAFFIRM attributes
Oracle Data Guard Broker for information about transporting redo in a broker configuration using FASTSYNC mode (using SYNC and NOAFFIRM together in maximum availability mode)

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 the time required to transmit redo data and receive acknowledgment from a standby database.

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.

Maximum Protection

Maximum protection is similar to maximum availability but provides an additional level of data protection in the event of multiple failure events. Unlike maximum availability, which allows the primary to continue processing if it is unable to receive acknowledgement from a standby database, maximum protection shuts the primary database down rather than allowing it to continue processing transactions that are unprotected.

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.

Note:

Asynchronously committed transactions are not protected by Oracle Data Guard against loss until the redo generated by those transactions has been written to the standby redo log of at least one synchronized standby database.

For more information about the asynchronous commit feature, see:

Setting the Data Protection Mode of a Primary Database

Protection mode settings can be set and changed on an open database as long as the configuration meets the requirements of the protection mode (including going from maximum performance mode to maximum availability mode).

Perform the following steps to set the data protection mode of a primary database:

Select a data protection mode that meets your availability, performance, and data protection requirements. See Oracle Data Guard Protection Modes for a description of the data protection modes.

Verify that at least one standby database meets the redo transport requirements for the desired data protection mode.

The LOG_ARCHIVE_DEST_n database initialization parameter that corresponds to at least one standby database must include the redo transport attributes listed in the following table for the desired data protection mode.

The standby database must also have a standby redo log.

Table 6-1 Required Redo Transport Attributes for Data Protection Modes

Maximum Availability	Maximum Performance	Maximum Protection
`AFFIRM` or `NOAFFIRM`	`NOAFFIRM`	`AFFIRM`
`SYNC`	`ASYNC`	`SYNC`
`DB_UNIQUE_NAME`	`DB_UNIQUE_NAME`	`DB_UNIQUE_NAME`

Verify that the DB_UNIQUE_NAME database initialization parameter has been set to a unique value on the primary database and on each standby database.
Verify that the LOG_ARCHIVE_CONFIG database initialization parameter has been defined on the primary database and on each standby database, and that its value includes a DG_CONFIG list that includes the DB_UNIQUE_NAME of the primary database and each standby database.
The following sample SQL statement configures the LOG_ARCHIVE_CONFIG parameter:
```
SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(CHICAGO,BOSTON)';
```
Set the data protection mode by executing the following SQL statement on the primary database:
```
SQL> ALTER DATABASE -
> SET STANDBY DATABASE TO MAXIMIZE {AVAILABILITY | PERFORMANCE | PROTECTION};
```
The data protection mode can be set to MAXIMUM PROTECTION on an open database only if the current data protection mode is MAXIMUM AVAILABILITY and if there is at least one synchronized standby database.
Perform the following query on the primary database to confirm that it is operating in the new protection mode:
```
SQL> SELECT PROTECTION_MODE FROM V$DATABASE;
```