GoldenGate Extract Performance Testing Made Repeatable

To measure the performance improvements of an Integrated Extract (specific to Oracle database as the source) when either making a GoldenGate parameter change or database parameter change or SDU size change to improve network throughput or any infrastructure level changes for performance improvement, it is critical to use a consistent and repeatable testing methodology.  Without control over the start and stop points or a consistent dataset, results can be misleading.  To accurately compare before-and-after test runs, your GoldenGate Extract performance test should ideally:

• Start from the same SCN
• Run under the same workload
• End at the same logical point
• Collect measurable performance data

This is where you can use the following features of GoldenGate: REPORTCOUNT, EVENTACTIONS and ETROLLOVER. 

REPORTCOUNT: Monitor Throughput Over Time

The REPORTCOUNT parameter logs periodic processing metrics into the report file.  It is extremely useful during performance testing to track the following:

• Total operations processed
• Average rate (since the start of the Extract)
• Delta rate (since last interval) 

Configuration Example

Sample Output

Understanding the Metrics

• Total records: Total number of operations processed
• Rate: Total records % time elapsed since Extract started
• Delta: Records processed in last interval % interval duration

Note: If there were no operations processed by the Extract within the interval, there would be none reported on the report file.  There is a high chance for the same when the interval is smaller like in seconds vs minutes or hours.

EVENTACTIONS: Ensure Consistent End Conditions

Along with the TABLE or MAP parameter that controls the selection, mapping, and manipulation of the objects there is an option named EVENTACTIONS that allows the Extract to take a defined action based on a record in the trail.  For repetitive performance tests and to eliminate inconsistencies, this EVENTACTIONS lets you define an automated stop condition for Extract.  This ensures that both your baseline and test processes stop at the same logical point.

Use Case:

Insert a row to a control table at the end of the test:

Set the following in your Extract parameter file:

GoldenGate will stop the Extract as soon as it encounters the event record, keeping the start and stop points aligned across test runs.

ETROLLOVER: Optimize Repeat Runs

If you want to run your Extract multiple times from the same SCN, the Extract will skip capturing records that were already written to the trail files which defeats the purpose of repetitive runs.  

The ETROLLOVER command forces a new incarnation of the trail file and increments the sequence number upon restart, capturing all records since the specified SCN, even if they were previously captured.   This is generally used for manual recovery situations after an issue or when upgrading Oracle GoldenGate but very handy and convenient for repetitive performance tests.

Configuration Example

Why Use ETROLLOVER

• Avoids delays caused by trail file recovery
• Captures all records since the specified SCN even if they were captured earlier
• Keeps test cycles consistent and efficient

Ensure Archived Logs Are Available for SCN-based Restarts

When rerunning Extract from a specific SCN using ETROLLOVER, it is critical to ensure that the corresponding archived redo logs are still available. If the required archived logs are missing, Extract will abend with a log read error. This will prevent the test from starting and make your comparison invalid or impossible.

If your Extract fails to start and logs error like:

2025-06-19 03:44:58 ERROR OGG-02028 Failed to attach to logmining server OGG$EXT1 error 1,292 - ORA-01292: LogMiner for upstream capture cannot find log file

it’s a clear sign that the archived logs for your test SCN are missing. If logs are gone, restore them from RMAN backup or recreate the test SCN using a fresh data snapshot.

Best practice is to verify the availability of required archived logs before re-running the test using a SQL like:

Always plan your SCN-based testing timeline to ensure archived logs are retained long enough for repeat runs.

Putting It All Together

With all the above options, here is the sequence of steps to run the baseline and the subsequent run with the changes that you wanted to measure.

1. If you are creating a new Extract, note down the SCN at the time of registering the Extract. If you are not creating a new Extract, note down the current SCN. Do not start the Extract yet.  
2. Run the workload to capture the baseline numbers while keeping the Extract down.
3. At the end of the workload, insert a record into the control table and commit the transaction.
4. Start the Extract and let it run.  The report file will contain the operations metrics captured by REPORTCOUNT.  Capture any other metrics that are relevant to the change you are implementing.
5. After the Extract stops due to the EVENTACTIONS, alter the Extract to the SCN noted in step 1 along with ETROLLOVER.
6. Make the change (be it parameter / infrastructure / SDU change) and start the Extract and let it run. Capture any other metrics that are relevant to the change you are implementing as you did in step 4. The report file should have the operations metrics captured by REPORTCOUNT.

Once the Extract stops at the same logical point due to EVENTACTIONS, you can compare the overall processing time and the RATE/DELTA metrics across the two runs. If you want you can parse the report file and extract the rate or delta metrics and plot the throughput trends over time.

Control External Factors: Eliminate Background Noise

For performance tests to be meaningful, they must be run under consistent system conditions. That means:

• Avoid running other resource-intensive processes during the test
• Ensure CPU, memory, and I/O load are stable
• Eliminate network congestion or background jobs that can distort results

In short, the only variable between test runs should be the configuration you are evaluating, such as, parameter change, SDU size change or infrastructure level change. Running tests under different load conditions introduces “noise”, making it difficult to tell if improvements (or regressions) are real or incidental. Keeping the environment clean and controlled ensures your measuresments are trustworthy and repeatable.

Summary

Final Thoughts

GoldenGate tuning doesn’t have to be a guesswork.  With tools like REPORTCOUNT, EVENTACTIONS, and ETROLLOVER, you can set up consistent, repeatable Extract performance tests that lead to confident data-driven decisions. 

References

EVENTACTIONS – Oracle GoldenGate Documentation