Exadata on Oracle Cloud Infrastructure — what OCI Exadata means for on-premises DBAs
Pro
The forward-looking post. Covers Exadata Cloud Service (ExaCS) and Exadata Cloud@Customer (ExaCC) — what they are, how they differ from on-premises Exadata, what changes for the DBA (patching, monitoring, administration), what stays the same, and whether your on-premises Exadata skills transfer directly. Gives the Oracle EBS DBA a complete picture of where Exadata is headed and how to position their skills.
Exadata — Basics to Pro Series
1. What Is Exadata
· 2. Hardware Components
· 3. Architecture Deep Dive
· 4. Smart Scan, Storage Indexes, HCC
· 5. Monitoring
· 6. Performance Tuning
· 7. Administration
· 8. Patching
· 9. EBS on Exadata
· 10. OCI Exadata
If you have been managing an on-premises Exadata system, at some point your organisation will ask about moving to the cloud — or your manager will forward an Oracle sales deck about Exadata Cloud Service. Your first question is a reasonable one: is this the same Exadata I already know, and does my experience transfer?
The answer to both is yes — with important qualifications. Oracle Exadata on OCI is the same engineered system, the same Smart Scan, the same storage cells, the same HCC, the same cellcli. But the operating model is fundamentally different. Some of what you do today on-premises, Oracle does for you in the cloud. Some of what you do on-premises, you still do in the cloud — but through different tools. And some things are genuinely new.
This article explains the three Exadata deployment options, the practical difference between ExaCS and ExaCC for a working DBA, what changes in your day-to-day role, and where your on-premises skills apply directly.
This is the final article in the Exadata Basics to Pro series. If you have read Articles 1 through 9, you already understand the technology that underpins all three Exadata deployment options. This article focuses on the operational differences — not the technology, which is the same across all three.
The Three Exadata Deployment Options
Oracle now offers Exadata in three commercially distinct delivery models. The underlying technology — the same X10M or X11M hardware, the same Exadata System Software, the same Smart Scan — is identical across all three. What differs is who owns the hardware, where it runs, who manages what, and how you pay.
| Deployment |
Where It Runs |
Who Owns Hardware |
Payment Model |
| On-Premises Exadata |
Your data centre |
You — capital purchase |
Capex — buy hardware upfront, annual support |
| ExaCC — Exadata Cloud@Customer |
Your data centre |
Oracle — subscription lease |
Opex — monthly subscription per OCPU |
| ExaCS — Exadata Cloud Service |
Oracle's public cloud (OCI regions) |
Oracle — fully managed |
Opex — hourly or monthly per OCPU |
The most important distinction for a DBA is not where the hardware runs — it is who manages what. That operating model split determines your day-to-day responsibilities entirely.
ExaCC — Exadata Cloud@Customer
ExaCC is Oracle's Exadata delivered as a cloud service inside your own data centre. Oracle installs the Exadata rack in your facility, but you consume it as a subscription service. Oracle retains ownership of the hardware and manages it remotely — just as they would in their public cloud — while you run your Oracle databases behind your own firewall.
Why organisations choose ExaCC
- Data sovereignty — the data never leaves your data centre or country, which satisfies regulatory and compliance requirements that prohibit public cloud
- Low latency connectivity — application servers and the database are in the same data centre, no internet round-trip for every database call
- Same OCI cloud services — consumed through the same OCI control plane, same APIs, same tooling as public OCI
- Predictable performance — dedicated hardware, no shared-tenancy performance variability
- Oracle manages the infrastructure — hardware maintenance, cell patching, firmware, switch management all handled by Oracle
What Oracle manages for you on ExaCC
- Physical hardware — servers, storage cells, switches, power, cooling — all Oracle responsibility
- Exadata System Software — cellsrv updates, cell OS patching, EXABP applied on Oracle's schedule
- Database server infrastructure — DBBP applied by Oracle including OS, firmware, ILOM
- Network switch firmware — RoCE switch patching handled by Oracle
- Hardware replacement — predictive failure responses and disk replacement done by Oracle
- OCI control plane — the cloud management layer connecting your ExaCC to OCI services
What you manage as DBA on ExaCC
- Oracle Grid Infrastructure and Oracle Database patching — GI and DB CPU/RU patches are still your responsibility, applied via the OCI console or OPatch
- Database creation, configuration, and lifecycle — create, drop, resize databases via OCI console or API
- User management, tablespace management, backup orchestration
- Application access, performance tuning, query optimisation
- Data Guard configuration and management
- Recovery operations in response to database failures
The key DBA implication of ExaCC: You no longer run patchmgr for cell patches, respond to disk alerts, SSH into storage cells for cellcli commands, or manage hardware events. All of that moves to Oracle. Your DBA scope narrows to the database layer — which is the work that directly impacts your applications.
ExaCS — Exadata Cloud Service on Public OCI
ExaCS is fully managed Exadata deployed in Oracle's public cloud regions. You provision Exadata VM clusters through the OCI console, and Oracle manages all the infrastructure beneath your databases — you never see the physical hardware, the storage cells, or the network switches.
Why organisations choose ExaCS
- Zero hardware responsibility — Oracle manages everything below the database VM
- Elastic scaling — add or remove OCPUs and storage without hardware procurement
- Global availability — deploy in any of Oracle's OCI regions worldwide
- Pay as you use — scale down during off-peak periods to reduce costs
- Access to full OCI service ecosystem — Object Storage, Autonomous Database, Analytics Cloud, AI services
- Multicloud — Exadata X11M is available via Oracle Database@Azure, Oracle Database@Google Cloud, and Oracle Database@AWS
What Oracle manages for you on ExaCS
- Everything Oracle manages for ExaCC, plus:
- The physical data centre — power, cooling, physical security
- Database server OS patching — Oracle patches the underlying VM host OS
- Network infrastructure between your VM cluster and the internet
- Automatic backups to OCI Object Storage if you enable the managed backup service
What you manage as DBA on ExaCS
- GI and Oracle Database patching — GI and DB CPU patches are still your responsibility, applied via OCI console patch scheduling or manually via OPatch
- Database provisioning and configuration via OCI console or API
- VM cluster configuration — number of nodes, OCPU allocation, storage scaling
- User management, schemas, tablespaces, application access
- Performance tuning — the same SQL and AWR skills apply
- Backup strategy — choose between Oracle-managed backups or self-managed RMAN
ExaCS vs ExaCC vs On-Premises — DBA Responsibility Comparison
| Responsibility |
On-Premises |
ExaCC |
ExaCS |
| Physical hardware |
You |
Oracle |
Oracle |
| Storage cell patching (EXABP) |
You — patchmgr |
Oracle |
Oracle |
| DB node infrastructure (DBBP) |
You — patchmgr |
Oracle |
Oracle |
| Network switch patching |
You — patchmgr |
Oracle |
Oracle |
| Disk replacement / hardware alerts |
You — cellcli, SR raise |
Oracle |
Oracle |
| Grid Infrastructure patching |
You — OPatch |
You — OCI console or OPatch |
You — OCI console or OPatch |
| Oracle Database CPU/RU patching |
You — OPatch + datapatch |
You — OCI console or OPatch |
You — OCI console or OPatch |
| Database creation and lifecycle |
You |
You — OCI console or API |
You — OCI console or API |
| Performance tuning and SQL |
You |
You |
You |
| Backup and recovery |
You — RMAN |
You — RMAN or OCI managed |
You — RMAN or OCI managed |
| Data sovereignty |
Your data centre |
Your data centre |
OCI region — you choose |
| cellcli access for DBA |
Yes — full SSH access to cells |
Limited — Oracle manages cells |
No — not exposed to DBA |
The operating model split in plain language: On-premises Exadata is the most operationally demanding model — you patch the OS, the Exadata storage software, Grid Infrastructure, and the database. ExaCC removes the infrastructure operations burden but preserves your database control. ExaCS removes even more, leaving only database-layer work.
What Changes for the DBA on Cloud Exadata
1. Patching is split — infrastructure vs database
On-premises, you patch everything with patchmgr and OPatch in a specific sequence. On ExaCC and ExaCS, Oracle patches the infrastructure (EXABP, DBBP, switches) on their own schedule — you cannot defer Oracle's infrastructure patch windows beyond a fixed grace period. You remain responsible for GI and Oracle Database patches, which you apply via the OCI console's database patching workflow or manually via OPatch.
This split removes a significant operational burden — but it also removes your control over the infrastructure patch schedule. You cannot delay an Oracle-managed infrastructure patch if it conflicts with your change management calendar.
2. Cell administration moves to Oracle — cellcli is not your tool anymore
On-premises, cellcli and dcli are essential daily tools. On ExaCC, Oracle manages the storage cells — you do not SSH into cells, run cellcli commands, respond to disk alerts, or manage griddisks. On ExaCS, the cells are not even visible to you — they are abstracted behind the VM cluster layer.
The cell metrics and health information that you previously got from cellcli are surfaced through the OCI console and OCI Monitoring service instead. You read the same information, but through a web interface and cloud APIs rather than a command line on the cell.
3. Database provisioning via OCI console or API
Creating a new database on-premises involves srvctl, DBCA, and ASM configuration. On OCI, you provision databases through the OCI console, OCI CLI, or Terraform — Oracle's infrastructure-as-code tool. The underlying database is identical, but the provisioning workflow is cloud-native.
OCI CLI — common database operations on ExaCS or ExaCC
# List VM clusters in your compartment
oci db vm-cluster list \
--compartment-id <compartment_ocid>
# List databases in a VM cluster
oci db database list \
--compartment-id <compartment_ocid> \
--vm-cluster-id <vm_cluster_ocid>
# Create a new database in an existing VM cluster
oci db database create \
--vm-cluster-id <vm_cluster_ocid> \
--db-name MYDB \
--db-unique-name MYDB_UNIQUE \
--db-version 19.0.0.0 \
--admin-password <password> \
--db-workload OLTP
# Get patching status for a VM cluster
oci db vm-cluster get \
--vm-cluster-id <vm_cluster_ocid> \
--query 'data.{patchingStatus:"lifecycle-state"}'
4. Backup to OCI Object Storage — not just local RMAN
On OCI, the natural backup destination is OCI Object Storage — Oracle's durable, scalable cloud object store. You can configure Oracle-managed automated backups (Oracle schedules and manages RMAN backups to Object Storage) or self-managed RMAN backups using the RMAN SBT (System Backup to Tape) channel pointing to Object Storage. Your RMAN knowledge applies — the syntax and concepts are the same, only the backup destination changes.
RMAN backup to OCI Object Storage
-- RMAN backup to OCI Object Storage using SBT channel
-- The OCI RMAN library handles the Object Storage connection
RMAN> RUN {
ALLOCATE CHANNEL ch1 DEVICE TYPE SBT
PARMS='SBT_LIBRARY=/opt/oracle/oak/lib/libopc.so,
ENV=(OPC_PFILE=/home/oracle/opc.ora)';
BACKUP DATABASE PLUS ARCHIVELOG;
RELEASE CHANNEL ch1;
}
-- Alternatively use the OCI-integrated backup service
-- which handles scheduling automatically
5. Scaling is elastic — not a hardware procurement
On-premises, scaling means hardware procurement, rack space, power planning, and weeks of lead time. On ExaCS, you can add OCPUs to a VM cluster in minutes through the OCI console or API. Storage expansion is similarly online. On ExaCC, scaling within your provisioned rack is straightforward — adding capacity beyond the rack requires a hardware change request to Oracle.
What Stays the Same on Cloud Exadata
This is the section that matters most for positioning your skills. The database technology is identical across all three deployment options. Everything you know about Oracle Database on Exadata transfers directly.
| Skill or Task |
Transfers Directly? |
Notes |
| Smart Scan, Storage Indexes, HCC |
Yes — identical |
Same technology, same V$SYSSTAT statistics, same execution plan keywords |
| SQL tuning and AWR analysis |
Yes — identical |
AWR reports include the same Exadata-specific sections |
| RMAN backup and recovery |
Yes — same commands |
Destination changes to Object Storage but syntax is standard RMAN |
| Oracle RAC administration |
Yes — same srvctl and crsctl |
RAC runs on the VM cluster the same way as on-premises |
| Data Guard configuration |
Yes — same concepts |
OCI provides a Data Guard console wizard but manual configuration also works |
| Performance monitoring with V$ views |
Yes — identical |
Same V$CELL_STATE, V$SYSSTAT cell statistics, same Smart Scan metrics |
| OPatch and datapatch for DB software |
Yes — same commands |
GI and DB patching uses the same OPatch process as on-premises |
| ASM disk group management |
Yes — same commands |
ASM manages disk groups the same way — V$ASM_DISKGROUP, V$ASM_DISK |
| ADOP for EBS R12.2 (if applicable) |
Yes — identical |
EBS on ExaCS or ExaCC uses the same ADOP patching cycle |
| cellcli commands on ExaCC and ExaCS |
Partial / No |
ExaCC limits DBA cellcli access. ExaCS does not expose cells to DBA at all. |
| patchmgr for infrastructure |
No on ExaCC/ExaCS |
Infrastructure patching is Oracle-managed. Your patchmgr skill applies on-premises only. |
New Skills the Cloud Adds to Your Toolkit
Moving to OCI Exadata does not replace your existing skills — it adds new ones on top. The DBA who understands both the on-premises Exadata internals and the OCI operational model is genuinely hard to find and well compensated.
OCI Console and CLI
The OCI console is where you provision databases, manage VM clusters, schedule patches, configure backups, and monitor cloud-level infrastructure. Becoming fluent in the OCI console and the OCI CLI is the most immediately practical new skill for an on-premises DBA moving to OCI.
Terraform for Oracle databases
Oracle provides a Terraform provider for OCI. Many organisations manage their OCI Exadata infrastructure as code — VM clusters, databases, Data Guard associations, and network configuration are all defined in Terraform files and applied through CI/CD pipelines. Basic Terraform literacy is increasingly expected for cloud DBA roles.
OCI Monitoring and Notifications
The cell alerts and cellcli health checks you ran on-premises are replaced by OCI Monitoring alarms and Notifications. You define metric-based alarms in the OCI console — for example, alert when database CPU exceeds 90% for more than 10 minutes — and route notifications to email, PagerDuty, or Slack. The same information is available, accessed through a different paradigm.
OCI Object Storage for backups and data movement
Object Storage is the natural landing zone for backups, data exports, and data imports on OCI. Understanding how RMAN integrates with Object Storage, how Data Pump uses pre-authenticated requests (PARs), and how to manage Object Storage buckets are practical skills that come up in every OCI database engagement.
OCI CLI — common monitoring tasks for cloud DBAs
# Check Exadata infrastructure maintenance history
oci db maintenance-run list \
--compartment-id <compartment_ocid> \
--target-resource-id <vm_cluster_ocid>
# List available database patches for a specific DB version
oci db patch list --all \
--compartment-id <compartment_ocid> \
--db-version 19.0.0.0 \
--db-home-id <db_home_ocid>
# Check backup status for a database
oci db backup list \
--compartment-id <compartment_ocid> \
--database-id <database_ocid>
# Create an alarm for cell Smart Scan efficiency
# (Done via OCI console Monitoring service or API)
# Metric: oracle_oci_database_exadata_smart_scan_efficiency_percent
# Alarm condition: value < 70
# Notification: email to DBA team
How to Think About Which Option Is Right for Your Organisation
| If Your Requirement Is |
Consider |
| Data must stay in your own data centre — regulatory requirement |
ExaCC or On-Premises Exadata |
| Want cloud economics but data sovereignty |
ExaCC — subscription in your data centre |
| Maximum operational simplicity — let Oracle manage infrastructure |
ExaCS on public OCI |
| Need to scale quickly without hardware lead time |
ExaCS — elastic OCPU and storage scaling |
| Application servers must be co-located with database |
ExaCC or On-Premises Exadata |
| Already have Oracle Database licences |
Any option — evaluate BYOL pricing for ExaCC and ExaCS carefully |
| Want access to Autonomous Database on the same platform |
ExaCS — Autonomous Database runs on ExaCS infrastructure |
| Multicloud requirement — run Oracle databases closer to AWS or Azure workloads |
Oracle Database@Azure, Oracle Database@Google Cloud, or Oracle Database@AWS — all use Exadata X11M |
What This Means for Your Career as an Exadata DBA
The shift to cloud Exadata does not make on-premises Exadata skills obsolete — it makes them more valuable when combined with cloud skills. Here is the reality of the market in 2026.
- On-premises Exadata is not going away. Most large enterprises with Exadata investments will run on-premises systems for years. Organisations with regulatory constraints will run ExaCC in their own data centres indefinitely. The on-premises DBA who understands cellcli, patchmgr, and the storage object model is still in demand.
- Cloud Exadata expertise is additive, not replacement. The DBA who understands both patchmgr rolling upgrades and OCI Terraform provisioning is rare. That combination commands a premium over a DBA who only knows one side.
- Database skills transfer completely. Everything you know about SQL tuning, AWR, Smart Scan, HCC, RAC, Data Guard, RMAN, and ADOP applies directly to cloud Exadata. None of it becomes obsolete. The cloud adds an operational layer on top — it does not replace the database layer underneath.
- The next step is OCI fundamentals. If you want to position yourself for cloud Exadata roles, learn the OCI console, OCI CLI, and basic Terraform. These are the gaps between your current skill set and a cloud DBA role. The Oracle Cloud Database Services certification (1Z0-1093) is a practical starting point.
Practical advice: Set up a free Oracle Cloud account at cloud.oracle.com — Oracle provides Always Free tier resources. Provision an Autonomous Database or a small VM cluster in the Always Free tier and explore the OCI console, OCI CLI, and monitoring. You will immediately recognise the concepts from your on-premises experience — Smart Scan metrics, AWR reports, RMAN backups — through a new interface.
Summary — Three Deployment Options, One Technology
- On-premises Exadata — you own and operate everything. Maximum control, maximum operational responsibility. patchmgr, cellcli, and dcli are daily tools.
- ExaCC (Cloud@Customer) — Oracle manages the infrastructure in your data centre. You manage databases. Data stays on-premises. Oracle handles EXABP, DBBP, hardware alerts, and disk replacement.
- ExaCS (Cloud Service) — fully managed in Oracle's public cloud. You manage databases via OCI console and CLI. Oracle manages everything below the database VM. Elastic scaling, multicloud availability.
- All three use the same Exadata hardware and software — Smart Scan, Storage Indexes, HCC, cellsrv, ASM, RAC. The technology does not change between deployment options.
- On cloud Exadata, your database skills transfer completely. SQL tuning, AWR, RMAN, RAC, Data Guard, OPatch, ADOP — all identical. Infrastructure skills (patchmgr, cellcli) are replaced by OCI operational tools.
- The new skills to add are OCI console, OCI CLI, Terraform, OCI Monitoring, and Object Storage for backups. None of these replace what you know — they extend it.
