链接：https://pan.baidu.com/s/1EqlZcnURrnbhQGgdRKjIJA 

提取码：kk6j

Introduction

The Oracle Maximum Availability Architecture (MAA) with Oracle Data Guard provides the most 

comprehensive solution available to eliminate single points of failure for mission critical Oracle 

Databases. It prevents data loss and downtime in the simplest and most economical manner by 

maintaining one or more synchronized physical replicas of a production database at a remote location. 

If the production database becomes unavailable for any reason, client connections can quickly, and in 

some configurations transparently, failover to a synchronized replica to immediately restore service. 

Active Data Guard extends basic Data Guard capabilities to eliminate the high cost of idle redundancy 

by enabling reporting applications, ad-hoc queries, data extracts, and fast incremental backups to be 

offloaded to read-only copies of the production database. Active Data Guard’s complete focus on real￾time data protection and availability and its deep integration with the Oracle Database eliminates

compromises in data protection, performance, availability and complexity found in storage remote 

mirroring or other host-based replication solutions.

Data Guard and Active Data Guard are the only Oracle-aware replication solutions can guarantee zero 

data loss failover to an already running, synchronized copy of a production database. New capabilities 

with Active Data Guard 12c extend zero data loss protection using synchronized replicas located at 

any distance from the production database, without impacting production database performance or 

adding complexity to failover operations. This provides both high availability and data protection for the 

Oracle database in the event of database, cluster, site, region, and geographic outages.

This paper provides Oracle MAA best practices for using synchronous redo transport in a Data Guard 

or Active Data Guard configuration. It is designed for database administrators who have a working 

knowledge of Data Guard and Active Data Guard configurations using Maximum Availability or 

Maximum Protection modes. These are the modes where the integration of synchronous redo 

transport with the Data Guard managed recovery process (MRP) provides a guarantee of zero data 

loss should there be an unplanned outage of the production database.

.1 | BEST PRACTICES FOR SYNCHRONOUS REDO TRANSPORT

2 | BEST PRACTICES FOR SYNCHRONOUS REDO TRANSPORT

Data Guard Synchronous Transport – an Overview

A Data Guard configuration includes a production database referred to as the primary database, and up to 30 

directly connected replicas referred to as standby databases. Primary and standby databases connect over TCP/IP 

using Oracle Net Services. There are no restrictions on where the databases are physically located provided they 

can communicate with each other. A standby database is initially created from a backup of the primary database. 

Data Guard automatically synchronizes the primary database and all standby databases by transmitting primary 

database redo - the information used by every Oracle Database to protect transactions - and applying it to the 

standby database.

Data Guard transport services handle all aspects of transmitting redo from a primary to a standby databases(s). As 

users commit transactions at a primary database, redo records are generated and written to a local online log file. 

Data Guard transport services simultaneously transmit the same redo directly from the primary database log buffer 

(memory allocated within system global area) to the standby database(s) where it is written to a standby redo log 

file. Data Guard transport is very efficient for the following reasons:

» Data Guard’s direct transmission from memory avoids disk I/O overhead on a primary database. This is different 

from how many other host-based replication solutions increase I/O on a primary database by reading data from 

disk and then transmitting the changes. 

» Data Guard transmits only database redo. This is in stark contrast to storage remote-mirroring which must 

transmit every changed block in every file in order to maintain real-time synchronization. Oracle tests have shown 

that storage remote-mirroring transmits up to 7 times more network volume, and 27 times more network I/O 

operations than Data Guard. For a more complete discussion of the advantages of Data Guard compared to 

storage remote-mirroring solutions refer to Oracle Active Data Guard vs Storage Remote Mirroring.1

Data Guard offers two choices of transport services: synchronous and asynchronous. Synchronous redo transport -

the subject of this paper - requires a primary database to wait for confirmation from the standby that redo has been 

received and written to disk (a standby redo log file) before commit success is signaled to the application. 

Synchronous transport combined with the deep understanding of transaction semantics by Data Guard apply 

services provides a guarantee of zero data loss protection should the primary database suddenly fail.

Data Guard also provides three different modes of operation that help users balance cost, availability, performance, 

and data protection - shown in Table 1. Each mode defines the behavior of the Data Guard configuration if a 

primary database loses contact with its standby. Two of the three modes use synchronous transport.

TABLE 1: DATA GUARD PROTECTION MODES

Mode Risk of data loss Transport If no acknowledgement from the standby database, then:

Maximum 

Protection

Zero data loss

Double failure protection

SYNC Signal commit success to the application only after acknowledgement is 

received from a standby database that redo for that transaction has been 

hardened to disk. The production database cannot proceed until 

acknowledgement has been received.

Maximum 

Availability

Zero data loss

Single failure protection

SYNC

FAST SYNC

FAR SYNC

Signal commit success to the application only after acknowledgement is 

received from a standby database or after NET_TIMEOUT threshold 

period expires – whichever occurs first. A network or standby database 

outage does not affect the availability of the production database.

Maximum 

Performance

Potential for

minimal data loss

ASYNC Primary never waits for standby acknowledgment to signal commit 

success to the application. There can be no guarantee of zero data loss.

 1 http://www.oracle.com/technetwork/database/availability/dataguardvsstoragemirroring-2082185.pdf

Synchronous Transport Performance

Data Guard also provides a number of performance advantages compared to synchronous solutions based upon

storage remote- mirroring. Recall from previous discussion that Data Guard only transmits redo. Storage remotemirroring, in contrast, must transmit every change to every block to maintain the same real-time protection offered 

by Data Guard. This means storage remote-mirroring transmits the volume of data transmitted by Data Guard plus

all writes to: data files, additional members of online log file groups, archived log files, control file, flashback log files, 

etc. The impact is significant. For example, the Oracle process that writes to data files is called Database Writer 

(DBWR) and anything that slows down DBWR can have a significant impact on database performance. 

Synchronous storage remote mirroring will impact DBWR by design, because each write by DBWR is delayed by 

the round trip network latency (RTT) between mirrored volumes. Data Guard is designed never to affect DBWR on 

the primary database.

Oracle has conducted numerous tests to characterize the impact of synchronous transport on a production 

database. The results of two representative tests are provided below. This data provides a general perspective on 

performance impact – it should not be used to extrapolate an expected impact for your production workloads. 

Each application will have a different tolerance for synchronous replication. Differences in application concurrency, 

number of sessions, the transaction size in bytes, how often sessions commit, and log switch frequency – result in

differences in impact from one application to the next even if round-trip network latency (RTT), bandwidth and log 

file write i/o performance are all equal. In general Oracle sees customers having greater success with synchronous 

transport when round trip network latency is less than 5ms, than when latency is greater than 5ms. Testing is always 

recommended before drawing any specific conclusions on the impact of synchronous replication on your workloads.

Test 1: OLTP Workload, Small Inserts 

Swingbench, (a public domain load generator2

) was used to simulate OLTP workload that generated redo at a rate 

of 30MB/second. Results showed 3% performance impact at 1ms RTT and 5% impact at 5ms RTT (see Figure 1).