Understanding Oracle Data Guard Protection Modes: Max Performance, Availability, and Protection

Overview

Oracle Data Guard (DG) provides high‑availability (HA) for Oracle databases by synchronizing redo logs between a primary and one or more standby databases. The core concept is the protection mode, which determines how strictly redo data must be transferred and acknowledged before a transaction is considered committed.

Three Protection Modes

Maximum Performance prioritises primary database throughput; transactions commit as soon as redo is written locally, while standby receipt is asynchronous. This mode offers the least data protection but has minimal impact on performance and is the default mode.

Maximum Availability provides the highest protection without sacrificing availability. Transactions commit only after redo is written to both the primary online redo log and at least one synchronized standby redo log. If the standby becomes unavailable, DG automatically degrades to Maximum Performance.

Maximum Protection guarantees zero data loss. A transaction commits only after redo is safely stored on the primary and a synchronized standby. If the standby cannot receive redo, the primary shuts down to prevent data loss.

Test Environment

The author used Oracle 11gR2 (11.2.0.4) with a primary database (VLIFE) and a physical standby (VLIFE‑SB). The primary was initially in Maximum Performance mode. Sample queries show the database role and protection mode:

SQL> select name, open_mode, database_role, protection_mode from v$database;
NAME   OPEN_MODE   DATABASE_ROLE   PROTECTION_MODE
VLIFE  READ WRITE  PRIMARY         MAXIMUM PERFORMANCE

Archive destination parameters were displayed to confirm synchronous and asynchronous transport settings.

Maximum Availability Mode Test

To switch from Maximum Performance to Maximum Availability, the archive destination was altered to synchronous mode with affirmation, and the protection mode was changed using:

SQL> alter system set log_archive_dest_2='SERVICE=vlifesb sync affirm net_timeout=30 valid_for=(online_logfiles,primary_role) db_unique_name=vlifesb';
SQL> alter database set standby database to maximize availability;

After the change, the primary reported MAXIMUM AVAILABILITY. Log transport initially became unsynchronized, prompting DG to accelerate log shipping. The standby caught up, and a test table created on the primary was visible on the standby.

Failure Scenarios

The author simulated network and listener failures. Stopping the listener on the standby caused the primary to continue processing transactions while logs accumulated without being applied. Manual log switches ( alter system switch logfile;) and log status queries demonstrated that redo was not reaching the standby.

When the listener was restarted and the standby began applying archived logs, the databases resynchronized, and the test table remained consistent.

Observations and Conclusions

The experiments show that Maximum Availability behaves like Maximum Protection when the transport path is healthy, ensuring strict synchronization. If the standby becomes unreachable, DG automatically falls back to Maximum Performance, allowing the primary to keep running while sacrificing strict data protection. This adaptive behavior makes Maximum Availability a practical choice for environments that require both high availability and reasonable data safety.