Migrating Oracle Databases to Exadata on Google Cloud: Strategies & Best Practices

On this page

1. 01 · Why a Google Cloud Migration Needs Its Own Plan
2. 02 · The Target Landscape on Google Cloud
3. 03 · Assess the Source Before You Pick a Method
4. 04 · Choosing a Migration Strategy
5. 05 · How Data Actually Moves
6. 06 · Running a ZDM Physical Online Migration
7. 07 · Cutover, Validation and Rollback
8. 08 · Best Practices and Pitfalls on Google Cloud
9. 09 · Key Takeaways
10. 10 · Frequently Asked Questions

01 · Why a Google Cloud Migration Needs Its Own Plan

Migration playbook · Oracle to Exadata on Google Cloud

"The applications are moving to Google Cloud. What happens to the Oracle databases?"

For years the honest answer was awkward. You could rehost Oracle on Compute Engine VMs and lose Exadata features, keep the databases on-premises and accept cross-network latency, or move them to OCI and connect back over an interconnect. Oracle AI Database@Google Cloud (launched as Oracle Database@Google Cloud, generally available since September 2024) changed that: Exadata now sits inside Google Cloud data centers, operated by OCI, next to your GKE clusters and Compute Engine VMs.

That removes the platform objection, but it does not migrate a single byte for you. The source might be an 11.2 database on AIX, a 19c RAC cluster on Linux, or a non-CDB never touched by multitenant. Each needs a different method, and the choice decides how long the business is offline, how much network you need and how easy it is to roll back.

02 · The Target Landscape on Google Cloud

Answer: You migrate into an Exadata VM cluster that Oracle runs inside a Google Cloud region. Your source reaches it over Cloud Interconnect or VPN into your VPC, where client and backup subnets connect to the Oracle-operated Exadata site. ZDM, GoldenGate and staging storage sit alongside in your project.

Three Oracle services are offered through Oracle AI Database@Google Cloud, and the right target changes the migration details. Exadata Database Service on Dedicated Infrastructure (ExaDB-D) gives you whole database and storage servers. Exadata Database Service on Exascale Infrastructure (ExaDB-XS) gives you a VM cluster on shared Exadata pools billed by ECPU and storage. Autonomous AI Database removes most DBA tasks but accepts only logical migration methods, because you cannot restore an RMAN backup into it.

The topology below is the one most enterprise migrations end up with. The source data center connects over Cloud Interconnect. In your project you run a ZDM host on a Compute Engine VM, optionally a GoldenGate hub, and a staging bucket. The target VM cluster lives in the Oracle-operated Exadata site; its control plane, and optionally its backups, live in the OCI parent region.

Read the three horizontal rows as the three ways data can travel: purple dashed redo for Data Guard, purple dashed trail files through the GoldenGate hub, and solid black backup or dump files through a staging bucket. The grey ZDM lines carry only SSH orchestration, never bulk data, so the ZDM host can stay small.

03 · Assess the Source Before You Pick a Method

Answer: Run a structured assessment first: platform and endianness, database release, character set, multitenant status, size, change rate and downtime budget. Oracle's Cloud Premigration Advisor Tool (CPAT) and AWR data answer most of these questions in a day.

What to collect for every database

Run CPAT against each source with the intended target type and keep its report with the migration plan: it flags objects and features a logical method or an Autonomous target will not carry. For sizing, look at peak redo generation in AWR: a database that writes 40 MB of redo per second at month end needs that much sustained interconnect bandwidth, plus headroom.

04 · Choosing a Migration Strategy

Answer: Use ZDM physical online (Data Guard) when the source is Linux x86-64 on a supported release and downtime must be minutes. Use ZDM logical online (GoldenGate) when you must also change release, platform or structure. Use offline RMAN or Data Pump when a maintenance window of hours is acceptable.

Once the assessment is done, the decision is mechanical. Platform comes first because it removes options, downtime separates online from offline methods, and release and scope pick the exact path. Treat the flow below as a default and record any exception in your decision log.

The two online outcomes on the left are both orchestrated by ZDM, and they differ in one thing: physical keeps the database block for block, so the release must match, while logical rebuilds it, so it can absorb an upgrade, a non-CDB to PDB conversion or a character set change. The red cross-platform box is where most AIX and Solaris estates land.

05 · How Data Actually Moves

Answer: Data reaches the Google Cloud target in one of three ways: as redo shipped by Data Guard, as trail records replicated by GoldenGate after an initial Data Pump load, or as backup and dump files staged in object storage and restored on Exadata.

Each path puts a different load on your network and gives a different rollback story. The walkthrough below follows one example of each from the first byte to the cutover. The step counts are similar; where the downtime sits is not.

The tags on the right are the key reading: both online paths confine downtime to step 3, the moment applications are pointed at the new primary. The offline path pays for its simplicity with a window that grows with database size, which is why it is usually reserved for databases that fit a weekend.

Physical online: redo over Cloud Interconnect

ZDM instantiates the target with RMAN, by restoring from service over the network or from a staged backup, then configures Data Guard so redo flows to the new standby on Exadata. When you resume the paused job, ZDM switches over and the old primary becomes a standby: your fastest rollback.

Logical online: GoldenGate after an initial load

ZDM takes a Data Pump export at a known SCN, imports it into the target PDB, then starts GoldenGate replicats from that SCN. The hub can be OCI GoldenGate or GoldenGate Microservices on a Compute Engine VM. Because the target is rebuilt rather than copied, this path tolerates upgrades and structural change.

Offline: files through a staging bucket

For a weekend migration you stop the application, take an RMAN backup or a Data Pump export, copy it to a bucket, and restore or import on the target. Staging can be Google Cloud Storage, OCI Object Storage or an NFS share; check which media your ZDM release and target support before you design around one. RMAN backups to OCI Object Storage use the Oracle Database Cloud Backup Module, and the same bucket can later hold the database's regular backups.

06 · Running a ZDM Physical Online Migration

Answer: Install ZDM on a Linux host that can reach both databases over SSH and SQL*Net, prepare a response file, run an evaluation with -eval, then run the real job paused after Data Guard is configured. Resume it only in the agreed cutover window.

ZDM does most of the orchestration, but it relies on clean prerequisites. This is the sequence we use for 19c Linux sources moving to ExaDB-D or ExaDB-XS on Google Cloud.

1. Build the ZDM host. A small Compute Engine VM (Oracle Linux) in your VPC, with SSH key access to the source and target database hosts and port 1521 open both ways through the interconnect and your VPC firewall rules.
2. Create the empty target database. Provision a database on the target VM cluster with the same release, a matching DB_NAME and a unique DB_UNIQUE_NAME. ZDM replaces its datafiles during instantiation.
3. Prepare the response file. Set MIGRATION_METHOD=ONLINE_PHYSICAL, DATA_TRANSFER_MEDIUM (for example DIRECT for restore from service, or an object storage option), TGT_DB_UNIQUE_NAME and, for a non-CDB source, the non-CDB to PDB conversion option.
4. Run an evaluation. Add -eval to the migrate command. ZDM checks connectivity, versions, TDE, archive log mode and space without changing anything.
5. Run the job and pause. Use -pauseafter ZDM_CONFIGURE_DG_SRC so ZDM stops once the standby is in sync. Watch apply lag with zdmcli query job and Data Guard broker.
6. Cut over in the window. Stop the application, run zdmcli resume job, let ZDM switch over, then repoint connection strings or DNS to the new primary.

zdmcli migrate database \
  -sourcedb PRODDB -sourcenode srcdb01.corp.example \
  -srcauth zdmauth -srcarg1 user:oracle \
  -srcarg2 identity_file:/home/zdmuser/.ssh/id_rsa -srcarg3 sudo_location:/usr/bin/sudo \
  -targetnode exa-vm1 -tgtauth zdmauth -tgtarg1 user:opc \
  -tgtarg2 identity_file:/home/zdmuser/.ssh/id_rsa -tgtarg3 sudo_location:/usr/bin/sudo \
  -rsp /home/zdmuser/proddb_physical.rsp -pauseafter ZDM_CONFIGURE_DG_SRC

zdmcli query job -jobid 42
zdmcli resume job -jobid 42

07 · Cutover, Validation and Rollback

Answer: Rehearse the full cutover at least once on a copy, validate row counts, invalid objects and performance before go-live, and keep the old database as a synchronized fallback until the business signs off.

The switch takes minutes; the surrounding work takes the day. A good runbook covers freeze, switch, validate and decide.

1. Freeze. Stop batch schedulers and application tiers, confirm zero apply lag or zero GoldenGate lag, and record the final SCN.
2. Switch. Resume the ZDM job or run the Data Guard switchover, then update connect strings. A Cloud DNS record or a SCAN alias in the application configuration makes this a one-line change.
3. Validate. Compare object and row counts on key tables, recompile with utlrp.sql and check DBA_INVALID_OBJECTS, gather optimizer statistics, and run a short workload smoke test from the GKE or Compute Engine tier.
4. Decide. Keep reverse redo or reverse GoldenGate replication running for an agreed period, so you can fail back without data loss if something unexpected appears.

Plans can change after an upgrade or a statistics refresh, so capture a SQL Tuning Set on the source and run SQL Performance Analyzer on the target before users notice a regression.

A migration is finished when the business has run on the new database through a full business cycle and nobody has asked to go back, not when the switchover command returns.

08 · Best Practices and Pitfalls on Google Cloud

The same issues come up on almost every Google Cloud Exadata project, and most are about networking rather than the database.

Habits that make migrations boring

• Migrate in waves. Start with a non-critical database to validate the network, ZDM host and runbook, then move the larger ones.
• Plan backups on day one. Decide whether the target uses OCI Object Storage, Autonomous Recovery Service or Google Cloud Storage for backups, and test a restore before go-live.
• Wire up monitoring. Use Cloud Monitoring and Cloud Logging alongside OCI metrics, so operations see one picture after cutover.
• Confirm support. Method support differs by target service, release and ZDM version. Check the current ZDM documentation for your exact combination and say so in the plan.

09 · Key Takeaways

1. The target is Exadata inside Google Cloud. Oracle AI Database@Google Cloud places ExaDB-D, ExaDB-XS and Autonomous AI Database next to your applications, reached through subnets in your VPC.
2. Assessment picks the method. Platform and endianness, release, multitenant status, size, redo rate and downtime budget decide between physical, logical and offline paths.
3. ZDM does the orchestration. Physical online with Data Guard for like-for-like Linux moves, logical online with GoldenGate when you must also upgrade or restructure.
4. Network capacity is a migration dependency. Size Cloud Interconnect from peak redo and initial copy volume, and fix firewall and CIDR issues before the first rehearsal.
5. Keep a way back. Rehearse the cutover, validate with real workload checks, and keep reverse replication until the business signs off.

10 · Frequently Asked Questions