Oracle GoldenGate Bounded Recovery (BR) Deep Dive

Why Bounded Recovery Matters

In GoldenGate Extract, restart time is driven by the oldest open transaction. In real-world systems, such transactions can span hours or even days, significantly impacting recovery time after a failure.

Without Bounded Recovery (BR)

• Crash / restart → Extract must re-mine redo starting from the recovery checkpoint (SCN of the oldest open transaction)
• Extensive redo scanning leads to high I/O overhead
• Longer restart times
• Lag spikes and delayed catch-up

With Bounded Recovery (BR)

• Extract periodically persists the state of long-running transactions to disk
• On restart, Extract restores this state instead of rebuilding everything from redo
• Significantly reduces redo scanning
• Enables predictable and faster recovery times

Rule of Thumb – Maximum recovery time is typically bounded to ~2 × BRINTERVAL

---

The Three Checkpoints You Must Understand

Current Checkpoint  → Last processed position in the redo stream
Recovery Checkpoint → SCN of the oldest open transaction
BR Checkpoint

 → Persisted snapshot of in-flight transaction state

How they work together:

• Current checkpoint tracks Extract’s progress in the redo stream
• Recovery checkpoint ensures correctness by identifying where recovery must begin
• BR checkpoint optimizes recovery by persisting long-running transaction state

Key Insight

Recovery always honors the oldest open transaction (recovery checkpoint), but Bounded Recovery allows Extract to restore transaction state from disk instead of rebuilding everything from redo.

Bounded Recovery Internals (How BR Actually Works)

While Oracle GoldenGate does not explicitly define internal components like “Preparer” or “Builder,” the Bounded Recovery (BR) mechanism can be logically understood in the following conceptual phases.

These phases describe how Extract analyzes redo, reconstructs transaction state, and avoids expensive reprocessing during restart.

Phase 1: Redo Analysis

During both normal operation and recovery, Extract scans redo logs (online and archived) to:

• Identify transaction boundaries (BEGIN / COMMIT)
• Track transaction start SCNs
• Capture change vectors (DML operations)
• Maintain awareness of in-flight (open) transactions

Goal: Understand what transactions exist and their current state

Phase 2: State Reconstruction

During restart, Extract rebuilds its in-memory transaction state by:

• Loading persisted BR files (if available)
• Supplementing with redo log data as needed
• Restoring transaction ordering and completeness

If BR files are not available or usable, Extract falls back to standard recovery and reconstructs everything from redo logs.

Goal: Rebuild what was previously held in memory efficiently

Phase 3: State Persistence (Bounded Recovery)

To minimize recovery time, Extract periodically persists the state of long-running transactions to disk:

• Transaction fragments (partial changes)
• SCN positions and progress markers
• Ordering and dependency information

These files are stored under the configured: BRDIR

Goal: Avoid rebuilding long-running transactions entirely from redo during restart

---

Normal vs Crash Recovery

Normal Flow

Redo → Extract → Memory Cache → Trail ↓ BR checkpoint (periodic persist)

Crash (Without Bounded Recovery)

Restart → Begin from recovery checkpoint (SCN of oldest open txn) → Scan redo logs (online + archive) → Reconstruct in-memory transaction state → Resume (slow)

Crash (With Bounded Recovery)

Restart → Load BR files (persisted txn state) → Minimal redo scan to catch up → Resume (fast)

Bounded Recovery does not change the recovery starting point—it reduces how much redo must be reprocessed by restoring long-running transaction state from disk.

---

Redo vs Archive Logs: Why Extract Reads Both

Extract mines changes from:

• Online Redo Logs → Capture current, active transactions
• Archived Redo Logs → Retrieve older changes when required

When Does Extract Read from Archive Logs?

Extract switches to archived logs when it needs redo from an earlier SCN, such as:

• Restart after downtime
• Presence of long-running transactions
• Replication lag requiring older redo
• Recovery scenarios (including BR-assisted recovery)

Extract follows SCN continuity, not time. It must read all redo required to reconstruct transactions correctly, regardless of whether the data resides in online or archived logs.

What If Archive Logs Are Missing?

Scenario

• Oldest open transaction started at SCN X
• Required archive logs containing SCN X are no longer available

Outcome

Extract ABENDS → Missing log / SCN not found

• Extract cannot reconstruct the transaction safely
• Data integrity cannot be guaranteed
• Replication process stops

Where Bounded Recovery Helps (and Where It Doesn’t)

Helps by:

• Persisting state of long-running transactions
• Reducing how far back Extract needs to read redo

But does NOT:

• Eliminate redo dependency entirely
• Remove the need for required archive logs

Best Practice

Ensure archive log retention is aligned with the longest transaction duration and potential recovery window to avoid Extract failures.

If redo is missing, recovery is impossible, Bounded Recovery optimizes, but does not replace redo.

---

Best Practices for Archive Retention

To ensure successful recovery and avoid Extract failures:

Set archive log retention to cover:

• Longest transaction duration
• Expected restart window + safety buffer

This ensures:

• Required redo is always available
• Extract can reconstruct transactions during recovery
• Avoids failures due to missing archive logs

Bounded Recovery Configuration

Example Extract parameter configuration:

BR BRINTERVAL 2H BRDIR ./br

Parameter Explanation

• BR Enables Bounded Recovery for Extract
• BRINTERVAL Defines how frequently Extract persists transaction state to disk *(Default is ~4 hours, tuning depends on workload and recovery requirements)*
• BRDIR Directory where BR files are stored

Should be placed on fast, low-latency storage (SSD/NVMe)

Keep BR enabled with an optimal interval (typically 2–4 hours) and ensure BR files are stored on high-performance storage for efficient recovery. Good archive retention ensures recovery is possible, Bounded Recovery ensures it is fast.

---

Performance Tuning Playbook

1. Pick the Right BR Interval

• 2–4 hours is the typical sweet spot
• Too low → excessive I/O overhead from frequent persistence
• Too high → longer recovery window after restart

Balance recovery speed vs runtime overhead

2. Use Fast Storage for BRDIR

• NVMe / SSD (low latency)
• Slow NFS or high-latency mounts

BR is write-heavy during runtime and read-sensitive during recovery—storage performance directly impacts restart speed.

3. Fix the Root Cause: Long Transactions

• Break large batch operations
• Commit more frequently
• Avoid multi-hour transactions

This is the single biggest optimization for both runtime performance and recovery efficiency.

4. Align Archive Log Retention

Retention ≥ longest transaction duration + safety buffer

• Ensures required redo is always available
• Prevents Extract failures during recovery

5. Prefer Integrated Extract (Where Applicable)

• Uses the database mining server
• Better scalability and stability compared to classic Extract
• Especially beneficial for high-volume environments

6. Balance Redo Generation

Avoid:

• Huge monolithic commits
• Large LOB-heavy transactions

Prefer:

• Steady, evenly distributed workload

Balanced redo = smoother Extract processing and reduced recovery pressure

7. Ensure Adequate Memory

• Avoid excessive spill to disk
• Ensure sufficient memory for Extract cache

Stable memory usage leads to smoother BR checkpoints and better performance

8. Monitor Long Transactions Early

WARNLONGTRANS 2H

• Detect long-running transactions proactively
• Identify problematic sessions before they impact recovery

9. Avoid Frequent Restarts

• Each restart triggers recovery logic
• Increases redo scanning and system load

Stability is key—fix root causes instead of relying on restarts, GoldenGate Extract performance is not just about configuration, it’s about transaction design, redo management, and system balance.

IMP – You don’t tune Bounded Recovery alone—you tune the system that creates the need for it.

---

Observability & What to Look For

Effective monitoring is critical to ensure Bounded Recovery (BR) is working as expected and to quickly identify recovery or performance issues.

Extract Report File

The Extract report file is your primary source of truth. Look for:

• Regular BR checkpoints Confirms BR is active and persisting state as expected
• Messages about long-running transactions Indicates transactions exceeding BR interval and being tracked
• Recovery behavior after restart Check whether Extract, Uses BR files (fast recovery), Falls back to standard recovery (longer redo scan)

Database Views & Logs

Correlate Extract behavior with database activity:

• Long-running transactions Typically from application workload Directly impact recovery time and BR usage
• Archive log generation and retention Ensure required redo is available Prevent Extract failures due to missing logs

Observability should focus on both Extract behavior and database workload—Bounded Recovery effectiveness depends on both.

Optional Add (if you want deeper credibility)

You can include:

• Monitor Extract lag and checkpoint movement
• Track archive log deletion policies vs transaction patterns

If you can’t observe Bounded Recovery, you can’t trust your recovery time.

---

Real-World Use Cases

Case 1: Long-Running Transaction + Crash

Scenario: A transaction runs for ~10 hours and Extract crashes before it commits.

• Without Bounded Recovery: Extract must re-mine redo from the start SCN of that transaction → Significant redo scanning → Long restart time
• With Bounded Recovery: Extract restores transaction state from BR files → Minimal redo reprocessing → Faster and predictable recovery

Case 2: High Redo Volume System + Restart

Scenario: System generates a large volume of redo and Extract restarts under load.

• Without Bounded Recovery: Extensive redo mining required → High I/O overhead → Slow catch-up and lag buildup
• With Bounded Recovery: Reduced redo scanning due to persisted state → Faster recovery → Predictable restart behavior

Case 3: Missing Archive Logs

Scenario: Required archive logs for recovery are no longer available.

• Outcome: Extract abends with missing log / SCN error → Recovery cannot proceed → Data integrity cannot be guaranteed
• Fix:
• Increase archive log retention
• Align retention policy with transaction patterns and recovery window

Bounded Recovery improves restart performance, but it cannot compensate for missing redo logs—proper archive retention remains critical.

---

Strong Takeaways

• BR bounds recovery time—not runtime.
• Redo is the source of truth, BR is the shortcut.
• Recovery starts from the oldest open txn, but BR avoids rebuilding it from scratch.
• Missing archive logs cause failure—not slowdown.

---

Quick Troubleshooting Checklist

Slow Restart?

Check:

• BRINTERVAL too high → increases recovery window
• Presence of long-running transactions → drives recovery checkpoint backward

Extract Abends on Restart?

Likely cause:

• Missing archive logs

Action:

• Increase archive log retention
• Align retention with transaction duration and recovery requirements

High I/O During Restart?

Likely cause:

• Excessive redo re-mining

Action:

• Ensure Bounded Recovery is enabled
• Verify BRDIR is on fast storage (SSD/NVMe)

Frequent Lag Spikes?

Likely cause:

• Inefficient transaction patterns

Action:

• Review batch sizes
• Increase commit frequency
• Avoid large, long-running transactions

---

Final Takeaway

Bounded Recovery does not replace standard recovery—it optimizes it by reducing redo reprocessing for long-running transactions.

What You Gain

• Faster, more predictable restarts
• Reduced lag spikes after failures
• Lower redo reprocessing overhead

What Still Matters Most

True performance optimization comes from:

• Good transaction design (avoid long-running transactions)
• Proper archive log retention (ensure redo availability)
• Fast, low-latency storage (for both redo and BR files)

Bounded Recovery is a powerful safety net—but it cannot compensate for poor transaction patterns or missing redo logs.

Optimize your transactions first—Bounded Recovery will take care of the rest.

###