Understanding Bounded Recovery, long-running transactions, archive-log retention, LogMiner, Logdump, and Oracle-to-PostgreSQL replication
By Michael R. Culp — MRC Consulting LLC
September 21, 2026
One of the more interesting Oracle GoldenGate failures occurs when Extract attempts to recover and suddenly requests an Oracle archived redo log from several days ago — but the database only retains one day of archive logs.
Consider this scenario:
Oracle Database
|
| Integrated Extract / LogMiner
v
Oracle GoldenGate Extract
|
v
GoldenGate Trail
|
v
GoldenGate Replicat
|
v
PostgreSQL
GoldenGate stops with an error similar to:
ORA-01292: LogMiner for upstream capture cannot find log file
Further investigation shows that GoldenGate wants redo from approximately seven days ago, while the Oracle database only retains archived redo for one day.
At first glance, this may look like a PostgreSQL replication problem.
It isn't.
The failure is occurring on the Oracle source side, before the changes can even be written to the GoldenGate trail.
For current Oracle Database releases, Oracle defines ORA-01292 as LogMiner being unable to locate a log file it requires in V$ARCHIVED_LOG. Oracle recommends identifying the required thread and SCN from the alert log and trace information and restoring the missing log if it has been deleted or expired.
That tells us something important about the architecture.
With Oracle Integrated Extract:
Oracle Online Redo / Archived Redo
|
v
LogMiner
|
v
GoldenGate Extract
|
v
GoldenGate Trail
If LogMiner cannot obtain the redo, Extract cannot capture those transactions.
And if Extract never captures them, they never enter the trail.
Changing something on the PostgreSQL target cannot correct that problem.
This is where the investigation gets interesting.
If the database retains only one day of archived redo but Extract requests a log from seven days ago, I would investigate three areas immediately:
The important question is not simply:
Why is GoldenGate looking backward?
The better question is:
What recovery state requires GoldenGate to return to that SCN?
One of the first commands I would run is:
INFO EXTRACT <extract_name>, SHOWCH
Oracle documents SHOWCH as displaying detailed Extract checkpoint information, including read and write checkpoint positions.
For example:
INFO EXTRACT EXTORA, SHOWCH
I want to understand the relationship between the current processing position and the recovery position.
Conceptually:
Current Oracle Redo
|
|
| Current Extract position
|
|
|----------------------------
|
|
| Recovery Checkpoint
|
|
|----------------------------
|
| Old transaction began
|
v
Older Redo
If that recovery position is seven days old, I need to determine why.
Next I would check what transactions Extract is tracking.
SEND EXTRACT <extract_name>, SHOWTRANS
For example:
SEND EXTRACT EXTORA, SHOWTRANS
SHOWTRANS is particularly useful because GoldenGate can show information such as transaction ID, redo thread, SCN, redo sequence, RBA and the oldest redo log required to restart Extract.
An example may conceptually look like:
Oldest redo log file necessary to restart Extract:
Redo Thread: 1
Redo Sequence: 12543
SCN: 984562341
XID: 7.14.48657
Start Time: 2026-09-14 04:13:21
Status: Running
Now we have something important.
Today may be September 21, but GoldenGate is tracking a transaction whose captured activity goes back to September 14.
That can explain why recovery needs older redo.
Oracle GoldenGate includes a mechanism called Bounded Recovery specifically to make Extract recovery from long-running transactions more manageable.
Oracle describes Bounded Recovery as part of Extract's checkpointing facility. Its purpose is to place an upper boundary on how much recovery work Extract needs after a planned or unplanned stop, regardless of the number or age of open transactions.
The default Bounded Recovery interval is:
BRINTERVAL = 4 hours
Oracle states that GoldenGate requires at least twice the BRINTERVAL in log retention to guarantee Bounded Recovery. With the default four-hour interval, that means at least eight hours of required redo availability for that mechanism.
The architecture is roughly:
Long-running transaction starts
|
|
| GoldenGate maintains
| transaction state
|
BR Checkpoint
|
|
BR Checkpoint
|
|
Extract stops
X
|
v
Extract recovers using
Bounded Recovery state
Without Bounded Recovery, recovery could require GoldenGate to return all the way back to the beginning of the transaction.
With BR, GoldenGate can persist recovery information periodically and avoid rereading the entire transaction history.
This is the dangerous situation.
Oracle documents that during Extract recovery, GoldenGate may either recover using Bounded Recovery checkpoint information plus redo, or recover from its normal recovery checkpoint in the archived and online redo logs.
You can check recovery status with:
SEND EXTRACT <extract_name>, STATUS
You may see something like:
In recovery[1]
Conceptually:
Extract Restart
|
v
Bounded Recovery
available?
/ \
YES NO
| |
v v
BR checkpoint Normal recovery
+ recent redo |
v
Recovery checkpoint
|
v
Older Oracle redo
If normal recovery needs redo from seven days ago, but Oracle only retains one day, recovery stops.
And eventually LogMiner reports that the required log cannot be found.
This is the operational lesson.
Archive-log retention should not be based solely on normal database backup requirements.
It also has to account for replication recovery requirements.
For example:
Archive Retention
1 day
<-------->
GoldenGate Recovery Requirement
7 days
<------------------------------------------------>
Those two policies are incompatible.
Under normal operation, everything may appear healthy.
Then Extract stops.
GoldenGate attempts recovery.
It needs sequence 12345 from six or seven days earlier.
Oracle says:
That archive no longer exists.
And GoldenGate cannot continue safely.
If the archived redo still exists in RMAN backup or another archive repository, the safest recovery path is generally to restore it.
From the GoldenGate error, alert log and Extract information, determine:
Thread
Sequence
SCN
Timestamp
Then query Oracle:
SELECT
thread#,
sequence#,
first_change#,
next_change#,
name,
archived,
deleted,
status
FROM v$archived_log
WHERE <required_scn> >= first_change#
AND <required_scn> < next_change#
ORDER BY thread#, sequence#;
In RAC environments the thread number is critical, because each instance generates its own redo thread.
If the required archive can be restored and made visible to Oracle/LogMiner, Extract may be able to resume from its existing recovery position.
This is where I would be extremely cautious.
It may be tempting to simply move Extract forward:
ALTER EXTRACT ...
and get replication running again.
That can solve the process availability problem while creating a much worse data consistency problem.
Imagine that Oracle transactions occurred here:
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7
|--------- REQUIRED ORACLE REDO ---------------------------|
X X X X X archive logs deleted X X X X X
|
v
Extract restarted
If Extract is repositioned beyond the missing redo:
Oracle
|
| Transaction A
| Transaction B
| Transaction C
|
X <-- missing redo
|
| Transaction D
| Transaction E
|
v
PostgreSQL
Transactions A, B and C could be missing from PostgreSQL forever.
Replication may show:
RUNNING
while the databases are no longer synchronized.
That is why I consider this a data-integrity incident, not merely an Extract restart problem.
If the missing redo cannot be recovered, the appropriate solution may be to establish a new consistent synchronization point and reinstantiate the affected PostgreSQL data.
Conceptually:
Oracle
|
|
Establish consistent
SCN / point
|
+----------+----------+
| |
v v
Initial/Reload Data GoldenGate Capture
| from sync point
v |
PostgreSQL |
| |
+----------+----------+
|
v
Normal Replication
Depending on the size of the environment and the scope of the missing transactions, this could mean synchronizing particular tables, schemas, or the entire target.
The exact recovery strategy should be determined from the known-good source and target positions rather than simply trying to make Extract show RUNNING.
Logdump is extremely useful here, but it is important to understand what it does.
Logdump reads GoldenGate trail and extract files. It does not read Oracle online redo logs or Oracle archived redo logs.
Oracle's current documentation describes OPEN as opening a GoldenGate trail file or extract file.
For example:
logdump
Then:
GHDR ON
DETAIL ON
DETAIL DATA
OPEN ./dirdat/aa000123
NEXT
Logdump can help determine what actually made it into the GoldenGate trail. Oracle documents commands such as OPEN, NEXT, POSITION, DETAIL DATA, and NEXTTRAIL for navigating and examining trail contents.
This distinction is critical:
Oracle Archive Redo
|
| LogMiner reads this
|
v
GoldenGate Extract
|
v
GoldenGate Trail
|
| Logdump reads this
|
v
GoldenGate Replicat
|
v
PostgreSQL
If the missing transaction never made it through Extract, Logdump cannot recover it.
However, Logdump can be extremely valuable in determining the last transaction, SCN, RBA, table operation or transaction boundary that successfully entered the trail.
That information can help establish exactly where the replication gap begins.
I like to divide an Oracle-to-PostgreSQL GoldenGate incident into four positions:
Oracle Redo Position
|
v
Extract Capture Position
|
v
Trail Position
|
v
Replicat Apply Position
|
v
PostgreSQL
Ask four separate questions:
| Layer | Question |
|---|---|
| Oracle redo | Does the required redo still exist? |
| Extract | What SCN/checkpoint is Extract trying to recover from? |
| Trail | What transactions actually made it into GoldenGate? |
| Replicat | How far did the target actually apply? |
Those four answers provide a much clearer picture than simply asking why Replicat is down.
Once service is restored, I would review the entire archive-retention strategy.
The environment should be designed so that a temporary GoldenGate outage does not immediately put recoverability at risk.
At minimum, I would review:
Archive log retention
RMAN deletion policy
FRA capacity
Extract checkpoint lag
GoldenGate heartbeat lag
Long-running transactions
Bounded Recovery status
BR checkpoint location and health
RAC redo-thread availability
Extract outage history
Trail retention
Monitoring and alert thresholds
One day of redo retention may technically work while everything is healthy, but it leaves very little operational margin when replication stops, infrastructure fails, or a long-running transaction complicates recovery.
When GoldenGate requests an archive log from seven days ago and Oracle retains only one day, don't immediately try to force Extract forward.
First determine why GoldenGate requires that redo.
Check:
INFO EXTRACT <extract>, SHOWCH
SEND EXTRACT <extract>, STATUS
SEND EXTRACT <extract>, SHOWTRANS
Look for the recovery checkpoint, Bounded Recovery state, long-running transactions, Extract lag, required redo thread and required SCN.
If the archive can be restored, restore it.
If it cannot, determine whether the target must be resynchronized.
And use Logdump where it is strongest: determining exactly what GoldenGate successfully wrote to the trail before the failure.
The goal isn't simply:
Extract = RUNNING
Replicat = RUNNING
The real goal is:
Oracle Source
=
GoldenGate Capture
=
GoldenGate Trail
=
PostgreSQL Target
A running replication process is not necessarily a synchronized replication environment.
© 2026 MRC Consulting LLC. All rights reserved.
Oracle, Oracle Database, Oracle GoldenGate, and related product names are trademarks or registered trademarks of Oracle Corporation and/or its affiliates. PostgreSQL is a trademark or registered trademark of the PostgreSQL Community Association of Canada and is used here solely for identification purposes.