Migrating GoldenGate from CDB-Root to Per-PDB Capture When Process Names Must Stay the Same

Moving an Oracle GoldenGate Extract from CDB-root capture to per-PDB capture changes more than the database connection. The migration must preserve transaction continuity while changing the capture topology, and in some environments there is another practical constraint: the existing Extract and Replicat names are already embedded in automation, monitoring, operational procedures, and documentation.

In that situation, permanently introducing new process names may create more downstream change than the database migration itself.

One option is therefore to recreate the processes in the new GoldenGate instance under the same logical names, while using an SCN-based handoff to avoid both data gaps and duplicate application.

For the examples below, I will use deliberately generic names:

Extract:  EXT1
Replicat: REP1

The important distinction throughout the migration is:

SAME NAME     → yes
SAME PROCESS  → no

EXT1 and REP1 in the new deployment are new GoldenGate processes. Only their operational names are preserved.

Two Valid Ways to Create the Overlap

A useful reference pattern for this type of migration is the runtime-overlap approach described by Lima.

In that model, the old CDB-root Extract and the new per-PDB Extract coexist for a period. Because both processes exist at the same time, they necessarily use different names. The overlap gives GoldenGate enough history to protect the transaction boundary before the old stream is retired.

That is a natural approach when introducing new process names is acceptable.

There is, however, another option when preserving existing names matters.

Instead of overlapping process execution, we can overlap the redo range processed by the new Extract.

Conceptually:

register_scn
     |
     |=========== SCN overlap ===========|
                                         cutover_scn
                                              |
                                              | new transactions
                                              v

The new EXT1 starts from an SCN earlier than the cutover boundary and therefore intentionally reads some redo already handled by the previous replication stream.

The new REP1 is then started with:

START REPLICAT REP1 AFTERCSN <cutover_scn>

The result is:

CSN <= cutover_scn  → SKIP
CSN >  cutover_scn  → APPLY

This preserves the same transaction-boundary principle as the runtime-overlap approach, but implements the overlap through SCN positioning instead of two simultaneously running Extracts.

The Starting and Target Topologies

The original topology is conceptually:

CDB Root
   ↓
EXT1
   ↓
old trail / Distribution
   ↓
REP1
   ↓
Target

After the migration:

PDB connection
   ↓
EXT1
   ↓
new trail / Distribution
   ↓
REP1
   ↓
Target

The names remain the same, but the GoldenGate objects do not.

The new Extract is registered directly against the PDB and uses the PDB-local GoldenGate configuration.

For example, a CDB-style table reference such as:

TABLE SOURCE_PDB.SOURCE_SCHEMA.TABLE1;

becomes a PDB-local reference:

TABLE SOURCE_SCHEMA.TABLE1;

SOURCECATALOG or an equivalent PDB prefix is no longer required where the Extract is connected directly to the PDB.

Prepare Everything That Does Not Require the New Process Registration

Before the cutover, the new GoldenGate environment should be prepared as far as possible without creating the same-name Extract or Replicat.

That includes:

PDB database connection / credential alias
target database connection / credential alias
trail configuration
Distribution / Receiver path
parameter files
profiles / autostart configuration

Review the current parameters for both EXT1 and REP1, and adapt only what the new topology requires.

Also verify supplemental logging and TRANDATA.

At this stage, however, do not create or register the new EXT1 or REP1.

The old objects still exist under those names.

Choose a Safe Registration SCN

The new per-PDB Extract needs a starting position that predates the final handoff.

For a per-PDB Extract, available dictionary builds can be inspected while connected to the PDB:

SELECT DATE_OF_BUILD,
       START_SCN
FROM DBA_LOGMNR_DICTIONARY_BUILDLOG
WHERE CONTAINER_ID = <PDB_CON_ID>
ORDER BY DATE_OF_BUILD DESC;

Select a valid dictionary START_SCN that is earlier than the planned cutover:

register_scn < cutover_scn

The required archive logs from register_scn onwards must remain available.

That point matters because the migration deliberately asks the new Extract to read historical redo rather than beginning exactly at the old Extract’s final position.

Long-Running Transactions Define the Real Boundary

An SCN overlap is only useful if it is old enough to cover transactions that may cross the handoff.

Before cutover, inspect transactions on the old Extract:

SEND EXTRACT EXT1, SHOWTRANS

Also inspect its checkpoints:

INFO EXTRACT EXT1, SHOWCH

The risk to avoid is conceptually:

register_scn
     |
     |------- transaction still open ------- commit
                                             |
                                        cutover_scn

If a transaction started before the range available to the new Extract but commits after the cutover, the migration can create a hole.

So the registration point, retained redo, and long-running transactions must be considered together.

This is also why an overlap period is important in the runtime-overlap pattern: the implementation differs, but the transaction-boundary problem is the same.

Establish the Cutover Boundary

Once the overlap is considered safe, stop the old Extract normally:

STOP EXTRACT EXT1

Use a forced stop only where it is understood and necessary.

Immediately inspect the checkpoint:

INFO EXTRACT EXT1, SHOWCH

Record:

cutover_scn = Current Checkpoint SCN

This value is the handoff boundary.

It is the old Extract Current Checkpoint SCN, not the Replicat checkpoint.

That gives the migration a precise rule:

old stream       → responsible through cutover_scn
new stream       → responsible after cutover_scn

Let the Old Replicat Finish Its Work

Stopping the Extract does not mean the old replication path has finished.

The old REP1 still needs to consume everything already written to the old trail.

Check:

SEND REPLICAT REP1, STATUS
INFO REPLICAT REP1, DETAIL

Wait until the Replicat reaches EOF and lag is zero.

Only then stop it:

STOP REPLICAT REP1

At that point:

old EXT1 = stopped
old REP1 = stopped / EOF

Target contains everything
through the old stream's cutover boundary

This separation between stopping capture and finishing apply is fundamental to the handoff.

Remove the Old Same-Name Processes

Because the new GoldenGate environment will use the same process names, the old objects cannot remain registered.

Back up or export the old configuration first.

For the integrated Replicat:

DBLOGIN USERIDALIAS <target_alias>

DELETE REPLICAT REP1

The associated inbound server is conceptually:

OGG$REP1

For the Extract, after the Replicat has reached EOF and cutover_scn has been safely recorded:

DBLOGIN USERIDALIAS <old_cdb_alias>

DELETE EXTRACT EXT1

Do not delete the old trail files or saved parameters yet.

They remain useful during the observation period for rollback and investigation.

Create the New Per-PDB Extract Under the Same Name

Now connect from the new GoldenGate deployment directly to the source PDB:

DBLOGIN USERIDALIAS <PDB_alias>

Register the new Extract at the earlier SCN:

REGISTER EXTRACT EXT1 DATABASE SCN <register_scn>

Then create it:

ADD EXTRACT EXT1,
    INTEGRATED TRANLOG,
    SCN <register_scn>

Its parameter file now represents the per-PDB topology:

EXTRACT EXT1
USERIDALIAS <PDB_alias>

...

TABLE SOURCE_SCHEMA.TABLE1;
TABLE SOURCE_SCHEMA.TABLE2;

Although the name is still EXT1, this is a new per-PDB Extract, not a modified continuation of the previous CDB-root process.

That distinction is what makes name reuse workable.

Start the New Extract and Allow the Overlap to Materialize

Start:

START EXTRACT EXT1

Then inspect its position:

INFO EXTRACT EXT1, DETAIL
INFO EXTRACT EXT1, SHOWCH

The new Extract starts at:

register_scn

which is earlier than:

cutover_scn

The new trail will therefore contain some transactions that the previous stream has already applied.

That is intentional.

register_scn
     |
     |========= overlapping redo =========|
                                      cutover_scn
                                           |
                                           | new transactions
                                           v

The overlap has moved from the process layer to the redo layer.

Do Not Start the New Replicat Too Early

Allow the new Extract and Distribution Path to produce and transfer enough trail data to move beyond cutover_scn.

Check:

INFO EXTRACT EXT1, DETAIL
INFO EXTRACT EXT1, SHOWCH

Only after its current position has passed the handoff boundary should the new integrated Replicat be introduced.

Create it in the new GoldenGate instance:

DBLOGIN USERIDALIAS <target_alias>

ADD REPLICAT REP1,
    INTEGRATED,
    EXTTRAIL <new_trail>

Use the previous Replicat configuration with only the changes required by the new topology.

Again, REP1 is a new process with an intentionally reused operational name.

Use AFTERCSN as the Duplicate-Protection Boundary

Start the new Replicat with:

START REPLICAT REP1 AFTERCSN <cutover_scn>

The logic is simple:

CSN <= cutover_scn  → SKIP
CSN >  cutover_scn  → APPLY

Visually:

old stream
------------- applied ---------------> cutover_scn
                                           |
                                           X
new stream overlap -------- skipped -------|
                                           |
                                           +------ apply new transactions ---->

The old stream therefore owns everything through the recorded Extract checkpoint.

The new Extract can safely read an earlier range, while AFTERCSN prevents that overlap from becoming duplicate application.

This is the core of the alternative migration pattern.

Validation Matters More Than the Elegance of the Cutover

Once both new processes are running, inspect them directly:

INFO EXTRACT EXT1, DETAIL
INFO EXTRACT EXT1, SHOWCH

INFO REPLICAT REP1, DETAIL
INFO REPLICAT REP1, SHOWCH

Confirm:

EXT1 RUNNING
REP1 RUNNING

Extract checkpoint advancing
Replicat checkpoint advancing

lag → 0

No discarded transactions
No abended transactions
No duplicate errors

Where possible, controlled DML in a test environment provides an additional end-to-end check:

INSERT
UPDATE
DELETE

Verify the changes on the target and perform reconciliation or counts for critical tables.

The migration is complete only when the target state has been validated, not merely when both GoldenGate processes report RUNNING.

Cleanup Comes Last

During the observation period, retain:

old GoldenGate instance
old trails
old parameters
old configuration export

Only after confirming:

new EXT1 healthy
new REP1 healthy
target consistency
Git / Ansible configuration

should obsolete trails and configuration be removed according to the applicable retention policy.

Keeping the previous configuration temporarily is useful regardless of whether runtime overlap or SCN overlap is used. It preserves evidence and recovery options while the new stream is being validated.

Why Preserving the Names Can Matter

Using different old and new process names is entirely reasonable when both generations of the replication stream need to coexist.

But when the GoldenGate deployment itself is being replaced, preserving the names after cutover can also have practical value:

• existing operational naming remains stable;
• monitoring references require fewer permanent changes;
• Git and Ansible conventions can remain consistent;
• documentation continues to use the same logical identifiers;
• the migration creates less long-term configuration drift.

This should not be read as an argument that same-name migration is inherently better.

It is an additional option for environments where operational naming has value and simultaneous old/new process execution is not required.

The architecture determines which overlap model fits.

What This Means in Practice

The key distinction is not between a “right” and “wrong” migration pattern.

It is between two ways of protecting the same transaction boundary.

A runtime-overlap design can keep the old and new streams alive simultaneously, which naturally requires different process names during migration.

An SCN-overlap design can preserve existing logical names, provided the old processes are fully retired before the new ones are created and the new Extract starts far enough back in redo to create a safe overlap.

The abbreviated sequence is:

PREPARE NEW GG INSTANCE
        ↓
choose valid per-PDB register_scn
        ↓
verify archive logs + long transactions
        ↓
STOP old EXT1
        ↓
INFO EXT1 SHOWCH
        ↓
cutover_scn = Current Checkpoint SCN
        ↓
let old REP1 reach EOF
        ↓
STOP old REP1
        ↓
DELETE old REP1
DELETE old EXT1
        ↓
NEW GG INSTANCE
        ↓
REGISTER / ADD EXT1
from register_scn < cutover_scn
        ↓
START EXT1
        ↓
new trail catches up
        ↓
ADD REP1
        ↓
START REP1 AFTERCSN cutover_scn
        ↓
VALIDATE
        ↓
KEEP SAME LOGICAL NAMES:
EXT1 / REP1

Conclusion

Migrating from CDB-root capture to per-PDB capture does not necessarily require a permanent change to GoldenGate process naming.

When preserving those names is operationally useful, SCN overlap provides another way to create a controlled handoff: stop the old Extract, record its Current Checkpoint SCN, allow the old Replicat to reach EOF, recreate the processes in the new topology, let the new Extract re-read an overlapping redo range, and use AFTERCSN to establish the exact apply boundary.

The important design principle remains the same across both approaches: the new replication stream must have enough history to cover the handoff, while only one stream is allowed to apply each transaction.

The implementation can then be chosen according to the surrounding operational constraints.