Coordinated Replicats: Faster, Lower-Risk GoldenGate Loads
Every Oracle GoldenGate migration project has a moment where the schedule is won or lost: the initial load. It is the unglamorous part of the plan — move the existing data, then let change data capture keep it current — and it is also where cutover windows quietly blow up. Pick the wrong replicat for a large table and a load you scoped in hours can stretch into the weekend, pushing your go-live and everyone's nerves with it.
Here is the straight story: the type of replicat you use for initial load directly affects your project timeline, your cutover risk, and how confidently you can tell the business when you will be live. For loading data, the coordinated replicat is the one that protects the schedule. Let me explain why, and what it means for your migration.
TL;DR
For Oracle GoldenGate initial loads, the coordinated replicat is the better choice over the parallel replicat — and the difference shows up on your project plan, not just in a config file.
- Initial load is a timeline risk, not a footnote. The replicat you choose decides whether a large table loads in parallel or becomes your bottleneck.
- Parallel replicat serializes on a single table, so big single-table loads do not scale — and that is exactly when your cutover window is tightest.
- Coordinated replicat ships with 25 threads by default and can load even a single table in parallel using
THREADorTHREADRANGE(). - The change is low-effort, high-leverage. You swap one, maybe two, replicats — the rest of your REST API load process stays the same.
- RheoData designs and delivers this so your team inherits a repeatable, low-risk load instead of learning it under deadline pressure.
Why Initial Load Strategy Belongs on Your Project Plan
When leaders ask "when can we cut over?", the honest answer depends heavily on how fast the initial load runs. That single number drives the size of your maintenance window, how much downtime the business has to absorb, and how much margin you have if something needs a second pass. Treat initial load as a checkbox and it becomes the line item that slips. Treat it as a design decision and it becomes predictable.
The good news is that this is a decision you can get right early, with very little added effort. The rest of this post walks through the mechanics so you understand why the coordinated replicat is the safer bet — and so you can ask the right questions of whoever is delivering your migration.
Two Trail File Types: EXTTRAIL vs. EXTFILE
The initial load process uses two different kinds of trail files. They look similar, but they do very different jobs, and knowing the difference is the foundation for everything that follows.
| Trail File | What It Holds |
|---|---|
| EXTTRAIL | A binary file that houses Change Data Capture (CDC) transactions. |
| EXTFILE | A file used for full table dumps of all the data. |
Your ongoing replication rides on EXTTRAIL. Your initial load rides on EXTFILE. The REST API approach I have written about for years remains the best way to do this, because everything can be scripted — and scripted means repeatable, reviewable, and far less prone to the manual mistakes that cost you a cutover.
The SPECIALRUN Change — and Why It Gives You Options
When Oracle moved to the RESTful API architecture, it removed the SPECIALRUN parameter from replicats. The practical effect is a win: every replicat can now read both the EXTTRAIL and the EXTFILE formats, which means any replicat can serve as your initial load replicat. You are no longer locked into a special-purpose process just to move the existing data.
There is one trade-off to plan for. Without SPECIALRUN, the replicat will not automatically stop once it finishes loading the EXTFILE — so your runbook needs to account for stopping and monitoring it. Oracle calls the unified behavior a feature, and it is; you simply trade the old "stop when done" convenience for far more flexibility. One detail to keep handy: the last release where SPECIALRUN appears is 19.1. On a current release, it is not coming back.
Coordinated vs. Parallel Replicat: The Decision That Moves Your Timeline
Across many implementations and tests, I keep landing on the same answer for the initial load of data: the coordinated replicat is the best fit. Both replicat types can do the job, so here is the difference that actually matters to your schedule.
Parallel Replicat
Parallel replicat lets you set minimum and maximum parallelism, which sounds ideal until you hit the catch: when it is loading a single table, the parallelism serializes and does not scale. Translated to the project plan, your largest table — the one most likely to define your cutover window — loads slower than you planned, exactly when you can least afford it.
Coordinated Replicat
Coordinated replicat does the same kind of work — it is, in fact, the precursor to parallel replicat — but it carries an advantage that pays off at load time. By default it has 25 threads available, and a single table can be loaded using the THREAD or THREADRANGE() parameter to leverage those pre-allocated threads. The result is a single large table loaded genuinely in parallel — the outcome parallel replicat could not give you, and the one that keeps a big table from becoming your bottleneck.
What This Means for Your Cutover
Here is the part executives appreciate: adopting this does not mean redesigning your migration. If you already have a REST API initial load process, the only change is switching out one, maybe two, replicats depending on the size of the environment. Same approach, better engine under the hood — and a load you can size with confidence instead of crossing your fingers on cutover night.
How RheoData Helps
Understanding the difference is step one. Designing, scripting, and delivering an initial load that holds up under a real cutover — with the right replicat architecture, the right thread strategy for your largest tables, and a runbook your team can actually operate — is where most projects want a partner who has done it before.
That is what we do at RheoData. We help organizations move and modernize their data on Oracle GoldenGate with migrations and initial loads that are repeatable, observable, and built to protect the schedule. Our work is grounded in deep GoldenGate experience: our founder, Bobby L. Curtis, is an Oracle ACE Director and the author of Pro Oracle GoldenGate 23ai for the DBA. When we hand a project back to your team, they inherit something they can run, not a black box.
Whether you are planning your first GoldenGate migration or tightening a cutover window that has burned you before, we would welcome the conversation.
FAQ
Why does initial load strategy affect my project timeline?
The speed of the initial load determines how large your cutover and maintenance window must be. A load that does not scale on your biggest table directly extends downtime and pushes your go-live, which is why the replicat choice is a planning decision, not just a technical one.
Why is the coordinated replicat better than the parallel replicat for initial load?
The coordinated replicat ships with 25 threads by default and can load a single table in parallel using THREAD or THREADRANGE(). The parallel replicat serializes parallelism on a single table, so large single-table loads do not scale and take longer.
What is the difference between EXTTRAIL and EXTFILE in Oracle GoldenGate?
EXTTRAIL is a binary file that houses Change Data Capture (CDC) transactions. EXTFILE is a file used for full table dumps of all the data. Initial loads rely on EXTFILE, while ongoing replication relies on EXTTRAIL.
Do I have to rebuild my migration to use a coordinated replicat?
No. The overall REST API initial load process stays the same. You are only swapping out one, possibly two, replicats depending on the size of the environment being loaded.
Can RheoData help with our GoldenGate migration?
Yes. RheoData designs and delivers Oracle GoldenGate migrations and initial loads, including the replicat architecture and scripting that keep cutovers low-risk and repeatable. Reach out and we will scope it with you.
Let's Talk
If you are sizing a GoldenGate migration or want a second set of eyes on an initial load before it lands on a cutover plan, let's connect. Visit rheodata.com or email bobby.curtis@rheodata.com. Clear objectives, team success — that is how we run every engagement.