Tales From A Lazy Fat DBA

Its all about Databases, their performance, troubleshooting & much more …. ¯\_(ツ)_/¯

Posts Tagged ‘integration’

Lessons from Integrating Oracle 11g with GoldenGate – ORA-06512 ORA-06502

Posted by FatDBA on February 7, 2026

This one took time. More than I’d like to admit.

I was trying to run GoldenGate 21c Integrated Extract from a remote extraction server, sourcing redo from an Oracle 11g (11.2.0.4.201020 (October 2020 PSU)) database. Everything worked fine, I was able to create the extract, login to the database, but got a weird issue when tried to register the extract with 11g source database from remote extraction.

GGSCI (fatdbatestlab1) 7> dblogin useridalias ogg11g
Successfully logged into database.

GGSCI (fatdbatestlab1) GGREPAZUR@boom1) 8> REGISTER EXTRACT ext11g DATABASE

xxxx:xxx:xxxx   ERROR   OGG-08221  Cannot register or unregister Extract group EXT11G because of the following SQL error: OCI Error ORA 
(status = 6502-ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at "SYS.DBMS_XSTREAM_GG_ADM", line 145
ORA-06512: at "SYS.DBMS_XSTREAM_GG_ADM", line 186
ORA-06512: at line 1).

So Integrated Extract was the plan from day one. Even with that clarity, things didn’t go smoothly. Integrated Extract should work with 11g, specially with remote-extraction option due to security concerns and performance issues. The docs say so (if you are on compatible 11.2.0.4), compatibility matrices agree.

Now, just to be clear upfront .. I already knew that if I tried classic (non-integrated) extract remotely, I would hit “OGG-02022 Logmining server does not exist on this Oracle database.” .. That part wasn’t a surprise. Classic extract + remote server + 11g… yeah, that’s expected.

Yet I kept running into weird behavior that just didn’t add up. That’s when the doubt started creeping in … “Am I missing something?” “Is Integrated Extract actually usable with 11g in real life… not just on paper?”

Before touching the source server, I paused and went deeper into Oracle notes and bugs. That’s when I landed on the real issue. This wasn’t a GoldenGate 21c problem. And it wasn’t a remote extraction limitation either. It was an Oracle 11g RDBMS bug.

The Actual Root Cause was the database Bug 28367006.. Once I applied Patch 21683400 & the datapatch things finally started behaving like a sane system again.

GGSCI (fatdbatestlab1) GGREPAZUR@boom1) 8> REGISTER EXTRACT ext11g DATABASE
xxxx:xxx:xxx INFO    OGG-02003  Extract group EXT11G successfully registered with database at SCN 189381938103811.
 

It’s worth calling out that while Oracle 11g is technically supported for Integrated Extract, it is still a very old database release, and expectations need to be set accordingly. Running the latest available PSU is not optional in this kind of setup, and being aware of known bugs, defects, and architectural limitations is part of the job when working with legacy versions. In practice, if you stumble into a new or undocumented issue on 11g, Oracle Support is unlikely to engage development for a fresh bug fix, which means the only real options are workarounds, existing patches, or architectural adjustments. That reality alone makes proactive patching and careful design choices even more critical when pairing modern GoldenGate versions with older database platforms.

Hope It Helped!
Prashant Dixit

Posted in Uncategorized | Tagged: , , | Leave a Comment »

Kafka Java Client for Transactional Event Queues (TEQ), Another great feature added to Oracle 21c …

Posted by FatDBA on November 6, 2022

Hi Guys,

Recently I was testing some advance queuing functions to setup an asynchronous communication (using event queues) between few applications and users on Oracle 21c database, to build a messaging platform. I was looking for a way to connect my client side libraries to allow Kafka APIs to connect to Oracle DB.

I had no clue how to do this integration, and then I came across this official documentation which talks about a new functionality in Oracle Database Version 21c – Kafka Java Client for Transactional Event Queues (TEQ) that enables Kafka application compatibility with Oracle Database. This provides easy migration of Kafka applications to TEQ.

Oracle Transactional Event Queue (TEQ) makes it easy to implement event-based applications. It is also highly integrated with Apache Kafka. Apart from enabling apps that use Kafka APIs to transparently operate on Oracle TEQ, Oracle TEQ also supports bi-directional information flow between TEQ and Kafka, so that changes are available in TEQ or Kafka as soon as possible in near-real-time.

Apache Kafka Connect is a framework included in Apache Kafka that integrates Kafka with other systems. Oracle TEQ will provide standard JMS package and related JDBC, Transaction packages to establish the connection and complete the transactional data flow. Oracle TEQ configures standard Kafka JMS connectors to establish interoperability and complete the data flow between the two messaging systems.

Another great blog post on the topic : https://docs.oracle.com/en/database/oracle/oracle-database/21/adque/Kafka_cient_interface_TEQ.html#GUID-94589C97-F323-4607-8C3A-10A0EDF9DA0D

Hope It Helps!
Prashant Dixit

Posted in Uncategorized | Tagged: , , , | Leave a Comment »