Home / OCI

OCIHow-toAdvanced

Transformation: on-premises Exadata to Exadata Database Service (OCI or Cloud@Customer)

Replace an ageing on-premises Exadata with Exadata Database Service on Dedicated Infrastructure in OCI or Exadata Cloud@Customer in your datacentre. Choose the deployment, size it, migrate databases with Data Guard and adapt operations to the cloud tooling.

Deepak Bhardwaj3 min read

Applies toOracle Exadata X7–X9 on-prem sources, Exadata Database Service on Dedicated Infrastructure (ExaDB-D), Exadata Cloud@Customer (ExaDB-C@C), Oracle Database 19c/23ai

Choose the target

Need Choose
Data must stay in your datacentre (sovereignty, latency to on-prem apps) Exadata Cloud@Customer
Apps moving to OCI, DR in another region Exadata Database Service on Dedicated Infrastructure
Apps in Azure/AWS/GCP Oracle Database@Azure / @AWS / @Google Cloud

All three use the same control plane and tooling (dbaascli, OCI console/API), so operations are similar.

1. Size

  • Pull AWR data for peak periods across all databases: CPU (convert to ECPU/OCPU), IOPS, storage incl. RECO, memory.
  • Consolidation: ExaDB lets you run several VM clusters on one infrastructure — separate prod/non-prod or business units.
  • Start with fewer enabled cores and scale online; licence (BYOL vs. included) follows enabled cores.

2. Build

  1. Exadata infrastructure (rack shape, compute and storage servers).
  2. VM cluster(s): enabled cores, memory, storage, Grid Infrastructure version.
  3. Database homes at the RU you want, then databases.
oci db cloud-vm-cluster list --compartment-id $C --query 'data[].{name:"display-name", cores:"cpu-core-count", state:"lifecycle-state"}' --output table

(Cloud@Customer uses oci db vm-cluster commands instead of cloud-vm-cluster.)

3. Migrate

Data Guard (physical) is the standard path for same-version, same-endianness Exadata sources:

  1. Create a database home with the same version/RU (or newer RU).
  2. Create the standby from an RMAN backup or DUPLICATE ... FOR STANDBY FROM ACTIVE DATABASE.
  3. Register it with the cloud tooling (follow the documented procedure so dbaascli manages it — or use ZDM physical online, which does this for you).
  4. Switch over in the change window; the old Exadata becomes standby for rollback.

For upgrade-during-migration (e.g. 12.2 → 19c) or non-CDB → PDB, use ZDM with AutoUpgrade, or Data Pump/GoldenGate.

4. Operations that change

On-prem habit Cloud equivalent
Patching with OPatch manually Infrastructure patched by Oracle (you pick windows); DB homes patched via console/dbaascli
Custom backup scripts Automatic backups (Object Storage, Autonomous Recovery Service, or local for C@C)
Add disk/cores by purchase order Scale enabled cores and storage online
OEM for monitoring OCI Database Management, or keep OEM with agents 
dbaascli database backup --dbname ORCL --getConfig
dbaascli dbHome create --version 19.24.0.0.0

Tip

Keep custom changes inside the database layer. Changes to the Grid/OS layer outside the tooling can break cloud automation (patching, scaling).

Checklist

  • Target model chosen; sizing from AWR peaks
  • VM clusters split by environment
  • Data Guard migration rehearsed with switchover and switchback
  • Backups via cloud tooling verified with a restore test
  • Runbooks rewritten for dbaascli and console operations

Related fixes