Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

60 Days of Data Days! Live and on-demand sessions, challenges, study groups and more! And it's all FREE!. Join now. Learn more

spurthikommajos

Stream Oracle database changes into Microsoft Fabric Eventstream (Preview)

Introducing the new Oracle CDC Connector 

Oracle runs many of the most mission-critical systems in the enterprise, including ERP, finance, orders, and inventory. Every day, these systems record a constant stream of changes as business happens. We built the new Oracle Database CDC source connector for Microsoft Fabric Eventstream (Preview) so you can bring those changes into Fabric the moment they occur. The connector captures every insert, update, and delete as a structured change event, so an order moving to shipped, a balance dropping below zero, or an inventory count hitting reorder level shows up in Fabric right away.


Instead of waiting for a nightly extract that hands you a fresh snapshot of final state, the connector streams every change from your Oracle database into Fabric as a structured change event, complete with what the row looked like before and after. With this, users can learn exactly what changed and can act on it immediately.

 

What is CDC and why does it matter?

Change data capture (CDC) is a way of tracking data changes in a database as they happen. Instead of copying the whole table on a schedule, CDC watches the database's transaction log and records each individual insert, update, and delete at the row level.


Each change is captured as a structured event that carries the operation type (create, update, or delete) along with the row's values before and after the change. That gives you a running feed of exactly what changed and when, which downstream systems can react to in real time.


The main benefits are lower load on the source system, near real-time freshness, and full visibility into how a record evolved over time rather than just its current state.


A stream of change events can unlock real value:


It enables event-driven applications: Each change becomes a signal your systems can react to the instant it occurs, with no polling and no waiting for the next scheduled run. A new order can immediately kick off downstream processing, and a status change can wake up the right workflow.

 

It gives you change-level insight along with final state: A batch snapshot tells you a row's current values. A change event tells you the row went from “ORDER PLACED” to “SHIPPED” and preserves the prior value, so you can see the transition, measure how long it took, and understand why the data looks the way it does.


It turns every change into an action: Because each event carries the before and after detail, you can trigger workflows, fire alerts, and drive downstream updates from the change itself rather than from a re-scan of the whole table. For example, when an order row updates from “ORDER PLACED” to “SHIPPED”, that single event can send the customer a shipping notification and update the delivery dashboard, with no need to reprocess the full orders table.

 

What you can do with a change event

Once Oracle changes are flowing into Eventstream, each event is a trigger you can build on:

Route the same stream to several destinations at once: Send changes to an Eventhouse for KQL analytics and real-time dashboards, to a Lakehouse for historical analysis, and to other Fabric destinations in parallel, all from one eventstream and with no full reloads. For example, keep fine-grained order changes in an Eventhouse for a live view while a summarized copy lands in a Lakehouse for trend reporting.

 

Trigger alerts and automated actions with Activator: Set conditions on the change stream so Activator raises an alert or starts an action the moment they are met. For example, notify the customer-success team in Teams whenever a premium account balance crosses a threshold or when a shipment changes to “DELAYED”.

 

Reconstruct the story behind the data: Because deletes and updates carry the prior state, you can build an audit trail of how a record reached its current value. This is useful for compliance, debugging, and analytics on the change itself, such as measuring how long orders sit in “ORDER PLACED” before they ship.

 

Under the hood

The connector uses Oracle LogMiner, a native Oracle mechanism for reading the redo log, and works whether your database is on-premises or in the cloud. The flow has three stages:


Initial snapshot: On first connect, the connector captures a consistent snapshot of the tables you specify, giving your eventstream a complete baseline of the current state.


Continuous change capture: After the snapshot, it reads from Oracle's archived redo logs through LogMiner. Every row-level change on a monitored table becomes a structured change event, with before and after values and an operation flag (c for create, u for update, d for delete).


Real-time routing in Fabric: Once changes land in the eventstream, you process and route them to downstream destinations within Fabric, with no separate streaming infrastructure required.


It supports Oracle Database 12c (12.1) and later, including 19c, 21c, and Oracle Autonomous Database.

 

Where this makes a difference

The same capability shows up differently across industries, but the pattern is always the same. A change happens in Oracle, and something useful happens downstream within seconds.


Fraud and anomaly detection in financial services: Every transaction lands in Oracle ledgers. Streaming those changes means a suspicious pattern, such as a rapid sequence of transfers or a velocity spike on one account, can be evaluated against rules the moment each row is written and can flag the account for review automatically. The window between something happening and someone acting shrinks from hours to seconds.


Real-time subscription and billing updates in SaaS and media: Subscriptions, plan changes, and payment events live in an Oracle billing system. With CDC, an upgrade can write through to entitlements the moment it is committed, a payment failure can trigger a workflow, and a cancellation can start a win-back journey right away. A live churn and revenue dashboard stays current with each change, so teams see plan movement as it happens rather than in a daily report.


Real-time claims processing in insurance: Claims move through ERP systems as they are submitted, reviewed, and settled. With change events, a claim changing from “SUBMITTED” to “APPROVED” can trigger the payout workflow and notify the customer, while a claim flagged for review can route to an adjuster right away. The prior state is preserved, so you can measure how long claims sit at each stage and spot bottlenecks.


In each case the architecture stays clean and predictable. The connector captures the initial state, streams subsequent changes into Fabric, and a downstream destination stays continuously up to date, without additional ETL pipelines or separate CDC infrastructure. Data moves from an Oracle transaction to Fabric analytics, alerts, and workflows in real time.

 

What setup looks like

Getting started is mostly about making sure Oracle is ready to share its change history and giving the connector a dedicated identity with just enough access to read those changes and the tables you care about. This keeps the integration secure and easy to reason about.

 

From there, connecting inside Eventstream is the familiar Fabric experience: add the Oracle C. DC source, point it at your database endpoint, and select the tables you want to watch.

 

Figure: Adding the Oracle Database CDC source in Eventstream: This step shows how an Oracle Database Change Data Capture (CDC) source is added to an Eventstream in Microsoft Fabric.Figure: Adding the Oracle Database CDC source in Eventstream: This step shows how an Oracle Database Change Data Capture (CDC) source is added to an Eventstream in Microsoft Fabric.

 

Figure: Configuring the Oracle connection and credentials: After selecting Oracle Database CDC as the source, the connection details and authentication credentials must be configured to establish secure communication with the Oracle database.Figure: Configuring the Oracle connection and credentials: After selecting Oracle Database CDC as the source, the connection details and authentication credentials must be configured to establish secure communication with the Oracle database.

 

Figure: Review Streams: After the Oracle CDC source has been configured, the stream can be transformed and routed to different destinations, such as a Lakehouse, Spark Notebook, Activator, etc..Figure: Review Streams: After the Oracle CDC source has been configured, the stream can be transformed and routed to different destinations, such as a Lakehouse, Spark Notebook, Activator, etc..

 

 



 

 

A few options let you tune the connector to your environment, including how it handles its first pass over the data and how it coexists with live workloads. The full set of prerequisites and configuration options is covered in the Add Oracle Database CDC source to an eventstream (preview) documentation.

 

Bring your Oracle data into Microsoft Fabric today

Oracle holds some of the most important operational data in the enterprise. The Oracle Database CDC source connector closes the gap between that data and real-time analytics, alerts, and event-driven apps in Microsoft Fabric, without asking you to build or maintain a separate change-capture stack.


The best way to see what it can do is to try it on your own data. Spin up an eventstream in Microsoft Fabric, add the Oracle Database CDC source, and watch your first change events stream in within minutes. Start with a single table, point a dashboard or alert at it, and turn Oracle database changes into real-time insights and actions.


For the full configuration guide, including prerequisites and connection options, check out the documentation on adding Oracle Database CDC source to an eventstream.

 

We'd love your feedback! If you found this post helpful, give it a thumbs up.

Comments

@spurthikommajos Great to see this native Oracle CDC connector roll out. It saves significant engineering time and compute by eliminating the need to maintain separate scheduled batch extraction pipelines.