Oracle GoldenGate with Oracle Database@Azure
Oracle GoldenGate with Oracle Database@Azure
Article Overview
Oracle GoldenGate is the piece that turns a database into a moving stream of change — capturing committed transactions as they happen and delivering them, in near real time, to another database that might be in the same cloud, a different cloud, or on-premises. On Oracle Database@Azure that capability is now available as a fully managed service, provisioned for the platform and able to connect databases across Azure, OCI, and your datacenter. This guide is a dedicated tour of GoldenGate on this platform: how the replication architecture actually works — Extract, trails, Distribution, Replicat — the managed OCI GoldenGate service and how it attaches to the platform, and then the four use cases that matter most: real-time replication, zero-downtime migration, reporting databases, and cloud integration into the Azure analytics ecosystem. It leans practical, with configuration examples and diagrams throughout. Where migration was covered as one method among several in the migration guide on this blog, here GoldenGate is the whole subject.
1.What GoldenGate Does
At its core, GoldenGate does one deceptively powerful thing: it captures the committed changes from a source database and applies them to one or more targets, continuously and with very low latency. It does this by reading the database's transaction log rather than querying the tables, so it sees every insert, update, and delete as a stream of change records — a technique known as change data capture. Because it works from the log, it imposes little overhead on the source and it never misses a committed transaction.
That single capability underpins a surprising range of outcomes. Keep two databases continuously in sync and you have real-time replication. Sync an old database to a new one and switch over when they match, and you have a migration with almost no downtime. Feed a copy that is used only for queries, and you have a reporting database that never burdens production. Stream the changes into a cloud analytics platform, and you have live data integration. All four — the subjects of this article — are the same underlying mechanism pointed at different destinations.
GoldenGate turns a database from a place data sits into a stream of change you can deliver anywhere — another cloud, a reporting copy, an analytics platform — in near real time, without slowing the source.
Log-based capture is why it is low-impact
The reason GoldenGate can run against a busy production database without dragging it down is that it reads the transaction log (the redo), not the tables. The database already writes that log for its own recovery; GoldenGate simply mines it. That is what lets replication happen continuously, at scale, with minimal effect on the source workload — and it is the foundation every use case in this article stands on.
2.The Replication Architecture
To use GoldenGate well you need a clear picture of its moving parts. Modern GoldenGate uses a microservices architecture, but the logical pipeline — the thing you actually reason about — has four stages that carry a change from source to target.
| Component | What it does |
|---|---|
| Extract | Reads the source redo and captures committed changes as trail records — the capture engine |
| Trail | A durable, platform-independent file of change records that decouples capture from delivery |
| Distribution | Sends trail data across the network to the target environment, securely |
| Replicat | Reads the delivered trail and applies the changes to the target database — the apply engine |
Trails are what make it resilient
The trail files are more than an implementation detail — they are why GoldenGate tolerates trouble. Because captured changes are written to a durable trail before being shipped and applied, a network interruption or a target outage does not lose data: capture keeps writing to the trail, and delivery resumes from where it left off when the path recovers. That decoupling of capture from apply is the quiet reason replication survives the real world.
3.The Managed Service on the Platform
The important recent development is that you no longer have to build and run GoldenGate yourself to use it with Oracle Database@Azure. OCI GoldenGate is available as a fully managed service for the platform — you design, run, and monitor replications without provisioning or maintaining the compute that runs the engine. It became generally available for Oracle Database@Azure in October 2025, and it carries the same features and behaviour as OCI GoldenGate running natively in OCI.
3.1 How it attaches to the platform
Provisioning follows the platform's cross-cloud pattern. You create the Azure-side anchors — a Resource Anchor and a Network Anchor — that root the service in your Azure networking, and then create the GoldenGate deployment from the OCI Console, associated with those anchors. The deployment is the running replication service; to it you assign connections to your source and target databases, and then design the Extracts and Replicats that move the data. Once the anchors and deployment exist, the day-to-day work is defining and monitoring replications, not managing servers.
| Concept | Role in a managed replication |
|---|---|
| Resource & Network Anchor | Azure-side objects that root the GoldenGate service in your Azure network |
| Deployment | The managed replication service instance — the running GoldenGate environment |
| Connection | A defined, credentialed link to a source or target database |
| Extract / Replicat | The capture and apply processes you configure on the deployment |
| Distribution path | Links two deployments — needed for heterogeneous (e.g. Oracle-to-non-Oracle) flows |
Co-locate the deployment with the database for latency
A practical best practice: create the GoldenGate deployment in the same OCI region as your Oracle Database@Azure database, so the capture-and-apply path is short and end-to-end latency stays low. Replication lag is partly a function of distance, and putting the engine next to the database it serves is the simplest way to keep lag small. Where a flow crosses to another cloud or on-premises, size the interconnect for the change volume so the network is never the bottleneck.
3.2 Self-managed remains an option
The managed service is the path of least resistance, but you can also run GoldenGate yourself — deploying the software within your Azure subscription and connecting to databases across Azure, OCI, and on-premises — if you need full control over versions and configuration, or you are extending an existing self-managed estate. The trade-off is the familiar one: the managed service removes operational burden, while self-managed maximises control. For most new work on the platform, the managed service is the sensible default.
4.Replication Topologies
GoldenGate's flexibility comes from the shapes the flow can take. A handful of topologies cover the great majority of designs, and knowing which one a use case needs is half the design work.
Unidirectional
One source, one target, changes flowing one way. The basis of migration, reporting offload, and most cloud-integration flows — the simplest and most common shape.
Bidirectional (active-active)
Two databases each replicating to the other, both taking writes. Powerful for active-active availability, but requires conflict detection and resolution — the advanced end.
Broadcast (one-to-many)
One source feeding several targets — a production database fanning changes out to multiple reporting or regional copies at once.
Consolidation (many-to-one)
Several sources converging into one target — regional databases feeding a central analytics or reporting store.
⚠️ Active-active is powerful but raises the bar
Bidirectional replication where both sides accept writes is genuinely useful — for active-active availability or geographically distributed writes — but it introduces the hardest problem in replication: conflicts, when the same row is changed on both sides at once. It demands a deliberate conflict-detection-and-resolution design and disciplined application behaviour. Reach for it when the requirement truly justifies it, and treat the conflict strategy as a first-class part of the design, not an afterthought. For most needs, a unidirectional topology is simpler and sufficient.
5.Configuring a Replication
With the managed service, much of the configuration is done through the console and its guided flows, but it helps to see the underlying shape — the parameters that define an Extract and a Replicat — because that is what you are really specifying. The examples below are illustrative of the classic parameter style; on the managed service you supply the equivalents through the deployment.
5.1 Prepare the source
Capture needs the database configured to give it what it requires: supplemental logging so the redo carries enough column detail to build change records, and archive log mode. This is a one-time source preparation.
-- Enable the minimal supplemental logging GoldenGate needs to
-- reconstruct changes accurately from the redo stream.
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
-- Enable GoldenGate replication at the database level.
ALTER SYSTEM SET ENABLE_GOLDENGATE_REPLICATION = TRUE SCOPE=BOTH;
-- Confirm the database is in archivelog mode (required for capture).
SELECT log_mode FROM v$database; -- expect: ARCHIVELOG
-- Add table-level supplemental logging for the schema being replicated
-- (done via GoldenGate's ADD TRANDATA, shown next).5.2 Define the Extract
The Extract parameter file names the capture process, points at the source, and lists the tables to capture. Conceptually:
EXTRACT ext1
-- Credentials alias for the source database connection
USERIDALIAS src_alias DOMAIN OracleGoldenGate
-- Where captured change records are written (the trail)
EXTTRAIL ea
-- Report a heartbeat so lag is visible
TRANLOGOPTIONS INTEGRATEDPARAMS (max_sga_size 256)
-- Tables to capture (schema.table; wildcards allowed)
TABLE sales.orders;
TABLE sales.order_items;
TABLE sales.customers;-- Add table-level supplemental logging for the captured tables
DBLOGIN USERIDALIAS src_alias DOMAIN OracleGoldenGate
ADD TRANDATA sales.orders
ADD TRANDATA sales.order_items
ADD TRANDATA sales.customers
-- Register and start integrated Extract, then create its trail
REGISTER EXTRACT ext1 DATABASE
ADD EXTRACT ext1 INTEGRATED TRANLOG BEGIN NOW
ADD EXTTRAIL ea EXTRACT ext1
START EXTRACT ext15.3 Define the Replicat
On the target, the Replicat reads the delivered trail and applies the changes. A parallel Replicat applies in parallel to keep up with a busy source — the recommended way to minimise apply lag.
REPLICAT rep1
-- Credentials alias for the target database connection
USERIDALIAS tgt_alias DOMAIN OracleGoldenGate
-- Apply in parallel to keep pace with the source
MAP sales.orders, TARGET sales.orders;
MAP sales.order_items, TARGET sales.order_items;
MAP sales.customers, TARGET sales.customers;DBLOGIN USERIDALIAS tgt_alias DOMAIN OracleGoldenGate
-- Parallel Replicat consumes the remote trail 'ea'
ADD REPLICAT rep1 PARALLEL EXTTRAIL ea
START REPLICAT rep1
-- Check it is running and current
INFO REPLICAT rep1
STATS REPLICAT rep1Instantiate first, then let change data catch up
A replication starts with an initial load — instantiating the target with a consistent copy of the data as of a known point — after which Replicat applies the change stream captured from that point forward to close the gap and stay current. Get the instantiation point and the capture start point aligned (Data Pump with an SCN is the classic pairing) and the target converges cleanly. Misalign them and you get missing or duplicated rows — so treat the handoff between initial load and change apply as the delicate step it is.
6.Use Case: Real-Time Replication
The foundational use case is simply keeping two databases continuously in sync. A committed change on the source appears on the target moments later, so the target is a live, queryable mirror rather than a stale nightly copy. On this platform the two databases might both be Oracle Database@Azure instances in different regions, or a Database@Azure primary feeding an on-premises or second-cloud copy.
6.1 Why it is more than a standby
Data Guard already gives you a physical standby for high availability and disaster recovery — and for pure DR it is usually the right tool, as the HA/DR guide on this blog discusses. GoldenGate replication is different in kind: it is logical, so the target is open for read and write while replication runs, can have a different structure, can be a different database version, and can even be a non-Oracle database. That openness is what makes the same mechanism serve reporting, migration, and integration, not just resilience.
| Property | Data Guard standby | GoldenGate target |
|---|---|---|
| Nature | Physical block-for-block copy | Logical change replay |
| Target openness | Read-only (Active Data Guard) | Open read-write while replicating |
| Structure / version | Identical to primary | Can differ; cross-version possible |
| Target type | Oracle only | Oracle or non-Oracle |
| Best for | DR and HA | Migration, reporting, integration, active-active |
They are complementary, not competing
It is worth being clear that GoldenGate does not replace Data Guard — many serious estates run both, Data Guard for zero-compromise DR of the primary and GoldenGate for the logical flows (a reporting copy, a migration, a feed into analytics) that Data Guard cannot serve. Choosing between them is really choosing the right tool per requirement; the two together cover a wider set of needs than either alone.
7.Use Case: Zero-Downtime Migration
The use case that most often justifies GoldenGate is migrating into Oracle Database@Azure with almost no downtime. The migration guide on this blog surveys several methods; GoldenGate is the one to reach for when the business simply cannot accept a long outage — a system that has to stay up through the move.
7.1 The pattern
The shape is always the same. Stand up the target on Database@Azure, take a consistent initial copy of the source, and start GoldenGate replicating the change stream from the copy's point forward. The source stays fully live and in production the entire time; the target continuously catches up and then tracks the source in near real time. When you are ready, you cut over — a brief, controlled switch of the application to the target — during a small window when the two are in sync. Downtime is measured in minutes, not the hours or days a copy-and-switch migration would need.
7.2 Why GoldenGate for the hardest migrations
Beyond low downtime, GoldenGate brings advantages that matter on difficult moves: because it is logical, it can migrate across database versions and even across endian platforms, and it gives you a safety net — if something looks wrong after cutover, the old source is still there and current enough to fall back to. It also allows validation of the target under real replicated data before you commit. For a mission-critical system that cannot tolerate a big-bang migration, that combination is hard to beat.
✅ Keep a fallback path until you are confident
The quiet superpower of a GoldenGate migration is reversibility. Before cutover, consider setting up the reverse flow so that once you switch to the target, changes there can replicate back to the old source for a while. That keeps the old system a viable fallback for a grace period after go-live, so a problem discovered an hour later is a controlled switch-back rather than a crisis. Dismantle the safety net only once the new platform has proven itself.
8.Use Case: Reporting Databases
A perennial tension in any busy system is that heavy reporting and analytics queries compete with transactional work for the same resources — a big month-end report can slow the checkout it runs beside. GoldenGate resolves this by maintaining a separate, continuously updated reporting copy of the data, so analysts and dashboards query the copy while production serves customers undisturbed.
8.1 Why a live replica beats a nightly extract
Many organisations still feed reporting from an overnight batch extract, which means reports are always a day stale and the nightly job is a fragile, heavy operation. A GoldenGate reporting replica is instead current to within seconds and updated continuously with low overhead — so dashboards reflect reality, not yesterday, and there is no brittle nightly window to protect. Because the target is logical, the reporting copy can also be shaped for queries — different indexing, or a subset of tables — without touching production.
| Aspect | Nightly extract | GoldenGate replica |
|---|---|---|
| Freshness | Up to a day stale | Current to seconds |
| Load on production | Heavy nightly spike | Low, continuous |
| Failure window | Fragile batch job | Resilient stream via trails |
| Report-time impact on OLTP | None (but data is old) | None (and data is live) |
Offloading reads protects the transactional workload
The real win of a reporting replica is isolation: the analytical workload that used to steal cycles from the transactional one now runs on its own copy, so the two never contend. For a mission-critical OLTP system, moving reporting off the primary is one of the cleaner ways to protect the critical path — and GoldenGate keeps that offloaded copy live rather than stale, which is what makes it acceptable to the business.
9.Use Case: Cloud Integration
The fourth use case points GoldenGate outward, into the wider Azure and cloud data ecosystem. Because GoldenGate can deliver to non-Oracle targets, it becomes a real-time bridge from the operational Oracle database into analytics platforms — feeding the change stream continuously into the places where the business does its large-scale analysis and AI.
9.1 Feeding the Azure analytics estate
GoldenGate can stream changes toward heterogeneous destinations — the managed service has been extending its reach into targets across the analytics landscape, including Microsoft Fabric event streams. That makes it an alternative or complement to the zero-ETL mirroring approach covered in the Fabric-integration guide on this blog: where mirroring is the frictionless default for getting Oracle data into Fabric, GoldenGate is the option when you need transformation in flight, heterogeneous targets, or replication patterns that mirroring does not cover. For Oracle-to-Oracle and demanding cross-system flows, it is the workhorse.
Real-time analytics feed
Stream operational changes into an analytics store or lakehouse continuously, so analysis runs on current data rather than a periodic dump.
Heterogeneous targets
Deliver to non-Oracle destinations via a second deployment and a distribution path — the pattern for cross-technology integration.
Transformation in flight
Filter, map, and transform data as it moves, so the target receives it in the shape the consuming system wants.
9.2 Heterogeneous flows use two deployments
One practical detail worth knowing: when the source and target are different technologies — say Oracle to a non-Oracle analytics target — the managed service uses a separate deployment per technology, joined by a distribution path. You capture on the Oracle deployment and deliver into the other, with the path carrying trail data between them. It is a small architectural wrinkle, but it explains why a heterogeneous integration looks different from a straight Oracle-to-Oracle flow.
✅ Choose GoldenGate or mirroring by what the flow needs
For getting Oracle data into the Azure analytics world you now have two good tools, and the choice is about fit. If you want the simplest possible path to analytics-ready Oracle data in Fabric, the zero-ETL mirroring approach is hard to beat. If you need in-flight transformation, non-Fabric or non-Oracle targets, bidirectional or complex topologies, or the same engine that also runs your migrations and reporting replicas, GoldenGate is the more capable, more general tool. Many estates use both, each where it is strongest.
10.Monitoring Lag and Health
A replication you are not watching is a replication you cannot trust. The single most important thing to monitor is lag — how far behind the target is — because lag is your real-time exposure: in a migration it is how long cutover will take to drain, in a reporting replica it is how stale the reports are, and in any flow a growing lag is the early warning of trouble.
10.1 What to watch
| Signal | Why it matters |
|---|---|
| Extract / Replicat lag | The core health metric — a rising trend means capture or apply is falling behind |
| Process status | Extract and Replicat should be running, not abended — a stopped process is a stalled flow |
| Trail growth | Trails growing without draining signals the target or network cannot keep up |
| Apply throughput | Operations applied per second, versus the source change rate — the balance to keep |
| Errors / discards | Rows that failed to apply — must be investigated, not ignored |
The managed service surfaces this through its monitoring, and a heartbeat table gives you an end-to-end lag measurement you can query and alert on. Classic commands express the same intent:
-- Overall lag and status of all processes
INFO ALL
-- Detailed lag for a specific process
LAG EXTRACT ext1
LAG REPLICAT rep1
-- Throughput and applied-operation statistics
STATS REPLICAT rep1, TOTALSONLY *
-- Heartbeat gives true end-to-end lag; query the heartbeat view
-- on the target to trend and alert on replication latency.Alert on lag trend, connect it to your monitoring
Wire GoldenGate lag into the same observability picture as the rest of the platform — the monitoring guide on this blog covers unifying signals in Azure. What you want is an alert on lag trend, not just an absolute threshold: a steadily climbing lag is a developing problem even before it crosses a line. Catch it on the way up and you fix a slow apply calmly; catch it only at the threshold and you are already behind.
11.Pitfalls and Best Practices
| Pitfall | Best practice |
|---|---|
| Forgetting supplemental logging | Enable it before capture — without it, change records cannot be reconstructed correctly |
| Misaligned initial load and capture start | Pair the instantiation SCN with the capture start point so the target converges cleanly |
| Serial apply on a busy source | Use parallel Replicat so apply keeps pace — serial apply is a common lag cause |
| Ignoring lag until cutover day | Monitor lag continuously and alert on the trend from the start |
| Running the engine far from the database | Co-locate the deployment in the same OCI region for low end-to-end latency |
| Undersized cross-cloud link | Size the interconnect for peak change volume so the network is not the bottleneck |
| Active-active without conflict handling | Design conflict detection and resolution up front, or avoid bidirectional entirely |
| Unhandled DDL changes | Decide how schema changes propagate — unmanaged DDL breaks apply |
| No fallback after migration cutover | Keep a reverse-replication path for a grace period so switch-back stays possible |
| Treating GoldenGate as a DR replacement | Use Data Guard for DR; GoldenGate for logical replication — they are complementary |
Nearly every GoldenGate problem is one of two things: a source that was not properly prepared for capture, or an apply that quietly fell behind. Prepare the source carefully, watch the lag relentlessly, and most of the trouble never arrives.
12.Frequently Asked Questions
Do I have to install and run GoldenGate myself on Database@Azure?
No. OCI GoldenGate is available as a fully managed service for Oracle Database@Azure — you provision a deployment (via the OCI Console, rooted by Azure Resource and Network Anchors) and define replications without managing the underlying compute. Self-managed GoldenGate within your Azure subscription remains an option if you need full control, but the managed service is the sensible default for new work.
How is GoldenGate different from Data Guard?
Data Guard maintains a physical, block-for-block standby for high availability and disaster recovery. GoldenGate does logical replication: the target is open read-write while replicating, can differ in structure or version, and can even be non-Oracle. Use Data Guard for DR and GoldenGate for migration, reporting, integration, and active-active — they are complementary, and many estates run both.
How much downtime does a GoldenGate migration need?
Typically minutes, not hours. The source stays live while GoldenGate replicates to the target; only the brief cutover, done when the two are in sync, touches availability. That is why GoldenGate is the method of choice when a system cannot tolerate a long migration outage.
Can GoldenGate replicate to non-Oracle targets?
Yes — that is central to the cloud-integration use case. It can deliver to heterogeneous targets across the analytics landscape, including Microsoft Fabric event streams and other non-Oracle systems. Heterogeneous flows use a separate deployment per technology, joined by a distribution path.
GoldenGate or Fabric mirroring for getting Oracle data into Azure analytics?
Both are valid; choose by fit. Zero-ETL mirroring is the simplest path to analytics-ready Oracle data in Fabric. GoldenGate is the choice when you need in-flight transformation, non-Fabric or non-Oracle targets, bidirectional or complex topologies, or one engine that also handles migration and reporting. Many estates use both where each is strongest.
What is the most important thing to monitor?
Lag — how far the target trails the source. It is your real-time exposure: cutover drain time in a migration, report staleness in a replica, and the earliest warning of trouble in any flow. Alert on the lag trend, not just an absolute threshold, and wire it into your platform monitoring.
What preparation does the source database need?
Supplemental logging so the redo carries enough detail to reconstruct changes, GoldenGate replication enabled, archivelog mode, and table-level TRANDATA on the replicated tables. This one-time source preparation is essential — skipping supplemental logging is a classic cause of broken replication.
Is active-active replication supported?
Yes, GoldenGate supports bidirectional active-active topologies, but they require a deliberate conflict-detection-and-resolution design because the same row can change on both sides. Use it when the requirement genuinely justifies it, and treat the conflict strategy as a first-class part of the design. For most needs a unidirectional flow is simpler and enough.
13.Key Takeaways
The short version
• One mechanism, four use cases. Log-based change capture and apply underpins real-time replication, zero-downtime migration, reporting replicas, and cloud integration alike.
• Know the pipeline. Extract captures from redo, trails buffer durably, Distribution ships across the network, Replicat applies — the decoupling by trails is what makes it resilient.
• Use the managed service. OCI GoldenGate is fully managed for Database@Azure (GA October 2025) — provision a deployment via anchors and design replications without running servers.
• GoldenGate complements Data Guard. Data Guard for physical DR; GoldenGate for logical flows — open, cross-version, cross-technology targets. Run both where each fits.
• Migration is its killer app. The source stays live through replication; only a brief in-sync cutover touches availability — keep a reverse-flow fallback for a grace period.
• Watch the lag. Lag is the core health signal and your real-time exposure — prepare the source properly, apply in parallel, and alert on the trend.
Oracle GoldenGate is, in the end, a single elegant idea — capture committed change from the log and deliver it anywhere, continuously — and on Oracle Database@Azure that idea is now available as a managed service that spans Azure, OCI, and on-premises. The reason it earns a dedicated place in the platform's toolkit is its range: the same engine that migrates a mission-critical system into the cloud with minutes of downtime also keeps a live reporting replica current, feeds the Azure analytics estate in real time, and, where the need justifies it, runs active-active across regions.
The practical path is unglamorous and reliable. Prepare the source for capture, instantiate the target cleanly, apply in parallel, and watch the lag as if it mattered — because it does. Choose GoldenGate when you need logical, open, heterogeneous, or low-downtime data movement, and reach for Data Guard or Fabric mirroring when those fit the requirement better; the mark of a good architect here is matching the tool to the flow rather than forcing one tool onto every problem. Do that, and GoldenGate becomes the quiet, dependable circulatory system of a hybrid, multi-cloud Oracle estate — keeping data moving to wherever the business needs it, in near real time, without ever asking the source to slow down.
GoldenGate service availability, managed-service capabilities, supported targets and regions, provisioning steps, and platform integration details reflect Oracle and Microsoft documentation available at the time of writing and change frequently — verify current features, supported source and target types, regions, and configuration steps against Oracle and Microsoft documentation before implementing. All parameter files, SQL, and commands are illustrative, use placeholder names and values, and must be validated against your own environment and current documentation before use. This article is independent commentary and is not affiliated with, endorsed by, or sponsored by Oracle or Microsoft.
Comments