Oracle GoldenGate (Streams) process disabled – Why?

It is amazing what Oracle Enterprise Manager 12c will report once it is configured for a product.  Once such product is Oracle GoldenGate.  I have stepped into a project where I’m running Oracle GoldenGate between many different environments for production purposes.   Just trying to get a handle around what is going on has been a task.  In talking with the customer, they were starting to implement Oracle Enterprise Manager 12c.   Once OEM was setup, we added the Oracle GoldenGate plug-in and started to monitor the replication environments.

Monitoring the Oracle GoldenGate environments, I noticed a warning in the Incident Manager.  The warning that was noticed was: “Status for Streams process OGG$_CGGMONX9AC55691 is DISABLED”.    I got to thinking, what is this message about?  Much more, how do I resolve this warning (I like OEM to be quite.  I started to look around MOS for answers, to my surprise, not much is written about his message.


Oracle GoldenGate, classic capture, doesn’t report these types of messages within Oracle Enterprise Manager 12c.  Classic Capture mostly reports the up and down status of Oracle GoldenGate processes.  This message had to be coming from some integrated version of the extract (first clue was the word Streams).  Keeping that Streams may be used in some way, the DBA_CAPTURE table should be able to shine a bit of light on this warning.

From a SQL*Plus prompt or an SQL IDE (prefer SQL Developer), the DBA_CAPTURE view can be queried.  


From looking at the STATUS column, I verified that I’ve found the correct record.  The PURPOSE column shows that this extract (capture) is being used for Streams.  What!?, wait a minute, I’m using Oracle GoldenGate. 

Yes, Oracle GoldenGate is being used.  If there is information in the DBA_CAPTURE view it is because the Extract has been registered (integrated) with the database some how.  The status is DISABLED, an indicator that this extract was registered for logretention:

GGSCI> stop extract cggmonx
dblogin userid ggate password ggate
GGSCI> register extract cggmonx logretention
GGSCI> start extract cggmonx

Now, that it is understood that the extract has been registered for log retention, what does this actually mean?

According to the Oracle GoldenGate 11g Reference Guide, an extract can be registered in one of two modes.

1. Database  – Enables integrated capture for the Extract group. In this mode,
Extract integrates with the database logmining server to receive
change data in the form of logical change records (LCR). Extract
does not read the redo logs. Extract performs capture processing,
filtering, transformation, and other requirements

2. Logretention – Enables an Extract group, classic capture mode, to work with
Oracle Recovery Manager (RMAN) to retain the logs that Extract
needs for recovery

As indicated a few lines up, this extract has been registered with logretention.  This means that the extract creates an underlying Streams capture process and prevents RMAN from removing any archivelogs that may be needed for replication of data.  As part of creating the underlying Streams structure, Oracle creates a queue under the Oracle GoldenGate owner (The queue name can also be found in the DBA_CAPTURE view).


Now that the root problem of the DISABLE message in Oracle Enterprise Manager 12c has been identified, how can this message be resolved?

The simplest way is to unregister the extract from the database/logretention knowing that Oracle GoldenGate configuration is using Classic Capture.  Keep in mind that when unregistering the extract, retention of archivelogs will not be enforced when RMAN backs them up and possibility removes them.  Make sure you RMAN retention policies are what you expect them to be. 

To unregister an extract that is using logretention, use the steps below:

GGSCI> stop extract cggmonx
dblogin userid ggate password ggate
GGSCI> unregister extract cggmonx logretention
GGSCI> start extract cggmonx



twitter: @dbasolved


Please follow and like:

Enquire now

Give us a call or fill in the form below and we will contact you. We endeavor to answer all inquiries within 24 hours on business days.