Oracle Publishes AI Workflow for a 5.1 Million-Record GoldenGate Reload

Oracle has published a lab workflow in which Codex coordinated a difficult GoldenGate replication reset from a Markdown runbook, MCP tools and APIs. The Oracle-to-Oracle test completed a 5.1 million-record reload and restarted change data capture, but it also exposed a practical limit: the agent could not complete every required operation through MCP alone.

An initial load copies a starting snapshot of data to a target database. Re-instantiation then restarts change data capture, or CDC, so later changes are applied without breaking continuity. Oracle used Codex with Oracle Database MCP, GoldenGate MCP and GoldenGate REST APIs to coordinate that sequence in a test whose target was Autonomous Database.

The runbook is the operating boundary

The central artifact was not a free-form prompt. Oracle’s Markdown runbook defined prerequisites, the order of operations, conditions for proceeding, failure handling and execution records. It also required the agent to inspect the current environment for items such as tables, the snapshot position and temporary process names, rather than automatically reuse values from prior runs.

• Keep CDC capture running while the existing CDC Replicat is stopped and its parameters and checkpoints are preserved.
• Select one common SCN, Oracle’s database change position, for the snapshot and the later CDC restart.
• Confirm the load before truncating target tables, then validate counts, errors, discards, checkpoints and apply completion.

Parallelism did not mean every stage ran together

Oracle split the snapshot work among four parallel Extracts with non-overlapping ranges. But the workflow kept extraction and apply as separate phases: all four Extracts had to finish before the parallel Replicats began. The shared SCN links the snapshot to the Replicat restart, while continued CDC depends on capture coverage and retained trail files.

MCP handled coordination, not every control

The test found that the available MCP tools did not expose all the settings needed for the procedure. Creating the initial-load Extract and restarting the Replicat with AFTERCSN required direct REST calls. Oracle put those interface choices, required parameters and expected evidence into the runbook so a generic command would not replace an operation with different semantics.

That division is also a guardrail. The agent was instructed to wait for user authorization before making operational changes, then present validation evidence and final replication status. Oracle describes its GoldenGate MCP server as an open-source project for prototyping, development and testing; it is not an Oracle-supported or certified product feature. The result is a working lab pattern, not evidence that the same workflow is ready for unattended production use.