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.

Monitoring Oracle Goldengate Monitoring / Oracle Enterprise Manager & the pluging & JAgent

In complex enterprise environments, the greatest danger lies in the failure.. But! the delay between a failure occurring and its detection is also very important. The longer it takes for detection to occur, the greater the impact of the problem will be. When dealing with an engine (like Oracle GoldenGate) responsible for moving crucial data, this delay translates directly into financial exposure and data divergence. Our recent project focused entirely on eliminating this blind spot, achieving a reliable, centralized view of OGG's operational state.

Monitoring is not a luxury; it is necessary for managing highly available, complex systems. Oracle  Goldengate is such a critical system. It's a bridge, where data passes between systems, and very critical tasks are then performed using that data. By implementing OEM 13.5 GoldenGate Plugin and JAgent, we can properly monitor Oracle Goldengate (OGG) landspace(s) -- even if we are using OGG in the classical mode (non-microservice mode). 

With this approach, we also have the capability of  doing the level 1 administration of our OGG environment (s) through a web-based GUI.

So, as mentioned, the tool we positioned for monitoring OGG was Oracle Enterprise Manager (OEM) Cloud Control 13.5. This is not just a dashboard; it is a central monitoring solution for our databases, middleware, and, the entire OGG environment.

We specifically deployed the OGG-EM-Plugin into OEM for this task. This plugin delivers centralized visibility into all OGG environments.

To achieve the visibility, one must establish a standardized communication path between OGG processes and management console. This path is realized through a layered agent architecture.

The OGG processes periodically generate monitoring points. These are essential data points such as status, lag, and checkpoints.

Then, these monitoring points are sent to the GoldenGate Monitor Agent, named JAgent. This agent is installed on both the source and target database servers and is kept up-to-date with the latest patch bundle(s). The JAgent's role is to collect the data from the local GoldenGate environment.

The JAgent then communicates the collected monitoring data to the standard OEM Agent. And finally, the OEM Server, empowered by the GoldenGate Plugin, receives the data.

Once the architecture is in place, the OEM Server transforms raw data into actionable intelligence. 

The GoldenGate Plugin allows us to populate dashboards with crucial performance indicators (like status, lag, and total operations) and automatically trigger alarms when metrics reach predefined thresholds. OEM also give us the capability of administering the OGG processes (this includes: initiating a stop/start action for any process, and checking alerts and errors on the processes)

We can also make configuration changes to already running parameters.

The resultant dashboards provide status updates. For instance, we can clearly see the Lag for all Extracts and Replicats, allowing quick identification of bottlenecks. By drilling down into a specific Extract, we can see fine-grained metrics, such as Checkpoint Position Delta Operations Per Second, and detailed operational counts (Inserts, Updates, Deletes).

OEM delivers us a web-based central for monitoring and administrating OGG, and it shifts our operation from a reactive to a proactive centralized model. 

We implemented this in one of our data analytics projects, and I can say it performed quite well. 

Things are a little different with the new microservice-based OGG platform. I'll examine that in another article.

Jagent / Monitoring Agent 12.2.1.2 & Oracle Goldengate 21.3 / java.lang.IllegalArgumentException: source parameter must not be null

 You are using Oracle Goldengate 21.3, the classical one (not the microservices architecture based one), and you want to monitor the activities of Goldengate?

You installed an Oracle Enterprise Manager, deployed the Goldengate Plugin, installed Jagent / Monitoring Agent 12.2.1.2 into the targets and configured them. 

You saw PMSRVR and JAGENT processes in GGSCI outputs, you started them, and they were in RUNNING status, and you told yourself: okay, so far so good.

Then, you used Oracle Enterprise Manager's auto discovery for discovering thee monitoring agents by the using relevant information like the port , host and etc..

Oracle Enterprise Manager didn't get any errors and discovery completed successfully, but! nothing changed? Couldn't Goldengate Monitoring agents be discovered?

Then you jumped into the servers where you installed those agents and checked the listen port by using netstat and everything seemed fine.

However; when you checked the log of those agents, you saw something like the following.

Could not get WSInstance Information , [[
com.goldengate.monitor.model.AgentCommunicationException: Failed to get Registry.
at com.goldengate.monitor.jagent.comm.ws.ManagerWSApi.getInstanceInfo(ManagerWSApi.java:239)
at com.goldengate.monitor.jagent.comm.ws.ManagerWSAdapter.getInstanceInfoNative(ManagerWSAdapter.java:105)
at com.goldengate.monitor.jagent.comm.impl.ManagerFacadeImpl.fillInstanceMap(ManagerFacadeImpl.java:259)
at com.goldengate.monitor.jagent.comm.impl.ManagerFacadeImpl.getInstances(ManagerFacadeImpl.java:253)
at com.goldengate.monitor.jagent.jmx.MBeansContainerImpl.createMBeans(MBeansContainerImpl.java:344)
at com.goldengate.monitor.jagent.jmx.MBeansContainerImpl$1.run(MBeansContainerImpl.java:836)
at java.lang.Thread.run(Thread.java:750)
Caused by: java.lang.IllegalArgumentException: source parameter must not be null
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:119)
at com.sun.xml.internal.ws.message.AbstractMessageImpl.readPayloadAsJAXB(AbstractMessageImpl.java:135)
at com.sun.xml.internal.ws.api.message.MessageWrapper.readPayloadAsJAXB(MessageWrapper.java:171)
at com.sun.xml.internal.ws.client.dispatch.JAXBDispatch.toReturnValue(JAXBDispatch.java:88)
at com.sun.xml.internal.ws.client.dispatch.DispatchImpl.doInvoke(DispatchImpl.java:274)
at com.sun.xml.internal.ws.client.dispatch.DispatchImpl.invoke(DispatchImpl.java:289)
at com.goldengate.monitor.jagent.comm.ws.ManagerService.getRegistry(ManagerService.java:267)
at com.goldengate.monitor.jagent.comm.ws.ManagerWSApi.getInstanceInfo(ManagerWSApi.java:230)

Then you thought deleting and creating datastore commands would help, but you got invalid command errors in GGSCI ( cause those commands were already deprecated in the OGG version that you were using).. 

Is this what happened?

Well.. Here is the cure for you ->  Patch 31997138 - Oracle GoldenGate Monitor 12.2.1.2.210930 (PS2 BP8) (Server+Agent) 

That patch will solve it.

I will give the same message again: 

Never take any initiative. Take all the steps documented in Oracle documentation.

Follow the steps in the documentation exactly 

Follow the correct documentation.!   For this case it is ->  "Doc ID 2314622.1 How To Enable Monitoring For GoldenGate 12.3.x Targets Using Oracle Enterprise Manager 13c R2+"

 

That's the tip of the day..