Migrating Oracle Databases to Exadata on Azure: What DBAs Need to Know

On this page

1. 01 · Two Projects in One
2. 02 · The Migration Path Into Azure
3. 03 · Preparing the Source Database
4. 04 · What Changes for the DBA After the Move
5. 05 · Monitoring, Security and Identity in Azure
6. 06 · The Cutover Runbook
7. 07 · Common DBA Mistakes to Avoid
8. 08 · Key Takeaways
9. 09 · Frequently Asked Questions

01 · Two Projects in One

DBA brief · On-premises Oracle to Exadata on Azure

"After cutover, who patches the cells?"

That question usually comes late, in the week before go-live, from a DBA who has run Exadata on-premises for years. The answer is: not you. On Oracle AI Database@Azure (generally available since December 2023 as Oracle Database@Azure) Oracle owns everything below the guest virtual machines, including storage servers, firmware and the hypervisor. You still own the databases, the Grid Infrastructure and database homes, the guest operating system updates, and the backup and recovery strategy.

The migration itself is familiar territory. Zero Downtime Migration (ZDM), Data Guard, RMAN and Data Pump do the work, exactly as they would for a move between two of your own data centers. What changes is the path, which runs over Azure ExpressRoute into a delegated subnet in an Azure VNet, and the staging, which can use Azure Blob Storage or OCI Object Storage. Plan both projects together, and the go-live week is uneventful.

02 · The Migration Path Into Azure

Answer: A typical physical migration sends redo from the on-premises primary over Azure ExpressRoute to a Data Guard standby on the Exadata VM cluster in a delegated subnet. The initial copy is either restored from a backup staged in Azure Blob Storage or OCI Object Storage, or restored directly from the source over the network. ZDM orchestrates every step.

The figure below is drawn top to bottom, because that is how the data moves. Your data center is at the top, with the source primary, its RMAN backups and the ZDM host. ExpressRoute private peering carries everything into Azure. The target Exadata VM cluster sits in the delegated subnet of a database spoke VNet, with a storage account alongside for staging. The OCI parent region on the right builds and patches the cluster and offers an alternative staging and backup destination.

The purple dashed line is the one that matters at cutover: as long as Data Guard redo keeps flowing and the standby applies it, switchover is a matter of minutes. The black backup path is used once, to instantiate the standby. If ExpressRoute bandwidth is tight, that initial copy is where your schedule slips.

03 · Preparing the Source Database

Answer: Before ZDM can build a standby, the source needs to be in ARCHIVELOG mode with force logging, have a password file and TDE wallet ready to copy, use a supported version and patch level, and be reachable from the ZDM host over SSH. ZDM's evaluation run checks most of this for you.

Most failed first runs are source prerequisites, not cloud problems. Work through them early, ideally during the assessment phase, because some of them, such as enabling TDE or force logging, need their own change window.

-- On the source primary
SELECT log_mode, force_logging, platform_name FROM v$database;
ALTER DATABASE FORCE LOGGING;
-- TDE is expected on cloud targets: check the wallet
SELECT wrl_type, status, wallet_type FROM v$encryption_wallet;
-- Size the redo stream you must ship over ExpressRoute
SELECT TRUNC(first_time,'HH') hr, ROUND(SUM(blocks*block_size)/1024/1024) mb
FROM   v$archived_log WHERE first_time > SYSDATE-7 AND dest_id=1
GROUP  BY TRUNC(first_time,'HH') ORDER BY mb DESC FETCH FIRST 5 ROWS ONLY;

The last query gives you the five busiest hours of redo over the past week. That peak, not the average, decides whether ExpressRoute can keep the standby current during month-end processing. If it cannot, the standby falls behind exactly when you least want it to.

04 · What Changes for the DBA After the Move

Answer: On Oracle Database@Azure, Oracle manages the Exadata hardware, storage servers, firmware and hypervisor. DBAs keep the guest VMs, Grid Infrastructure and database patching, backup configuration, monitoring, security and performance, but do most of it through cloud tooling such as dbaascli and the console instead of opatch scripts and cellcli.

This is the change that surprises experienced Exadata DBAs most. Commands you used for years, such as cellcli on the storage servers or patchmgr for infrastructure updates, are no longer yours to run. In exchange, a lot of undifferentiated work disappears: no firmware upgrades, no storage server replacements, no quarterly cell patching weekends.

The side-by-side view below lists the tasks DBAs ask about most. Green rows have moved to Oracle. Blue rows stay with you but use different tools. Yellow rows are shared, because the service provides a default and you decide whether to add your own.

Look closely at the backups row. Automatic backups exist, but you still decide whether to enable them, where they go and how long they are kept, and you still own restore testing. "The cloud backs it up" is not a recovery strategy until someone has restored from it.

New tools for familiar jobs

# Grid Infrastructure and database patching on the VM cluster
dbaascli grid patch --targetVersion 19.28.0.0.0
dbaascli dbHome create --version 19.28.0.0.0
dbaascli database move --dbname SALES --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_2

# On-demand backup to the configured destination
dbaascli database backup --dbname SALES --start

Out-of-place patching with a new home and dbaascli database move is the pattern to adopt: it keeps rollback simple and works in a rolling fashion across the RAC nodes. Infrastructure maintenance by Oracle runs in maintenance windows you can schedule, so align them with your own patch calendar.

05 · Monitoring, Security and Identity in Azure

Answer: Database metrics and events from Oracle Database@Azure surface in Azure Monitor and Log Analytics alongside OCI's own metrics, and you can keep Oracle Enterprise Manager for deep database diagnostics. Microsoft Entra ID can authenticate database users, and encryption keys can live in OCI Vault, Azure Key Vault or a local wallet.

Decide early who looks at which screen. Azure operations teams will expect alerts in Azure Monitor and dashboards in their existing workspaces. DBAs will want AWR, ASH and SQL Monitor, which still come from the database itself or from Enterprise Manager. Both are valid; the mistake is assuming the other team is watching.

06 · The Cutover Runbook

Answer: A good cutover runbook starts two weeks before go-live with an in-sync standby, includes a dress rehearsal on a snapshot standby, freezes changes three days out, switches over at T0 and keeps the old primary as a standby for a week. Every step has an owner, a check and a rollback.

The timeline below is the runbook we use as a starting template. The left and right boxes alternate only for readability; the order is strictly top to bottom. The colours mark the type of milestone: blue for preparation, yellow for decision gates, red for the switchover itself, green for the work after go-live that teams tend to under-plan.

The T-7 dress rehearsal is the step that pays for itself. Converting the standby to a snapshot standby lets the application team run real tests against Exadata on Azure, with real data, then discard the changes and resume redo apply, all without touching production.

1. T-14: confirm sync. ZDM is paused after Data Guard configuration. Check transport and apply lag in v$dataguard_stats every day, including during batch peaks.
2. T-7: rehearse. Convert to a snapshot standby, run application tests, time the switchover steps, then convert back and let redo catch up.
3. T-3 and T-1: decide. Freeze changes, verify a backup from the target restores, stage the connect string or DNS change, hold the go / no-go call.
4. T0: switch over. Resume the ZDM job or run the Data Guard switchover, open the new primary, repoint applications and run smoke tests.
5. T+1 to T+7: stabilise. Compare AWR against the source baseline, fix plan regressions, tune alerts, and only then retire the old primary.

Keep the old primary as a standby until the business signs off. A rollback should be a second switchover, never a restore.

07 · Common DBA Mistakes to Avoid

These are the issues that show up most often in post-migration reviews. Each one is easy to prevent if it is on the checklist before cutover.

1. Sizing on averages. Size the VM cluster from AWR peaks, and ExpressRoute from peak redo, not from weekly averages.
2. Forgetting the client side. Applications must use the SCAN name and a dedicated service. Hard-coded host names from the old cluster break at T0.
3. Upgrading in the same weekend. Migrate physically at the same version, stabilise, then upgrade with AutoUpgrade in a later window.
4. Leaving backups at defaults. Set retention, destination and schedule deliberately, and restore-test before you decommission the source.
5. Ignoring the maintenance calendar. Oracle's infrastructure maintenance windows and your own patching should not collide with month-end or the cutover itself.

08 · Key Takeaways

1. Familiar tools, new path. ZDM, Data Guard, RMAN and Data Pump move the database; ExpressRoute and the delegated subnet carry it.
2. Size the link for peak redo. The busiest hour of redo decides whether the standby keeps up.
3. Oracle runs everything below the guest VM. No more cellcli or firmware; you keep databases, homes, guest OS updates, backups and performance.
4. Rehearse on a snapshot standby. Test with real data on the real target a week before cutover, without touching production.
5. Keep the way back open. The old primary stays a standby until sign-off, so rollback is a switchover.

09 · Frequently Asked Questions