01 · Introduction
Provisioning a production-ready Oracle database on-premises via a public cloud console feels like a contradiction. If the physical racks sit in your own server room, how does Oracle manage them without crossing your data privacy boundaries?
The answer is Oracle Exadata Cloud@Customer architecture — a deliberate split between the Control Plane and the Customer Plane. Oracle automates infrastructure lifecycle management through OCI while you retain full ownership of databases, applications, and business data inside the Customer Plane.
ExaCC delivers the same engineered-system capabilities as on-premises Exadata, wrapped in the OCI operational model.
Dom0 (Control Plane) and DomU (Customer Plane) isolation prevents Oracle from accessing your application data.
Database traffic stays on your local Client Network — it never traverses the internet or OCI public framework.
02 · What Is Oracle Exadata Cloud@Customer Architecture?
Understanding this operational split requires analyzing the hardware layout and cloud management planes as two distinct, isolated environments.
Two Operational Worlds
- Physical Infrastructure (Your Datacenter): Oracle delivers, installs, and maintains Exadata racks — compute nodes, Exadata storage servers, and the ultra-low-latency RoCE internal fabric.
- Cloud Management Layer (OCI Region): Provisioning engine, lifecycle workflows, billing meters, and the control dashboard reside in the Oracle Cloud public region.
Figure 1 · ExaCC Control Plane (Dom0) and Customer Plane (DomU) separation
The physical machine runs a secure virtualization layer that creates an impenetrable boundary between Oracle's management components and the environments where your databases execute.
03 · What Is the Control Plane?
When you use the OCI Console, CLI, or REST APIs against your Exadata system, you interact with the Control Plane. The Control Plane's Dom0 (Hypervisor Layer) runs automation agents that communicate outward to the OCI region via an encrypted management connection.
Control Plane Responsibilities
- Initial infrastructure provisioning and capacity activations
- Hypervisor-level patching and firmware updates for compute and storage nodes
- Hardware telemetry, health monitoring, and proactive fault detection
- Automating backup schedules and executing scaling requests
The Security Boundary: What Oracle Can and Cannot Access
| Oracle CAN (Control Plane / Dom0) | Oracle CANNOT (Customer Plane / DomU) |
|---|---|
| Manage hypervisor and hardware firmware | View or query your tablespaces and records |
| Receive hardware telemetry and health alerts | Access database encryption keys |
| Push provisioning and scaling instructions | Root OS access inside Guest VMs |
| Schedule validated patch bundles for Guest VMs | Process or store application data |
Automation agents in Dom0 (Control Plane) have no visibility into DomU (Guest Virtual Machines) where your Oracle Databases run. Oracle cloud operators cannot see your data — the architectural boundary is enforced at the hypervisor layer.
04 · What Is the Customer Plane?
Inside the Customer Plane you will find:
- VM Clusters: Virtualized processing environments on database compute nodes
- Oracle Database Instances: Grid Infrastructure, ASM, Container Databases, and Pluggable Databases
- Customer Networking: Client and Backup networks tied to your corporate topology
Figure 2 · Application traffic stays on the local Client Network inside the Customer Plane
The Customer Plane is isolated from Oracle's management layer. You administer databases with SQL*Plus, Enterprise Manager, or OCI cloud tooling. Application servers connect via the Client Network interface — operational database traffic never leaves your corporate network borders.
05 · How Do the Control Plane and Customer Plane Work Together?
The technical execution hinges on secure, automated API pathways that pass cloud commands down to the physical asset safely. Consider a classic scenario: creating a Database Home and provisioning a Pluggable Database (PDB).
Figure 3 · Cross-plane coordination from OCI Console click to local database availability
- The IntentAn architect selects Exadata Infrastructure, VM Cluster, and database parameters in the OCI Console or Terraform.
- The HandshakeOCI validates identity policies, resource availability, and licensing boundaries.
- Command DeliveryThe Control Plane pushes an encrypted metadata package to local Dom0 agents via the secure management connection.
- Local OrchestrationThe Dom0 agent brokers the command payload across an internal virtual bridge into the DomU guest OS.
- ExecutionCloud tooling inside the Guest VM triggers Grid Infrastructure, creates ASM volumes, runs DBCA, and mounts database files.
- The Echo BackCompletion is verified in the Customer Plane; status updates from Provisioning to Available in OCI.
The instruction originated in the public cloud, but the work executed locally — keeping data pathing private.
06 · Which OCI Services Integrate with ExaCC?
Even though your processing engine lives on-premises, ExaCC gains access to OCI cloud-native tooling — avoiding the overhead of building separate logging, monitoring, and backup infrastructure locally.
| OCI Service | ExaCC Integration |
|---|---|
| IAM | Fine-grained policies dictating who can see, scale, or modify Exadata resources |
| Monitoring & Notifications | Hypervisor metrics, performance telemetry, alerts via SMS, email, or Slack |
| Logging | Management audit trails for security officers tracking API actions |
| Object Storage | Backup target via dedicated Backup Network — bypasses production Client Network |
07 · How Are Resources Managed Inside ExaCC?
ExaCC removes classic hardware bottlenecks by managing resources hierarchically instead of treating an Exadata rack as a static monolith.
The Structural Hierarchy
| Layer | Description |
|---|---|
| Exadata Infrastructure | Base physical asset — components, licensing, overall capacity |
| VM Cluster | Logical cluster slice with OCPU and memory limits (prod vs non-prod) |
| Database Home | Software installation directory — supports multiple version baselines side-by-side |
| Oracle Database | Operational layer — CDBs and PDBs sharing or isolating resources as configured |
Elastic Resource Scaling
ExaCC provides elastic online scaling. Scale OCPUs up or down inside a VM Cluster via the OCI console without database downtime. The Control Plane handles hypervisor layout updates, mapping physical CPU threads to your virtual machine dynamically.
08 · What Happens When You Deploy a New Database?
Trace an administrative request from initial click to application connection:
Step 1 — Submit the Blueprint
Select Exadata infrastructure, VM Cluster, database version, name, and admin credentials in the OCI Console.
Step 2 — API Validates the Payload
OCI IAM verifies permissions. The service checks OCPU allocation limits against physical capacity.
Step 3 — Dispatch via Secure Control Channel
The Control Plane translates parameters into a configuration instruction packet pushed to the Dom0 management master node.
Step 4 — Storage Allocation
The Dom0 agent instructs Exadata Storage Servers via the RoCE network to provision ASM disk spaces — DATA and RECO disk groups per Exadata best practices.
Step 5 — Database Creation
Automation inside DomU executes directory creation, template deployment, DBCA silent routines, redo log creation, and background process startup.
Step 6 — Registration & Readiness
Services register with Grid Infrastructure listeners. Status updates to Active in OCI. Applications connect via SCAN on the local Client Network.
09 · Common Misconceptions About ExaCC Architecture
- "Oracle support teams can see my customer data."The Dom0/DomU boundary prevents this. Oracle maintains hardware and hypervisors outside your runtime systems — no root access or database permissions inside Guest VMs.
- "ExaCC is simply hosted Exadata."Hosted Exadata implies renting static colocation hardware. ExaCC is a true OCI extension — full API programmability, elastic utility licensing, and automated lifecycle while the rack sits in your building.
- "If our internet link to OCI goes down, production databases stop."No. You lose cloud management actions (create DB, scale OCPUs via console). Running databases continue locally without interruption. Applications on local switches experience zero downtime.
- "We must move all application servers to OCI."ExaCC is designed for single-digit microsecond database latency to existing on-premises application landscapes. Your app tier stays where it is.
10 · Production Best Practices
To extract maximum value from ExaCC, architectural deployment designs should adhere to these production standards:
Network Segmentation
Isolate Client, Backup, and Management subnets at the physical switch layer. Never route production database traffic through the management tunnel.
IAM Before Provisioning
Map corporate IdP groups to OCI compartments and policies before the first VM Cluster is created — retrofitting IAM is painful.
Backup Network Sizing
Size the Backup Network for your RPO/RTO targets. Object Storage backups should not compete with Client Network bandwidth.
Operational Runbooks
Document what Oracle automates (hypervisor, hardware) versus what your team owns (schemas, indexes, PDB lifecycle).
11 · The Architecture Checklist
Before signing off on an ExaCC deployment design, verify your engineering teams can answer "Yes" to these readiness checkpoints:
- Control Plane Architecture: Has security approved outbound HTTPS port requirements for OCI control plane connectivity?
- Customer Plane Ownership: Are DBAs trained on managing Guest VMs using OCI cloud tooling utilities?
- IAM Policy Framework: Have you mapped corporate Active Directory/IdP groups to OCI IAM compartments and policies?
- Network Separation: Are Client, Backup, and Management network subnets isolated at the physical switch layer?
- Resource Planning Matrix: Is there a documented baseline for OCPU, memory, and storage ratios per initial VM Cluster?
- Backup Infrastructure: Is the backup network sized to meet enterprise RPO/RTO objectives?
- Operational Runbooks: Are responsibilities clearly delineated between Oracle automation and your staff ownership?
12 · Frequently Asked Questions
Who is responsible for patching the Guest VM operating system?
You own the Guest VM (DomU) layer. Oracle provides pre-tested, validated patch bundles through the OCI Control Plane. You schedule and trigger deployment at your convenience.
Can I install third-party agents or software inside Guest VMs?
Yes. You have root administrative access inside the Guest VM Cluster and can install monitoring agents, security software, or backup utilities, provided they do not conflict with Oracle Grid Infrastructure.
How does Exadata Cloud@Customer calculate billing?
ExaCC uses split billing. A predictable baseline monthly fee covers the physical infrastructure asset. Database software consumption is billed elastically by OCPU allocation hourly (Pay-As-You-Go or BYOL).
What happens if a physical disk or flash card fails?
Oracle handles replacement automatically. The infrastructure transmits a hardware telemetry alert through the Control Plane. Oracle dispatches a field engineer with replacement parts to your datacenter without requiring a manual ticket.
Can I use Oracle RAC on ExaCC?
Yes. ExaCC is designed around Oracle RAC. Deployments span multiple compute nodes in your VM cluster for high availability and horizontal performance scaling.
Where do my database encryption keys reside?
You control keys locally or via OCI Vault. Use Oracle Wallet inside the Customer Plane, or integrate with OCI Vault via secure cloud API calls for Master Encryption Keys.
Does ExaCC support Autonomous Database?
Yes. Oracle offers ExaCC with the option to deploy traditional Exadata Database Services and Oracle Autonomous Database on the same physical infrastructure simultaneously.
How does ExaCC ensure high storage availability?
ASM High Redundancy by default. Data is written with 3-way mirroring across distinct physical storage cells, ensuring loss of multiple storage units does not cause data loss or downtime.
13 · Architectural Summary
| Architectural Principle | ExaCC Implementation |
|---|---|
| Plane Separation | Control Plane (Dom0) manages infrastructure; Customer Plane (DomU) runs databases and applications |
| Data Sovereignty | Application data remains in the Customer Plane inside your datacenter — never processed by Oracle management agents |
| Cloud Automation | OCI Console, CLI, Terraform, IAM, Monitoring, Logging, and Object Storage integrate via secure management connection |
| Local Execution | Provisioning commands execute locally in DomU; only metadata traverses the OCI tunnel |
| Resource Hierarchy | Infrastructure → VM Cluster → Database Home → Oracle Database (CDB/PDB) |
| Elastic Scaling | Online OCPU scaling via OCI console without database downtime |
| Network Isolation | Client, Backup, and Management networks separated at switch layer |
| Resilience Model | Production databases continue during OCI connectivity loss; management actions require periodic connectivity |
Table 1 · ExaCC architectural principles at a glance
14 · Conclusion
Oracle Exadata Cloud@Customer is not simply Oracle hardware inside your datacenter. It is a carefully designed architecture where cloud automation and customer control coexist — Oracle manages the infrastructure while your business continues to own and protect its most valuable asset: its data.
The architectural separation between management traffic and application data is one of ExaCC's most important security features — and the reason regulated enterprises adopt it.
At ExaGuru, our Exadata Expert course covers ExaCC architecture, Control Plane vs Customer Plane operations, migration patterns, and production deployment — because understanding this split is the foundation for every ExaCC design decision.