Oracle Data Guard is widely used to provide disaster recovery and high availability for Oracle databases.
One of the areas that often causes confusion is redo transport.
You will frequently encounter these terms:
- SYNC
- ASYNC
- AFFIRM
- NOAFFIRM
At first, they can look like four different ways of doing the same thing.
They aren’t.
The easiest way to understand them is to separate two questions:
SYNC / ASYNC asks: Does the PRIMARY wait for the standby acknowledgment?
AFFIRM / NOAFFIRM asks: Does the STANDBY wait for redo to be written to persistent storage before sending that acknowledgment?
Once these two questions are separated, the entire concept becomes much easier.
1. Start With the Basic Data Guard Flow
The primary database generates redo whenever transactions modify the database.
That redo is transported to the standby database and eventually applied to the standby datafiles.
A simplified flow looks like this:
PRIMARY DATABASE
|
|
REDO
|
v
REDO TRANSPORT
|
|
v
STANDBY DATABASE
|
|
REDO APPLY
|
v
DATAFILES
There are two different activities here:
Redo Transport
Moving redo from the primary to the standby.
Redo Apply
Applying the received redo on the standby.
SYNC, ASYNC, AFFIRM and NOAFFIRM are related to redo transport and acknowledgment behavior.
They should not be confused with the redo apply process.
2. The First Question: Does the Primary Wait?
This is where SYNC vs ASYNC comes in.
Imagine that the primary generates redo.
The primary sends that redo toward the standby.
Now ask:
Does the primary wait for an acknowledgment from the standby?
There are two possibilities.
3. SYNC — The Primary Waits
With synchronous redo transport, the primary waits for the required acknowledgment from the standby.
Conceptually:
PRIMARY STANDBY
REDO ------------------------>
|
| Receive REDO
|
| ACK
|
<-----------------------------+
Primary continues
with commit processing
The important point is:
SYNC = Primary waits for acknowledgment.
The standby is therefore part of the primary’s commit path.
This is why network latency becomes important when synchronous transport is used.
If the standby is located very far away, the round-trip network latency can increase transaction response time.
4. ASYNC — The Primary Doesn’t Wait
With asynchronous transport, the primary sends redo but does not wait for the standby acknowledgment before completing the transaction.
Conceptually:
PRIMARY STANDBY
REDO ------------------------>
Commit completes
without waiting
The standby can continue receiving and applying redo independently.
The important point is:
ASYNC = Primary doesn’t wait for the standby acknowledgment.
Notice something important:
ASYNC does not mean redo isn’t sent.
Redo is still transported.
The difference is simply that the primary doesn’t wait for the acknowledgment.
5. SYNC and ASYNC: Same Job, Different Waiting Behavior
This is the first major concept.
Both SYNC and ASYNC perform the same fundamental job:
Transport redo from the primary to the standby.
The difference is what happens to the primary while the standby is receiving that redo.
REDO TRANSPORT
REDO
PRIMARY --------------------------------> STANDBY
|
|
+---- SYNC → Primary waits
|
+---- ASYNC → Primary doesn't wait
So the easiest way to remember it is:
SYNC = WAIT
ASYNC = DON’T WAIT
6. Now Forget SYNC and ASYNC for a Moment
The second concept is AFFIRM vs NOAFFIRM.
AFFIRM and NOAFFIRM answer a different question.
The question is:
When the standby receives redo, does it wait for the redo to be written to persistent storage before acknowledging the primary?
Now we’re looking at the standby’s behavior.
7. AFFIRM — Standby Persists Before Acknowledgment
With AFFIRM, the standby acknowledges the received redo only after the redo has been written to persistent storage.
Conceptually:
PRIMARY STANDBY
REDO ------------------------>
|
| Receive REDO
|
v
Write to SRL
|
v
ACK
|
<-----------------------------+
The sequence is:
Receive REDO
↓
Write REDO to persistent storage
↓
Send ACK
So:
AFFIRM = Standby waits for persistence before acknowledgment.
This gives the acknowledgment a stronger durability meaning.
The standby is essentially saying:
“I have received the redo and written it to persistent storage.”
8. NOAFFIRM — Standby Doesn’t Wait for Persistence
With NOAFFIRM, the standby doesn’t wait for the redo to be persisted before sending the acknowledgment.
Conceptually:
PRIMARY STANDBY
REDO ------------------------>
|
| Receive REDO
|
ACK
|
<-----------------------------+
|
v
Write to storage
The sequence is conceptually:
Receive REDO
↓
Send ACK
↓
Persistence happens
Therefore:
NOAFFIRM = Standby doesn’t wait for persistence before acknowledgment.
This can reduce acknowledgment latency.
9. Now Put the Two Concepts Together
This is where most of the confusion disappears.
There are two different questions.
Question 1 — SYNC or ASYNC
Does the PRIMARY wait?
SYNC
↓
YES
ASYNC
↓
NO
Question 2 — AFFIRM or NOAFFIRM
Does the STANDBY wait for persistence before acknowledging?
AFFIRM
↓
YES
NOAFFIRM
↓
NO
So:
DATA GUARD REDO TRANSPORT
PRIMARY
|
| REDO
v
STANDBY
|
|
+------------+------------+
| |
SYNC / ASYNC AFFIRM /
| NOAFFIRM
| |
v v
PRIMARY WAITING STANDBY
BEHAVIOR ACK BEHAVIOR
This is the key to understanding the entire topic.
10. A Simple Human Example
Imagine you send an important document to another office.
There are two separate questions.
Question 1: Do you wait for the other office?
SYNC
You say:
“I will wait until you acknowledge receipt.”
ASYNC
You say:
“Send it when you can. I’m continuing with my work.”
That’s SYNC vs ASYNC.
Question 2: What does the other office do before acknowledging?
AFFIRM
They say:
“I’ve received the document and safely stored it. Now I’ll acknowledge.”
NOAFFIRM
They say:
“I’ve received the document. I’ll acknowledge now and persist it afterward.”
That’s AFFIRM vs NOAFFIRM.
11. The Most Important Visual
Think of the complete flow as two decisions:
PRIMARY
|
| REDO
v
STANDBY
|
|
+-----------+-----------+
| |
SYNC/ASYNC AFFIRM/
| NOAFFIRM
| |
v v
Does PRIMARY Does STANDBY
WAIT? wait for persistence
before ACK?
SYNC / ASYNC
Controls the primary-side waiting behavior.
AFFIRM / NOAFFIRM
Controls the standby-side acknowledgment behavior.
12. Why SYNC + AFFIRM Is Important
Consider:
PRIMARY STANDBY
REDO ------------------------>
|
| Write to SRL
|
v
Persistent
storage
|
|
<---------------------------- ACK
Commit completes
Here:
SYNC
The primary waits.
AFFIRM
The standby waits for persistence before acknowledging.
Therefore the acknowledgment from the standby represents a stronger durability condition.
The trade-off is that transaction latency can be affected by:
- Network latency
- Standby storage latency
- Standby availability
This is why synchronous transport requires careful architecture.
13. Why ASYNC Is Common for Long-Distance DR
Imagine:
PRIMARY
Frankfurt
|
|
| WAN
|
|
STANDBY
Another geographic location
If SYNC is used, network round-trip time can become part of the commit path.
With ASYNC:
PRIMARY
|
+----------------------> STANDBY
|
+--> Commit continues
The primary doesn’t wait for the standby.
This makes ASYNC particularly useful when the standby is geographically distant and network latency is significant.
The trade-off is that redo generated immediately before a primary failure may not yet have reached the standby.
14. SYNC vs ASYNC Does Not Mean “Fast vs Slow”
This is another important point.
It is tempting to say:
“SYNC is slow and ASYNC is fast.”
That’s not technically precise.
The real difference is:
SYNC introduces standby acknowledgment into the primary’s commit path.
ASYNC removes that wait from the primary’s commit path.
Whether SYNC actually causes a noticeable performance impact depends on factors such as:
- Network round-trip latency
- Network reliability
- Standby responsiveness
- Storage performance
- Workload characteristics
- Transaction rate
15. AFFIRM vs NOAFFIRM Does Not Mean “Redo Is Stored vs Not Stored”
Another common misunderstanding:
“NOAFFIRM means the redo isn’t written to disk.”
That’s wrong.
NOAFFIRM does not mean the redo will never be persisted.
The distinction is about when the acknowledgment is generated relative to persistence.
Conceptually:
AFFIRM
Receive
↓
Persist
↓
ACK
NOAFFIRM
Receive
↓
ACK
↓
Persist
That’s the important distinction.
16. How Protection Modes Fit Into This
Now we can introduce Data Guard protection modes.
Maximum Performance
Normally uses asynchronous transport.
The primary doesn’t wait for the standby.
The objective is to minimize the impact on primary performance.
There can be a potential data-loss window if the primary fails before some redo reaches the standby.
Maximum Availability
Designed to provide strong data protection while preserving primary availability if the synchronous standby becomes temporarily unavailable, depending on the configured transport settings.
Synchronous transport is typically used for the required standby.
Maximum Protection
Prioritizes data protection over primary availability.
The primary requires the configured synchronous standby acknowledgment behavior.
If the required standby cannot provide the necessary acknowledgment, the primary may stop processing transactions rather than continue without the required protection.
17. SYNC/ASYNC Is Not the Same as Real-Time Apply
These concepts are often mixed together.
They are different.
SYNC / ASYNC
Concerned with redo transport behavior.
Real-Time Apply
Concerned with redo apply behavior on the standby.
The complete flow is:
PRIMARY
|
| REDO TRANSPORT
|
SYNC / ASYNC
|
v
STANDBY REDO LOG
|
| REDO APPLY
|
v
DATAFILES
Real-Time Apply allows the standby to apply redo from the standby redo logs without waiting for the redo to be archived first.
18. Why Standby Redo Logs Matter
Standby Redo Logs, or SRLs, are an important component of a well-designed Data Guard environment.
The flow is:
PRIMARY
|
| REDO
v
STANDBY REDO LOG
|
v
REDO APPLY
|
v
DATAFILES
SRLs are especially important for:
- Synchronous transport
- Real-time apply
- Low-latency redo application
- RAC Data Guard configurations
For RAC, SRLs must be designed with the individual redo threads in mind.
19. A Practical Example
Suppose an application executes:
UPDATE accounts
SET balance = balance - 1000
WHERE account_id = 100;
COMMIT;
The database generates redo for this transaction.
With ASYNC
Conceptually:
Primary generates REDO
↓
Redo sent toward standby
↓
Primary doesn't wait
↓
Commit completes
The standby may receive and apply the redo shortly afterward.
With SYNC
Conceptually:
Primary generates REDO
↓
Redo sent toward standby
↓
Primary waits for required ACK
↓
ACK received
↓
Commit completes
Now the standby acknowledgment is part of the commit path.
20. The Complete Mental Model
If you’re ever confused, don’t memorize four definitions.
Ask two questions.
Question 1
Who is waiting?
SYNC / ASYNC
↓
PRIMARY
Question 2
What is the standby waiting for?
AFFIRM / NOAFFIRM
↓
STANDBY
↓
PERSISTENCE BEFORE ACK
That’s it.
21. Final Cheat Sheet
|
Concept |
What does it control? |
Simple meaning |
|
SYNC |
Primary behavior |
Primary waits for required ACK |
|
ASYNC |
Primary behavior |
Primary doesn’t wait for ACK |
|
AFFIRM |
Standby ACK behavior |
Standby persists redo before ACK |
|
NOAFFIRM |
Standby ACK behavior |
Standby doesn’t wait for persistence before ACK |
The easiest possible memory trick
SYNC / ASYNC = PRIMARY
AFFIRM / NOAFFIRM = STANDBY
And more specifically:
SYNC = Primary waits
ASYNC = Primary doesn’t wait
AFFIRM = Standby persists before ACK
NOAFFIRM = Standby doesn’t wait for persistence before ACK
Conclusion
SYNC, ASYNC, AFFIRM and NOAFFIRM are not four competing ways of transporting redo.
They describe different parts of the redo transport and acknowledgment process.
The most important distinction is:
SYNC vs ASYNC determines whether the primary waits for the standby acknowledgment.
AFFIRM vs NOAFFIRM determines whether the standby waits for persistence before sending that acknowledgment.
Once you separate primary waiting behavior from standby acknowledgment behavior, the concepts become much easier to understand.
And this distinction matters in real production environments because the choice affects:
- Transaction latency
- Network dependency
- Data protection
- Potential data loss
- Disaster recovery architecture
- Protection mode selection
- Geographic DR design
For an Oracle DBA designing Data Guard, the goal isn’t simply to choose SYNC or ASYNC.
The goal is to understand the RPO, RTO, network characteristics, workload, availability requirements, and durability requirements, and then design the redo transport configuration accordingly.
Comments
Post a Comment