This mode provides the greatest protection against transaction loss. However using it may result in the longest transaction response time among the four modes.
In this mode, log writes are considered successful only when logs have been written to log files on the primary database and when the primary database has received acknowledgement from the standby database that the logs have also been written to log files on the standby database. The log data is guaranteed to be stored at both sites.
NEARSYNC (near synchronous)
While this mode has a shorter transaction response time than synchronous mode, it also provides slightly less protection against transaction loss.
In this mode, log writes are considered successful only when the log records have been written to the log files on the primary database and when the primary database has received acknowledgement from the standby system that the logs have also been written to main memory on the standby system. Loss of data occurs only if both sites fail simultaneously and if the target site has not transferred to nonvolatile storage all of the log data that it has received.
Compared with the SYNC and NEARSYNC modes, the ASYNC mode results in shorter transaction response times but may cause greater transaction losses if the primary database fails
In ASYNC mode, log writes are considered successful only when the log records have been written to the log files on the primary database and have been delivered to the TCP layer of the primary system's host machine. Because the primary system does not wait for an acknowledgement from the standby system, transactions may be considered committed when they are still on their way to the standby database.
SUPERASYNC (super asynchronous)
This mode has the shortest transaction response time but also has the highest probability of transaction losses if the primary system fails. This mode is useful when one does not want transactions to be blocked or experience elongated response times due to network interruptions or congestion.
In this mode, the HADR pair will never be in peer state or disconnected peer state. The log writes are considered successful as soon as the log records have been written to the log files on the primary database. Because the primary database does not wait for acknowledgement from the standby database, transactions are considered committed irrespective of the state of the replication of that transaction.
Since the transaction commit operations on the primary database are not affected by the relative slowness of the HADR network or the standby HADR server, the log gap between the primary database and the standby database may continue to increase. It is important to monitor the log gap as it is an indirect measure of the potential number of transactions that could be lost should a true disaster occur on the primary system.
In disaster recovery scenarios, any transactions committed during the log gap would not be available to the standby database. Therefore, monitor the log gap by using the hadr_log_gap monitor element. If it occurs that the log gap is not acceptable, investigate the network interruptions or the relative speed of the standby database node and take corrective measures to reduce the log gap.