GoldenGate Error: OGG-02249 The Extract configuration does not support a physical standby / & the need for Downstream Capture

Recently, I saw people dealing with errors while configuring an Oracle GoldenGate Extract process against a Physical Standby database. In this post, I will share the cause of this error and the recommended architectural approach to resolve it.

*When starting the extract, the process abends with the following messages in the ggserr.log:

2025-12-20 18:13:36 ERROR OGG-02249 The Extract configuration does not support a physical standby as the source database.

2025-12-20 18:13:36 ERROR OGG-01668 PROCESS ABENDING.

This error occurs when a GoldenGate Extract is configured to pull data directly from a physical standby database that is not properly set up for such operations. By design, traditional Extract requires access to specific redo log structures and supplemental logging.

A standard physical standby (Active Dataguard / ADG) is typically in a read-only state and does not inherently support direct extract operations in the same way a primary or logical standby does.

Well. This means it is not supported to make CDC with Goldengate from an physical standby including the Active Dataguard-based ones directly.

So if we need to offload the extraction process from our primary production system to a standby environment, we should consider using downstream capture configuration. I mean; GoldenGate Integrated Extract can be configured to work with Active Data Guard using a Downstream Capture configuration. In this setup, the mining process runs on a separate database (the downstream mining database). This also offloads the CPU and I/O overhead from the primary instance.

What about using classic capture instead? Well, it is important to note that Classic Capture mode is deprecated. Therefore, moving towards Integrated Capture is not just a fix for this error, but a strategic requirement for future-proofing our environments.

**In summary, if we need to make a standby database as the source for Goldengate, we should include a data mining server in to the picture. Production will also replicate to the data mining server, which is also an Oracle Database running in Read Write mode, and then Goldengate will capture from there..

Data mining server (an Oracle Database) is not a physical standby bytheway. It is configured to receive redo from the source, but it is in read write mode. Redo transport will still be there, logs are shipped over the network from the source database to the data mining server and the log mining server in the data mining database extracts the changes from the redo log (or archive) files and serves them to the GoldenGate extract process.

That's tip for today. I hope it helps.