Zero-downtime Oracle migration with GoldenGate

When a database cannot be switched off, we move it while the business keeps using it. We build the new database alongside the old one, keep the two in sync in real time with Oracle GoldenGate, test the new one end to end, and switch over at a moment you choose, with a tested way back. It is how we moved a 30 TB transaction database for a global retail bank with zero downtime and zero data loss.

Book a strategy call See case studies

What we cover

How GoldenGate worksChanges captured from the logs, applied to the new database
Our approachBuild alongside, keep in sync, test, then switch
Cut-over and fallbackA switch you have rehearsed, with a way back
ValidationEvidence that nothing was lost
What we offerFrom the first plan to support after the move

How GoldenGate works

Changes captured from the logs, applied to the new database

GoldenGate reads committed changes from the source database's redo logs, writes them to trail files and applies them continuously to the target. Because it works from the logs rather than querying the tables, the old and new databases can run different Oracle versions, on different operating systems and hardware. That makes it a good fit for moves that would otherwise need a long outage: an upgrade from an old release, a move off Solaris or AIX, a new data center or a cloud.

What we do

Version upgrades and hardware moves, such as 10g on Solaris to 12c RAC on AIX
Data center moves and moves to the cloud
Consolidation of several databases into one
Replication between Oracle and other engines

Our approach

Build alongside, keep in sync, test, then switch

First we size the work: the objects and data types GoldenGate handles differently, the change volume at the busiest hour, and the applications and interfaces that connect. Then we build the target, load it from a consistent point in time with Data Pump or RMAN, and start GoldenGate from that same point (the SCN), so no change is missed or applied twice. While the two databases run in sync, your teams test the new one with real data, and we compare the two table by table.

What we do

Assessment of objects, data types and change volume
Initial load from a consistent SCN
Real-time sync while you test
Table-by-table comparison of source and target

Cut-over and fallback

A switch you have rehearsed, with a way back

On the day, the applications stop writing to the old database for a short, planned moment, GoldenGate applies the last changes, the comparison runs once more and connections move to the new database. Before that day we rehearse the whole sequence and time every step. We also set up replication in the other direction, from the new database back to the old one, so that if anything unexpected appears after the switch you can go back without losing the transactions made since.

What we do

A rehearsed, timed cut-over runbook
A final comparison before connections move
Reverse replication for a tested fallback
A go or no-go decision taken with your team

Validation

Evidence that nothing was lost

We do not ask you to trust the replication. We compare row counts and checksums for every table, check the data types and objects that are known to behave differently between versions and platforms, and run your own reports and test cases against both databases. Oracle GoldenGate Veridata can automate the comparison where you hold its licence; otherwise we use our own scripts. The results are written up before the switch, so the go-ahead rests on evidence.

What we do

Row counts and checksums for every table
Object and data-type checks
Your reports and tests run on both databases
Written results before the go-ahead

What we offer

From the first plan to support after the move

We can take on the whole migration or the part you need: the plan and design, the GoldenGate setup and the move, testing after the switch, or help with a GoldenGate replication that is already running and has started to fall behind or fail. After the move, our remote DBAs can look after the new database, and our engineers have written a series of articles on GoldenGate migrations in our blog.

What we do

Migration planning and design
GoldenGate installation, configuration and the move
Post-migration testing
Rescue and support for existing GoldenGate replication

Case studies

GoldenGate Zero-Downtime Migration in practice

Client names are withheld. We are happy to share details on a call.

All case studies

Delivered
30 TB, zero downtime
Financial services
Oracle
Zero-downtime move of a 30 TB Oracle database for a global retail bank
The bank's transaction database served thousands of users around the clock. We built the new Oracle 12c RAC platform on IBM AIX alongside the old Solaris system, kept the two in sync with Oracle GoldenGate, tested everything and switched over with no downtime and no data loss.
- 30 TB moved with zero downtime
- Zero data loss at cut-over
Read the case study →
Delivered
Zero downtime
Legal technology
Oracle
Sybase to Oracle with zero downtime for an e-discovery company
Sybase was holding back a platform that processes large volumes of legal data. We converted the schema, kept both databases in sync with continuous replication, validated the data and switched over without interrupting the business.
- Zero downtime at cut-over
- No disruption to client workflows
Read the case study →

Questions

Common questions

Is a zero-downtime migration really zero?

Users keep working on the old database throughout the move. The switch itself is a short, planned pause while the last changes are applied and connections move, and it is timed in rehearsal. For a global retail bank's 30 TB transaction database, that meant zero downtime for the business and zero data loss.

Do we need a GoldenGate licence?

In most cases, yes. GoldenGate is normally licensed separately from Oracle Database, and on OCI it is also offered as a managed service paid for by use. We raise the licence question at the start, so it is settled before the plan depends on it.

Will GoldenGate slow down our production database?

It adds some load. GoldenGate reads the redo logs rather than querying tables, but it needs supplemental logging switched on, which adds a little redo, and it uses CPU, memory and disk on the server where it runs. We measure the effect on a copy at your busiest change rate before switching it on in production.

Can GoldenGate move data between different database engines?

Yes. GoldenGate can replicate between Oracle and other engines such as SQL Server, MySQL and PostgreSQL, which makes it one of the tools we use for heterogeneous migrations. A move between engines also needs the schema and code converted, which our heterogeneous migration page describes.

What if our source database is very old?

Older releases narrow the options, and some need a particular GoldenGate version or an intermediate step. We check your exact release and platform in the assessment and choose the route, which may combine GoldenGate with an upgrade of the old system first.

From the blog