Troubleshooting Oracle GoldenGate Downstream Mining

16 min readAug 15, 2026

When configuring an Oracle GoldenGate downstream mining architecture, you may encounter issues that are not necessarily caused by GoldenGate itself. Delays can occur because of Data Guard redo transport problems, missing archived redo logs, incorrect standby redo log configuration, mining database recovery issues, LogMiner registration problems, or the Extract process itself.

Downstream mining is used to reduce the workload on the source database by moving the redo mining activity away from the production environment. Instead of running Extract directly against the source database, the source archived redo logs are transported to a separate downstream mining database. Extract then mines the redo from that mining database and writes the captured changes to GoldenGate trail files.

The downstream mining database can be placed on the source server, the target server, or a completely separate server, depending on the available operating system resources and workload requirements. In many cases, placing the mining database outside the production server helps reduce CPU, memory, and I/O usage on the source environment.

However, this architecture also introduces additional moving parts. Compared to a traditional source-side Extract configuration, downstream mining requires you to consider not only the Extract process, but also redo transport, archived redo availability, standby redo logs, LogMiner registration, dictionary redo, and mining database health.

Because of this, troubleshooting downstream mining requires a more systematic approach. Restarting Extract blindly should not be the first step. Instead, the correct approach is to follow the redo flow from the source database to the mining database, and then from LogMiner to Extract.

In this article, I will discuss some of the issues I personally encountered while working with Oracle GoldenGate downstream mining architecture and explain the troubleshooting steps that helped me identify and resolve them. I specifically refer to archive log mining architecture here, not real-time mining.

Scope of this article

The troubleshooting examples in this article are based on archive log only downstream mining. Real-time downstream mining is mentioned only where it affects interpretation, such as standby redo log configuration and mining database archiving.

Quick Architecture Recap

Downstream mining can generally be configured in two ways. You can transport redo directly from the source database to the downstream mining database, or, if a Data Guard standby database is available, you can cascade the redo through the standby database to the mining database.

Standard Downstream Mining

Source DB
   ↓
Downstream Mining DB
   ↓
Extract
   ↓
Trail Files
   ↓
Pump
   ↓
Replicat
   ↓
Target Database

In a standard downstream mining configuration, redo generated by the source database is shipped directly to the downstream mining database. Extract runs on the mining database side and mines the received redo from there.

Cascaded Downstream Mining Through a Data Guard Standby

Source DB
   ↓
Standby DB
   ↓
Downstream Mining DB
   ↓
Extract
   ↓
Trail Files
   ↓
Pump
   ↓
Replicat
   ↓
Target Database

In a cascaded configuration, the source database ships redo to the standby database, and the standby database then ships the redo to the downstream mining database. This approach can be useful when you want to reduce direct dependency on the production database and make use of an existing Data Guard environment.

In both architectures, the key point is the same: Extract is not mining directly from the source database. It depends on the redo that reaches the downstream mining database.

Troubleshooting Mindset

When troubleshooting an Oracle GoldenGate downstream mining issue, your first instinct should not be to restart Extract. Your first priority should be to examine the flow of redo.

A general rule of thumb I use is:

Was redo generated on the source database?
Was the redo archived?
Was the redo shipped from the source or standby database?
Was the redo received by the downstream mining database?
Was the redo registered or made visible to LogMiner?
Is Extract mining the redo?
Is Extract writing data to the trail files?
Are the Pump and Replicat processes processing the trail data correctly?

This approach helps you identify where the delay actually begins. In downstream mining, Extract may be running normally, but it cannot mine redo that has not arrived at the mining database or has not been registered with LogMiner.

The main idea is simple:

First prove where the redo stopped. Then troubleshoot that layer.

Before Troubleshooting

Before any troubleshooting effort begins, capture the current state of the GoldenGate environment. This gives you a baseline and helps avoid unnecessary restarts or configuration changes.

The following GGSCI commands have been extremely useful in my troubleshooting work.

INFO ALL

GGSCI> INFO ALL

INFO ALL gives a basic overview of the processes running in the GoldenGate environment. This is usually the first command I run because it quickly shows the status of Manager, Extract, Pump and Replicat processes.

It provides information such as:

Process type
Process status
Group name
Lag at checkpoint
Time since checkpoint

Example output:

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING
EXTRACT     RUNNING     X_SRC       00:00:35      00:00:09
REPLICAT    RUNNING     R_TGT       00:00:00      00:00:10

The Status column shows the current state of the process. Common values are:

Lag at Chkpt shows the replication delay measured at the last GoldenGate checkpoint. Time Since Chkpt shows how long ago that checkpoint was written.

It is important to understand that Time Since Chkpt is not the actual data lag. It tells you how fresh or stale the displayed checkpoint information is.

In a downstream mining architecture where the mining database is on the same host as the target database, you may see Extract and Replicat processes running from the same GoldenGate home.

INFO EXTRACT <extract_name>, DETAIL

GGSCI> INFO EXTRACT <extract_name>, DETAIL

This command gives a detailed overview of the Extract process.

It can show information such as:

Extract status
Checkpoint lag
Current checkpoint position
SCN being processed
Trail file prefix
Current trail sequence
RBA position
Trail file size

The RBA, or Relative Byte Address, identifies the exact byte position inside a trail file or redo/log file where Extract or Replicat is currently reading or writing.

This command is useful when you need to understand exactly where Extract is positioned and whether the checkpoint is moving forward.

LAG EXTRACT <extract_name>

GGSCI> LAG EXTRACT <extract_name>

This command is used to check the current lag of an Extract process.

A small amount of lag can be normal. However, the meaning of lag depends on the type of downstream mining configuration.

If the Extract is configured for archive log only mining and not real-time mining, lag can be higher because the redo must first be archived at the source or standby database, transported to the mining database, and then mined by Extract.

Therefore, when reviewing lag, always consider whether Extract is mining from archived redo logs only or from real-time redo.

SEND EXTRACT <extract_name>, STATUS

GGSCI> SEND EXTRACT <extract_name>, STATUS

This command shows the current status of the Extract process.

It is useful for checking whether Extract is actively processing data, waiting for redo, recovering, or stopped at a particular position.

Example:

Sending STATUS request to EXTRACT X_SRC ...

EXTRACT X_SRC
  Current status: Recovery complete: Processing data

A status like Recovery complete: Processing data generally means that Extract has completed recovery and is processing available redo. However, if lag continues to increase, you still need to verify whether new redo is reaching the mining database and whether LogMiner can see it.

SEND EXTRACT <extract_name>, SHOWTRANS

GGSCI> SEND EXTRACT <extract_name>, SHOWTRANS

This command shows open transactions currently known to Extract.

It is useful when investigating long running transactions. A long running transaction can make lag appear worse because Extract may need to wait until the transaction commits before certain changes can be fully processed.

Example:

GGSCI> SEND EXTRACT X_SRC, SHOWTRANS

Sending SHOWTRANS request to EXTRACT X_SRC ...
No transactions found.

If the output shows No transactions found, then there are no open transactions currently being tracked by Extract. In that case, the lag is likely caused by something else, such as redo transport, LogMiner registration, missing archived logs, or downstream apply.

VIEW REPORT <extract_name>

GGSCI> VIEW REPORT <extract_name>

This command opens the report file for the Extract process.

The Extract report is one of the most important files to review during troubleshooting. It contains startup information, parameter details, database connection messages, mining related messages, warnings, and errors.

When reviewing the report, search for keywords such as:

ERROR
WARNING
OGG-
Logmining server
checkpoint
recovery
dictionary
archive log
SCN

This is especially useful when Extract has abended, is waiting for dictionary redo, or is unable to continue because a required redo log is missing.

VIEW GGSEVT

GGSCI> VIEW GGSEVT

This command displays the GoldenGate event log.

Unlike the Extract report, which focuses on one process, GGSEVT contains messages for the overall GoldenGate environment. This includes Manager, Extract, Pump and Replicat messages.

It is useful when you want to check whether multiple processes were affected around the same time, or whether there were environment-level issues such as process restarts, communication errors, or trail file problems.

GoldenGate CLI Is Not Enough

The GGSCI commands above are useful for capturing the GoldenGate process state, but they do not always show the full root cause.

In downstream mining, Extract depends on the mining database and the LogMiner server. Therefore, you also need to investigate from the database side.

The GoldenGate CLI can tell you that Extract is waiting or lagging, but database views can help you answer deeper questions:

Has the mining database received the required archived redo log?
Is the redo registered with the Extract’s LogMiner session?
Is LogMiner waiting for a missing file?
Is the capture process waiting for dictionary redo?
Is the issue actually on the Replicat side rather than the Extract side?

The next step in troubleshooting is to combine GGSCI output with database level diagnostics from the source, standby, mining and target databases.

Database Level Diagnostics for Downstream Mining

While GGSCI commands are useful for checking the GoldenGate process state, they do not always show the full reason behind a delay. In downstream mining, Extract depends on the mining database LogMiner server. Therefore, some issues must be diagnosed from the database side as well.

A downstream Extract mines redo from a separate mining database instead of directly mining redo at the source database. In real-time mining, redo can be processed from online or standby redo logs immediately, while in archive mining mode, redo is not processed until it is archived into redo log files.

The most useful mining side views are:

V$GOLDENGATE_CAPTURE
DBA_LOGMNR_SESSION
DBA_LOGMNR_LOG
V$ARCHIVED_LOG
V$ARCHIVE_DEST
V$ARCHIVE_DEST_STATUS

These views help you answer one important question:

Has the redo required by Extract reached the mining database, and has it been added to the LogMiner session used by Extract?

Checking the Integrated Capture State

The first database level check I usually perform on the mining database is against V$GOLDENGATE_CAPTURE.

SET LINES 250
COLUMN state FORMAT A25
COLUMN extract_name FORMAT A15
COLUMN capture_name FORMAT A25
COLUMN bytes_of_redo_mined FORMAT A20

SELECT capture_name,
       extract_name,
       state,
       total_messages_captured,
       total_messages_enqueued,
       total_messages_sent,
       bytes_of_redo_mined
FROM   v$goldengate_capture;

V$GOLDENGATE_CAPTURE shows information about the GoldenGate capture process that sends Logical Change Records, or LCRs, to the GoldenGate Extract process. It also shows the LogMiner session ID associated with the capture process.

The STATE column is especially important. Some useful states include:

If BYTES_OF_REDO_MINED, TOTAL_MESSAGES_CAPTURED, and TOTAL_MESSAGES_SENT are increasing, then LogMiner and Extract are progressing. If these values remain unchanged while lag increases, the problem is likely before or inside the mining layer.

Mapping Extract to Its LogMiner Session

After confirming the capture process state, the next step is to identify which LogMiner session belongs to the Extract.

-- Run on Mining DB

SET LINESIZE 250
SET PAGESIZE 1000

COLUMN extract_name FORMAT A12
COLUMN capture_name FORMAT A20
COLUMN logminer_session FORMAT A20

SELECT c.extract_name,
       c.capture_name,
       c.logminer_id,
       s.name AS logminer_session,
       s.source_database
FROM   v$goldengate_capture c
JOIN   dba_logmnr_session s
       ON s.id = c.logminer_id
WHERE  c.extract_name = 'X_SRC';

This query is useful because the GoldenGate Extract name and the internal LogMiner session are not always the same thing. The LOGMINER_ID from V$GOLDENGATE_CAPTURE links the GoldenGate capture process to the LogMiner session.

Once you know the LogMiner session ID, you can check which archived redo logs are actually registered with that LogMiner session.

Checking Logs Registered With LogMiner

One issue I encountered was that the archived redo logs physically existed on the mining database, but they were not registered with the LogMiner session used by Extract. This is an important distinction.

A file can exist in ASM or the filesystem, but Extract cannot mine it unless LogMiner knows about it.

Use the following query to check for gaps in the logs registered with the Extract’s LogMiner session:

-- Run on Mining DB

SET LINESIZE 250
SET PAGESIZE 1000

WITH logs AS
(
    SELECT l.thread#,
           l.sequence#,
           l.first_scn,
           l.next_scn,
           l.name,
           LAG(l.sequence#) OVER
             (PARTITION BY l.thread#
              ORDER BY l.sequence#) AS previous_sequence,
           LAG(l.next_scn) OVER
             (PARTITION BY l.thread#
              ORDER BY l.sequence#) AS previous_next_scn
    FROM   dba_logmnr_log l
    JOIN   v$goldengate_capture c
           ON c.logminer_id = l.logmnr_session_id
    WHERE  c.extract_name = 'X_SRC'
    AND l.keep = 'YES'
)
SELECT thread#,
       previous_sequence + 1 AS missing_sequence_from,
       sequence# - 1         AS missing_sequence_to,
       previous_next_scn     AS missing_scn_from,
       first_scn             AS missing_scn_to
FROM   logs
WHERE  previous_sequence IS NOT NULL
AND    sequence# > previous_sequence + 1
ORDER BY thread#,
         missing_sequence_from;

DBA_LOGMNR_LOG displays archived logs registered with active LogMiner session. It includes the LogMiner session ID, archive log name, source thread number, sequence number, first SCN and next SCN.

Get Kulith Jayakody’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

This query is useful because it shows gaps from LogMiner’s perspective, not just from the filesystem perspective.

For example, if the output shows:

THREAD#  MISSING_SEQUENCE_FROM  MISSING_SEQUENCE_TO  MISSING_SCN_FROM  MISSING_SCN_TO
-------  ---------------------  -------------------  ----------------  --------------
1        804203                 804203               92997000000       92998000000

Then Extract may be waiting because LogMiner does not have sequence 804203 registered for the capture session.

Missing Archive Sequences

Missing archive sequences are one of the most common downstream mining problems. In a normal source side Extract configuration, Extract reads from the source database redo directly. In downstream mining, the redo must travel through redo transport and must be available on the mining database.

This means you need to check the redo sequence at multiple points:

Source database
Standby database, if cascaded transport is used
Downstream mining database
LogMiner registered log list

Start by checking the latest archived sequence from the source database:

select max(sequence#),THREAD# from gV$ARCHIVED_LOG group by thread#;

On the redo source or cascading standby, check destination status:

SELECT destination,
       status,
       archived_thread#,
       archived_seq#,
       applied_thread#,
       applied_seq#,
       error
FROM   v$archive_dest_status
WHERE  status <> 'DEFERRED'
AND    status <> 'INACTIVE'
ORDER BY destination;

V$ARCHIVE_DEST_STATUS shows runtime and configuration information for redo transport destinations, including the most recent archived and applied thread/sequence numbers and any error text.

If the source or standby shows a higher archived sequence than the mining database, the issue is likely redo transport. If the mining database has the sequence but DBA_LOGMNR_LOG does not, the issue is likely LogMiner registration.

Mapping an Extract SCN to an Archive Log

When troubleshooting GoldenGate, do not rely only on sequence numbers. Extract and LogMiner often report positions using SCNs. Therefore, you should know how to identify which archive log contains a specific SCN.

SET LINESIZE 250
COLUMN name FORMAT A90

SELECT thread#,
       sequence#,
       first_change#,
       next_change#,
       first_time,
       next_time,
       name
FROM   v$archived_log
WHERE  93022885124 BETWEEN first_change# AND next_change# - 1
ORDER BY thread#, sequence#;

Replace 93022885124 with the SCN shown in the Extract checkpoint or Extract status output.

V$ARCHIVED_LOG contains archived log information from the control file. The FIRST_CHANGE# column shows the first change number in the archived log, and NEXT_CHANGE# shows the first change in the next log.

This is extremely useful when Extract reports that it is stuck around a particular SCN. Once you identify the archive sequence containing that SCN, check whether that sequence exists on:

Source database
Standby database
Mining database
LogMiner registered log list

Manually Registering Missing Logs With LogMiner

In my case, some archive logs had to be manually registered with the capture process.

Example:

ALTER DATABASE REGISTER LOGICAL LOGFILE
'+DATA/MINEDB/SRC_CASCADE_ARCH/src_1_804203_859865870.arc'
FOR 'OGG$CAP_X_SRC';

ALTER DATABASE REGISTER LOGICAL LOGFILE
'+DATA/MINEDB/SRC_CASCADE_ARCH/src_1_802229_859865870.arc'
FOR 'OGG$CAP_X_SRC';

Use the following syntax for explicit log file assignment:

ALTER DATABASE REGISTER LOGICAL LOGFILE
   file_name FOR capture_process;

The file must already exist at the downstream mining database site, and the capture_process must be the capture process that will use that redo log file. Capture process is equivalent to the LogMiner session name in this context.

This command should not be used blindly. Before registering a file manually, verify:

The file physically exists on the mining database
The file belongs to the correct source database
The capture process name is correct
The log is not already registered

After registering the log, rerun the DBA_LOGMNR_LOG gap query and check whether the missing sequence has disappeared.

Extract Waiting for Redo

One common status is:

Current status: Recovery complete: Processing data

This usually means Extract has completed recovery and is actively processing available data. However, if lag continues to increase while this status remains unchanged, you need to verify whether new redo is reaching the mining database.

I use the following checklist:

1. Check Extract lag from GGSCI
2. Check V$GOLDENGATE_CAPTURE state
3. Check whether BYTES_OF_REDO_MINED is increasing
4. Check latest source archived sequence
5. Check latest sequence received at mining database
6. Check DBA_LOGMNR_LOG for registered logs
7. Check for missing logfiles

If V$GOLDENGATE_CAPTURE.STATE shows WAITING FOR REDO, there are two possibilities:

There is genuinely no new redo activity from the source database
The next required redo log has not reached or has not been registered with the mining database

Extract Waiting for Dictionary Redo

Another important state is:

WAITING FOR DICTIONARY REDO

This means the capture process is waiting for redo logs containing the LogMiner dictionary build. Capture process cannot begin scanning redo until all log files containing the dictionary build have been added to the capture process session.

This can happen when:

Extract was registered at a specific SCN
The dictionary build redo was generated but not shipped
Older required archive logs were deleted
The mining database received redo logs, but LogMiner did not receive all dictionary related sequences
The dictionary related sequence was not registered with the LogMiner session

To investigate, check dictionary markers in V$ARCHIVED_LOG:

SELECT thread#,
       sequence#,
       first_change#,
       next_change#,
       dictionary_begin,
       dictionary_end,
       name
FROM   v$archived_log
WHERE  dictionary_begin = 'YES'
OR     dictionary_end   = 'YES'
ORDER BY thread#, sequence#;

V$ARCHIVED_LOG includes DICTIONARY_BEGIN and DICTIONARY_END, which indicate whether the archived redo log contains the beginning or end of a LogMiner dictionary.

If the dictionary logs are missing from the mining database, restore or copy them from the source/standby and register them with the capture process if required.

Redo Transport Issues

In cascaded downstream mining, redo transport becomes one of the most important areas to troubleshoot.

The flow is:

Source DB → Standby DB → Downstream Mining DB → LogMiner → Extract

If the standby receives redo but the mining database does not, the issue is likely between the standby and mining database.

Check archive destinations on the redo shipping database:

SET LINESIZE 250
COLUMN destination FORMAT A20
COLUMN error FORMAT A60
COLUMN db_unique_name FORMAT A20
COLUMN valid_now FORMAT A20
COLUMN valid_type FORMAT A20
COLUMN valid_role FORMAT A20

SELECT dest_id,
       status,
       target,
       destination,
       db_unique_name,
       valid_now,
       valid_type,
       valid_role,
       error
FROM   v$archive_dest
ORDER BY dest_id;

V$ARCHIVE_DEST shows Data Guard archive destinations, including destination status, target type, destination path or service, validation status, valid redo type, valid role, DB_UNIQUE_NAME and error text.

Pay close attention to:

A common issue in cascaded setups is incorrect VALID_FOR. For example, if the standby is supposed to ship standby redo logs to the mining database, but the destination is configured for the wrong redo type or role, redo may not be transported as expected.

VALID_NOW can report values such as WRONG VALID_TYPE, WRONG VALID_ROLE, or INACTIVE, which are useful indicators when troubleshooting redo transport configuration problems.

Mining Database Archive Configuration

Do not forget that the mining database itself must be healthy.

I recommend enabling archiving at the downstream mining database. Archiving is required for real-time integrated capture and is also recommended for archive log only capture because integrated Extract writes state information in the database. Archiving and regular backups help recover this state information if anything goes wrong at the mining database.

Check the mining database archive mode:

ARCHIVE LOG LIST;

Also check filesystem or ASM space where foreign archived logs are stored. Downstream mining database recovery area must not be used to store foreign archived logs or archive standby redo logs.

This is a practical point. If the mining database FRA or archive destination fills up, redo receiving and mining can stop even though Extract itself is not the root cause.

Do Not Blame Downstream Mining Before Checking Replicat

Sometimes the Extract and mining side are working correctly, but the lag is caused by Replicat. This is especially true when Extract is mining and writing trail files, but changes are not appearing quickly at the target.

The following views are useful for Integrated Replicat diagnostics.

SET LINESIZE 300
COLUMN state FORMAT A20
COLUMN current_position FORMAT A20
COLUMN apply_name FORMAT A10

SELECT apply_name,
       sid,
       serial#,
       state,
       current_position,
       total_messages_received,
       total_available_messages,
       total_transactions_received,
       total_commits,
       total_errors
FROM   v$gg_apply_receiver
WHERE  apply_name = 'OGG$R_TGT';

V$GG_APPLY_RECEIVER displays information about the message receiver of the Replicat process.

To check apply servers:

COLUMN transaction_id FORMAT A30

SELECT server_id,
       state,
       transaction_id,
       message_sequence,
       total_messages_applied,
       TO_CHAR(SYSDATE,'YYYY-MM-DD HH24:MI:SS') AS check_time
FROM   v$gg_apply_server
WHERE  apply_name = 'OGG$R_TGT'
ORDER BY server_id;

V$GG_APPLY_SERVER displays information about each GoldenGate apply server. Oracle documents states such as WAIT DEPENDENCY, which means an apply server is waiting to apply an LCR until another dependent transaction has been applied. This can happen when Integrated Replicat is running with parallelism greater than one.

If one transaction appears to be stuck, check it in V$GOLDENGATE_TRANSACTION:

SELECT transaction_id,
       cumulative_message_count,
       total_message_count
FROM   v$goldengate_transaction
WHERE  transaction_id = '61.29.1647467';

If the Extract side is progressing but Replicat apply servers are waiting, the problem is not downstream mining. It is an apply side issue.

Stopping Integrated Replicat Apply Safely

In one troubleshooting case, I had to stop the Integrated Replicat apply process manually from the database side.

BEGIN
  DBMS_APPLY_ADM.STOP_APPLY(
    apply_name => 'OGG$R_TGT',
    force      => TRUE
  );
END;
/

This should be used carefully. I would not present this as the first troubleshooting step. It is better to first check GGSCI, the Replicat report, apply receiver state, apply server state, and target database wait events.

Use this only when you have confirmed that:

The issue is on the Replicat/apply side
The apply process is not stopping cleanly from GoldenGate
You understand the impact on replication delay
You have captured the current transaction/apply state first

How to Identify the Responsible Layer

The most useful way to troubleshoot downstream mining is to isolate the responsible layer.

This is the main troubleshooting principle:

First prove where the redo stopped. Then troubleshoot that layer only.

Practical Troubleshooting Flow

When I face downstream mining lag, I follow this order:

1. Check INFO ALL
2. Check LAG EXTRACT
3. Check SEND EXTRACT STATUS
4. Check VIEW REPORT extract_name
5. Check V$GOLDENGATE_CAPTURE
6. Check the LogMiner session for the Extract
7. Check registered/missing logs in DBA_LOGMNR_LOG
8. Compare source, standby, and mining archive sequences
9. Check V$ARCHIVE_DEST and V$ARCHIVE_DEST_STATUS
10. If Extract is healthy, check Pump and Replicat

This avoids wasting time restarting GoldenGate processes when the real problem is missing redo transport or LogMiner registration.

Preventive Best Practices

Based on the issues I faced, these are the preventive practices I recommend:

Keep a longer archive retention period on the source, standby and mining database until downstream mining is stable.
Monitor archive sequence gaps between source, standby and mining database.
Do not delete archive logs from the mining database before Extract has mined them.
Keep foreign archived logs separate from the mining database FRA.
Regularly check V$ARCHIVE_DEST.ERROR.
Keep a saved copy of all Extract registration commands.
Document the capture process name, Extract name, LogMiner session ID, source DBID and source resetlogs information.
Monitor V$GOLDENGATE_CAPTURE.STATE, especially WAITING FOR REDO and WAITING FOR DICTIONARY REDO.
Do not assume every lag is an Extract issue, check Pump and Replicat before concluding.

Conclusion

Troubleshooting Oracle GoldenGate downstream mining requires a different mindset from troubleshooting a normal source side Extract. In a source side Extract configuration, most capture issues are close to the source database and Extract process. In downstream mining, the redo must pass through transport, the mining database, LogMiner registration, integrated capture, Extract, trail files, Pump and Replicat.

The best approach is to follow the redo path step by step:

Source redo generation
→ Archive/standby redo creation
→ Redo transport
→ Mining database reception
→ LogMiner registration
→ Integrated Extract mining
→ Trail file generation
→ Pump transfer
→ Replicat apply

In downstream mining, the real question is not simply:

Is Extract running?

The better question is:

Has the redo required by Extract reached the mining database, has LogMiner registered it and is GoldenGate able to convert it into trail data?

Once you answer that question, the root cause becomes much easier to isolate.

Kulith Jayakody

Troubleshooting Oracle GoldenGate Downstream Mining

Scope of this article

Quick Architecture Recap

Standard Downstream Mining

Cascaded Downstream Mining Through a Data Guard Standby

Troubleshooting Mindset

Before Troubleshooting

INFO ALL

GoldenGate CLI Is Not Enough

Database Level Diagnostics for Downstream Mining

Checking the Integrated Capture State

Mapping Extract to Its LogMiner Session

Checking Logs Registered With LogMiner

Get Kulith Jayakody’s stories in your inbox

Missing Archive Sequences

Mapping an Extract SCN to an Archive Log

Manually Registering Missing Logs With LogMiner

Extract Waiting for Redo

Extract Waiting for Dictionary Redo

Redo Transport Issues

Mining Database Archive Configuration

Do Not Blame Downstream Mining Before Checking Replicat

Stopping Integrated Replicat Apply Safely

How to Identify the Responsible Layer

Practical Troubleshooting Flow

Preventive Best Practices

Conclusion

References

Written by Kulith Jayakody

No responses yet

More from Kulith Jayakody

Building an End-to-End CI/CD Deployment Workflow on Oracle Cloud Infrastructure Using OCI DevOps…

Continuous Integration and Continuous Deployment, commonly known as CI/CD, has become an important part of modern application delivery…

Installing Oracle Database 19c on Linux 8 (OL8) Server

Oracle AI Database 26ai True Cache -Complete Hands-On Lab

Oracle True Cache is an in-memory, read-only cache for Oracle AI Database. It behaves similarly to an Active Data Guard read-only replica…

Oracle True Cache Explained: Why It Matters, How It Works and Where to Use It

Modern applications generate a large amount of database read traffic.

Recommended from Medium

Mapping VMware Network Concepts to OpenShift Virtualization: VLANs, Multus, and NMState

This detailed technical diagram illustrates the network architecture and concept mapping for migrating from a traditional VMware vSphere…

APEX 26.1 Installation and Configuration in Oracle 26AI Database.

Prerequisite:

Automating OCI Load Balancer Log Export Using OCI Cloud Shell, OCI CLI, and Object Storage

By Patan Fardeen Khan Oracle ACE Associate | OCI Associate Cloud Engineer

Under the Microscope- There’s a certain Slant of light

It is a strange thing to feel the weight of something that has none.

PostgreSQL max_wal_size: How to Tune It Using Your Server’s Data

PostgreSQL tuning | November2026

Multiplexing a Control File in Oracle Database

Control files are one of the most critical components of an Oracle Database. They store essential metadata about the database, including…

No responses yet

More from Kulith Jayakody

Building an End-to-End CI/CD Deployment Workflow on Oracle Cloud Infrastructure Using OCI DevOps…

Continuous Integration and Continuous Deployment, commonly known as CI/CD, has become an important part of modern application delivery…

Installing Oracle Database 19c on Linux 8 (OL8) Server

Oracle AI Database 26ai True Cache -Complete Hands-On Lab

Oracle True Cache is an in-memory, read-only cache for Oracle AI Database. It behaves similarly to an Active Data Guard read-only replica…

Oracle True Cache Explained: Why It Matters, How It Works and Where to Use It

Modern applications generate a large amount of database read traffic.

Recommended from Medium

Mapping VMware Network Concepts to OpenShift Virtualization: VLANs, Multus, and NMState

This detailed technical diagram illustrates the network architecture and concept mapping for migrating from a traditional VMware vSphere…

APEX 26.1 Installation and Configuration in Oracle 26AI Database.

Prerequisite:

Automating OCI Load Balancer Log Export Using OCI Cloud Shell, OCI CLI, and Object Storage

By Patan Fardeen Khan Oracle ACE Associate | OCI Associate Cloud Engineer

Under the Microscope- There’s a certain Slant of light

It is a strange thing to feel the weight of something that has none.

PostgreSQL max_wal_size: How to Tune It Using Your Server’s Data

PostgreSQL tuning | November2026

Multiplexing a Control File in Oracle Database

Control files are one of the most critical components of an Oracle Database. They store essential metadata about the database, including…