Protection Modes

---

Determining the protection mode in which you operate your Data Guard configuration is one of the most important decisions you will make while configuring your disaster recovery solution. At the heart of this decision lies the answer to one question-how much data are you willing to lose? Naturally, everyone answers none. But as we well know from everyday life, there is no such thing as a free lunch. Data Guard can provide you with guaranteed no data loss but your management chain must be willing to spend the money necessary to provide the resources to support this protection mode. If management is unwilling to part with the funds, we must reconsider our first question-how much data are you willing to lose? Thankfully, Data Guard provides us with three options when it comes to protection modes, each offering a different level of protection to suit our business needs and abilities. First let's examine what each protection mode offers, and then we will ask some questions that will help you decide which is best for you.

Maximum Protection

To provide this level of protection, the redo data needed to recover each transaction must be written to both the local redo log and to a standby redo log on at least one standby database before the transaction commits. To ensure that data loss cannot occur, the primary database will shut down if a fault prevents it from writing its redo stream to at least one remote standby redo log.

To participate in maximum protection, the following requirements must be met:

• The primary must use the LGWR SYNC AFFIRM attributes in the archive destination used to archive to the standby.

• The standby must be configured with standby redo logs.

• At least one standby must be available.

By using the LGWR SYNC AFFIRM attributes in the archive destination going to the standby, we are stating that a commit complete message will not be returned to the user until we have successfully written the redo change into the standby redo logs on the standby host. Only after that write has been confirmed can the user continue with other transactions. As you can see, the speed of the network will have a great impact on the speed at which commits on the primary database can complete. You would not want to have your standby participating in maximum protection mode over a WAN or over a high latency network. A good recommendation for maximum protection mode is to have at least two standby databases available to satisfy the primary's requirements for maximum protection with one of the standby databases available on a high-speed low-latency network.

Maximum Availability

Maximum availability offers the next highest level of data protection while minimizing the impact on availability of the primary database. In the same manner as maximum protection mode, we do not return a commit complete message to the user until we have guaranteed that the redo has been completely written locally and into the standby redo log of at least one standby database. If for some reason the standby becomes unavailable and the primary is unable to write into the standby redo log, the primary database is not shut down. Instead, the primary database will temporarily drop its protection mode to maximum performance (using the ARC process) and continue. Once the standby becomes available, gap resolution with the primary will occur-in which any archivelog gaps will be filled. At the next log switch on the primary, the protection mode will once again be raised to maximum availability.

To participate in maximum availability, the following requirements must be met:

• The primary must use the LGWR SYNC AFFIRM attributes in the archive destination used to archive to the standby.

• The standby must be configured with standby redo logs.

• At least one standby must be available.

We can see by the above requirement to utilize LGWR SYNC AFFIRM attributes in the remote destination that maximum availability will also be impacted by a slow network. While slow networks will affect the time to return commits to the primary, an error condition will cause the protection mode to temporarily drop, thereby avoiding impact on the primary.

Maximum Performance

The maximum performance protection mode is the default protection mode for any Oracle database. It offers the highest level of database protection without affecting the availability or the performance of the primary database. User transactions on the primary are allowed to commit as soon as the transaction is written to the local online redo logs.

With maximum performance, no specific rules or requirements are enforced. The primary typically uses either the ARCH or LGWR ASYNC attributes in the remote destination going to the standby. The standby does not have to have standby redo logs, although their use is recommended. The primary database is allowed to open even if the standby is not available, unlike maximum availability and maximum protection.

HA Workshop: Changing the Protection Mode

Workshop Notes

When you first create an Oracle database, its protection mode is set to maximum performance by default. Once you have decided which protection mode is best for your business needs/objectives, you will need to change the default mode. Changing the mode involves setting the destination so as to meet the requirements as well as placing the database into the correct mode.

The following example shows how to change the protection mode from the default maximum performance to maximum availability.

Step 1.  Change the initialization parameters for the remote destination.

alter system set log_archive_dest_2=   'SERVICE=Orlando_hasun1   LGWR SYNC AFFIRM    VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)    DB_UNIQUE_NAME=Orlando' scope=both;

Step 2.  Shut down all instances of the primary database and start up in exclusive mode.

shutdown immediate; startup mount exclusive;

Step 3.  Change the protection mode via the ALTER DATABASE command.

alter database set standby to maximize availability;

Step 4.  Open all instances.

---