Deploying Your First Database on Oracle Exadata Cloud@Customer: What Really Happens?

You log into the Oracle Cloud Console, choose Create Database, select a few options, click Deploy, and wait. Twenty minutes later, a production-ready Oracle Database is running inside your own data center. It feels almost too simple.

Behind that single click, Oracle Exadata Cloud@Customer performs dozens of automated tasks — allocating infrastructure, validating resources, configuring Grid Infrastructure, preparing storage, creating Database Homes, provisioning the database, registering monitoring services, and integrating everything into Oracle Cloud Infrastructure (OCI).

Most administrators never see these steps because Oracle automates them. Understanding them, however, makes troubleshooting, capacity planning, and architecture design much easier. For the physical and control-plane foundations, see our deep dive on ExaCC Architecture.

A common misconception among cloud newcomers is that database provisioning is an isolated event. On ExaCC, the Create Database button is the final milestone of a highly coordinated infrastructure lifecycle.

Infrastructure layers that must be operational first

• Exadata Physical Infrastructure Foundations: The bare-metal footprint — Quarter, Half, or Full Rack — must be physically rolled into your on-premises data center, anchored, cabled to your data center switches, and energized. Oracle field engineers must have initialized the underlying compute nodes and Exadata Storage Servers (cells).
• OCI Control Plane Integration via Gen 2 Gateway: A persistent, encrypted out-of-band connection must be active between your local deployment and the OCI region, driven by an Oracle-managed Gen 2 Exadata Cloud Gateway. Without this control plane bridge, the OCI API cannot pass orchestration instructions to your local hardware.
• Network Partitioning & VLAN Isolation: Your network team must provision deterministic networks — client traffic on dedicated VLANs, backup traffic on separate interfaces to protect RMAN throughput, and the ultra-low latency RoCE (RDMA over Converged Ethernet) or InfiniBand private fabrics completely unobstructed.
• Active VM Cluster & Resource Carving: You do not install databases directly onto bare metal. An active VM Cluster must be built via the KVM hypervisor layer, locking down OCPU, memory, and local storage boundaries across the physical compute infrastructure.
• Stabilized ASM Disk Groups: Storage cells must be grouped into cloud-managed ASM pools — predominantly +DATA and +RECO — cleanly sliced and presented to your target VM Cluster.

ExaCC is an engineered system delivered as a cloud service. The underlying hardware and hypervisor layers must be completely stabilized so the OCI control plane can predictably issue API calls to configure operating system profiles, cluster software, and storage allocations.

A VM Cluster is the secure, virtualized operating environment where your databases actually live. Oracle uses an optimized KVM hypervisor on ExaCC to partition physical compute nodes into distinct virtual machine groups. For sizing and design patterns, see our guide to Designing Enterprise VM Clusters.

Figure 1 · ExaCC VM Cluster virtualization — physical compute partitioned via KVM hypervisor

Resource partitioning and isolation

When you build a VM Cluster, you specify exactly how many OCPUs and how much RAM to allocate per node. If your physical nodes have 126 OCPUs each, you might allocate 32 OCPUs to a Production VM Cluster and 16 OCPUs to a Non-Production VM Cluster on the same physical frame. This guarantees hard resource isolation — a rogue batch job in development cannot starve production CPU or memory.

Real Application Clusters (RAC) framework

Every ExaCC VM Cluster is inherently clustered across all physical compute nodes. If your ExaCC infrastructure has two compute nodes, your VM Cluster consists of two identical virtual machines — one on each node. This lays the baseline for Oracle RAC, ensuring that if one physical server drops offline for maintenance, the surviving VM instance continues running without dropping the database service.

To visualize how virtual and physical components interact with cloud management layers, follow the structural relationship from OCI Console down to your applications.

Figure 2 · ExaCC infrastructure hierarchy — from OCI Console to application connectivity

Oracle Grid Infrastructure (GI) bundles Oracle Clusterware and Oracle Automatic Storage Management (ASM) into a single software stack. Without GI, an Exadata system is a collection of disconnected VMs and independent storage arrays. GI transforms these into a unified, highly available cloud system. For operational guidance, see Grid Infrastructure Best Practices.

Figure 2b · Grid Infrastructure — Clusterware and ASM foundation before database creation

Core roles

Oracle Clusterware manages node membership, monitors system health, and coordinates cluster communications across the private RoCE/InfiniBand interconnect. If a database instance hangs, Clusterware detects the failure and handles fencing and failover.

Automatic Storage Management (ASM) acts as a built-in, clustered file system and volume manager optimized for Oracle database files. It takes raw disk volumes from Exadata Storage Servers and groups them into logical disk pools (+DATA and +RECO) with automatic striping — bypassing manual disk layout planning entirely.

You cannot install an Oracle Database on ExaCC without a healthy Grid Infrastructure layer. When a database is provisioned, its datafiles go directly into ASM disk groups and register instantly with GI-managed local and SCAN listeners — before DBCA ever runs.

A Database Home (ORACLE_HOME) is a specific directory within your VM Cluster file system containing compiled Oracle Database software binaries, utility scripts, and network configuration templates. The DB Home is the application package; the database itself is the user data created by that package.

Multiple Database Homes and version management

An ExaCC VM Cluster supports multiple DB Homes for different versions or patch levels simultaneously:

Software sharing and isolation

Group databases into logical DB Homes according to application tier and patching schedule. When one DB Home requires a Critical Patch Update, every database sharing that ORACLE_HOME must be taken offline simultaneously during the patching window — which is why monolithic DB Home design creates severe lifecycle bottlenecks.

When you verify configuration parameters in the OCI Console and hit Create Database, you trigger an advanced automated orchestration workflow. Here is exactly what happens step-by-step behind the scenes.

Figure 3 · ExaCC database provisioning orchestration — from OCI Console to Available status

1. API Ingestion and Control Plane Payload HandoffWhen you commit database parameters in the OCI Console, the interface translates your selections — SID, db_name, global character sets, and PDB configurations — into an authenticated API payload. The OCI Control Plane checks this against IAM policies, authorizes it, and streams the execution payload through the Exadata Cloud Gateway to your on-premises virtual environment.
2. Pre-Flight Hard Resource VerificationLocalized cloud automation agents ingest the payload and run pre-flight validation inside the target VM Cluster. The automation verifies unallocated RAM and OCPU capacity, polls ASM instances to confirm +DATA and +RECO possess the raw byte capacity requested, and validates that cluster status across all RAC nodes is perfectly synchronized and healthy.
3. Database Home Registration and Inventory PlacementIf using an existing DB Home, the automation confirms directory health, inventory links, and patch parity. If deploying a new DB Home, the agent pulls a verified Oracle Golden Image from an internal OCI repository, extracts binaries into a new directory path on your VM Cluster nodes, registers the path with the central global inventory, and applies localized security descriptors.
4. Automatic Storage Allocation & Disk MirroringThe automation interfaces with local ASM instances across all cluster nodes. It carves out initial tablespace containers within +DATA for SYSTEM, SYSAUX, UNDOTBS, and TEMP, and sets up tracking boundaries within +RECO for online redo logs, multiplexed control files, and future archive log streams. This completely bypasses old-school manual disk striping layout planning. See Advanced ASM Disk Group Management.
5. Silent DBCA Interconnect ExecutionThe cloud framework invokes DBCA in silent mode inside the newly prepared ORACLE_HOME. DBCA writes the spfile and initialization profiles, constructs SGA and PGA boundaries inside the virtual memory stack, and runs bootstrap data dictionary scripts. Because ExaCC provisions enterprise-tier RAC natively, DBCA creates independent instances, threads, and thread-specific redo architectures across every node. See Configuring Oracle RAC on Cloud@Customer.
6. Listener Binding and OCI Monitoring SynchronizationWith database structures online, the orchestration engine binds services to local node listeners and virtual SCAN listeners, enabling secure application routing via SQL*Net. Simultaneously, the OCI Management Agent establishes tracking links with the OCI Control Plane — binding physical database metrics to the OCI console for cloud backup tracking, scheduling, and live performance charts.

Exadata Cloud@Customer achieves high performance by dynamically sharing physical hardware resources among virtualized workloads. Understanding this allocation prevents performance bottlenecks.

OCPU and memory provisioning

When you deploy a database, you assign an explicit number of OCPUs. The underlying automation adjusts the database cpu_count parameter accordingly. The hypervisor ensures compute processing power is instantly available to the database instance. Memory allocation configures sga_target and pga_aggregate_target based on your inputs so the database operates safely within its VM memory boundary without causing OS-level swapping.

Dynamic resource scaling

One of ExaCC's best features is elastic scaling. If a database experiences an unexpected end-of-month processing surge, scale OCPUs upward via the OCI Console or API without rebooting the VM or interrupting application connections. The database instantly recognizes the new cpu_count allocation and scales internal processing threads to match.

ASM storage strategy and flash acceleration

Figure 4 · ExaCC storage layer — Smart Flash Cache, NVMe cells, and ASM disk group allocation

When data is written to an ASM disk group on ExaCC, it distributes automatically across all Exadata Storage Servers to maximize parallel throughput. Exadata caches hot data blocks into PCIe NVMe Smart Flash Cache and Exadata System Memory (RAM). The provisioning engine configures these caching rules automatically, ensuring newly created tablespaces instantly benefit from Smart Scans and columnar caching.

The console status bar turns green and reads Available. Your database is technically up and running — but before you hand the keys to application teams, several post-deployment processes complete behind the scenes, and a few critical verifications must be handled by the DBA.

Cloud integration processes

• Automatic backup initialization: If you enabled managed cloud backups, the OCI agent schedules immediate baseline backups and establishes secure connections to your Object Storage bucket or local Zero Data Loss Recovery Appliance (ZDLRA).
• Unified monitoring and diagnostics: Cloud management frameworks stream health metrics to OCI. Locally, ExaWatcher and background AWR snapshots capture CPU, memory, wait events, and storage latency baselines.

Post-deployment verification checklist for DBAs

• SCAN resolution: Confirm client environments resolve all three virtual IP addresses associated with the cluster SCAN listener.
• TNS connection strings: Test connectivity using service-based TNS descriptors — not explicit node IP addresses — to ensure RAC failover works correctly.
• Wallet and encryption health: Confirm TDE master keys are initialized, rotated, and accessible via assigned Oracle Wallets.

The complete operational journey moves through these sequential development phases:

Figure 5 · ExaCC database lifecycle — sequential phases from planning to production operations

Deploying enterprise systems via a cloud interface can make administrators overlook critical engineering details. These are the most common pitfalls encountered during first-time ExaCC deployments:

1. Creating VM Clusters without long-term capacity planningOver-allocating OCPUs or RAM to initial non-production VM clusters leaves later production clusters starved for hardware space, forcing complex down-sizing operations.
2. Monolithic Database Home complicationsPlacing disparate business applications inside a single massive Database Home creates severe lifecycle bottlenecks. When one application requires an urgent Interim Patch or CPU, every database sharing that ORACLE_HOME must be taken offline simultaneously.
3. Ignoring Grid Infrastructure patch and version compatibilityDeploying brand-new database versions on old, unpatched Grid Infrastructure layers can cause unexpected cluster evictions or performance anomalies. Always ensure GI version is equal to or higher than your target database version.
4. Incorrect CPU allocation and uncontrolled oversubscriptionAssigning too many initial OCPUs to a small database wastes cloud licensing budget. Start lean and use ExaCC elastic scaling when production metrics demand it.
5. Asymmetric storage allocation and +RECO starvationAllocating nearly all available storage to +DATA while starving +RECO. A high-throughput transaction database will rapidly saturate a restricted +RECO group with archive logs, throwing the database into a hard-hang state the moment log destinations become unwriteable.
6. Missing or misconfigured backup pathsDisabling managed cloud backups to save configuration time leaves a database vulnerable. Failure to verify network throughput to your backup destination early can cause your first full RMAN backup to saturate application network interfaces.
7. Weak IAM permissions and over-privileged rolesGranting blanket cloud administrator rights to every junior DBA bypasses the security isolation of the cloud. Use precise OCI IAM policies to restrict who can terminate VM Clusters or alter infrastructure assets.
8. Skipping monitoring integration verificationAssuming OCI console charts are everything you need can leave you blind to deep database health issues. Always verify local diagnostic tools, alert logs, and OS tracing agents are functioning.
9. Asymmetric network routing and unresolved firewall rulesInitiating the database creation wizard before confirming client, backup, and SCAN networks are clear of internal firewalls. If the deployment engine cannot register endpoints against all three virtual SCAN IP addresses, the provisioning pipeline fails mid-flight, forcing a complex cloud rollback.
10. No real-world production readiness testingMoving client workloads onto a newly provisioned database without stress tests or RAC node failover validation leaves your team unprepared for routine infrastructure maintenance.

Before you click Create Database on your next deployment, confirm you can answer Yes to every question:

• Is the underlying Exadata Infrastructure completely healthy and online in OCI?
• Has the target VM Cluster been correctly sized with adequate unallocated OCPUs and RAM?
• Are the Grid Infrastructure services completely synchronized across all active nodes?
• Have you checked that the ASM +DATA and +RECO disk groups have enough free space?
• Are you deploying into a clean, appropriately patched Oracle Database Home?
• Have you verified that your OCI IAM user account has the precise policy permissions?
• Are the client, backup, and interconnect networks fully routed and clear of firewall blocks?
• Have you defined a clear automated backup schedule and destination bucket?
• Is your OCI monitoring agent verified as active and communicating with the control plane?

1. VM Clusters are mandatoryEvery Oracle Database on Exadata Cloud@Customer runs inside a virtualized VM Cluster — never directly on bare-metal hardware.
2. Grid Infrastructure firstOracle Grid Infrastructure (Clusterware and ASM) must be completely healthy and operational before any database can be provisioned.
3. DB Homes form the foundationA Database Home contains the compiled software binaries. You can run multiple DB Homes to manage different versions and patch levels.
4. The Cloud Control Plane drives automationThe OCI Control Plane automates the entire deployment process, converting console inputs into a multi-step infrastructure setup.
5. ASM manages storage performanceASM automatically handles disk striping and redundancy across all Exadata storage servers, eliminating manual file placement.
6. Resources scale dynamicallyCPU and memory allocations are highly elastic and can be scaled dynamically to handle changing application workloads.
7. Cloud integration is automaticThe provisioning process automatically sets up OCI monitoring agents, performance logging tools, and scheduled backup schedules.
8. Success requires upfront planningA successful production deployment depends on proper design of your network, storage splits, and DB Home layouts — not just clicking a button.

Deploying an Oracle Database on Exadata Cloud@Customer may take only a few clicks, but behind those clicks is one of Oracle's most sophisticated automation workflows — combining engineered infrastructure, cloud orchestration, and enterprise-grade database architecture into a repeatable deployment process.

Understanding what happens between Create Database and Available status is what separates DBAs who troubleshoot in minutes from those who troubleshoot in days.

At ExaGuru, our Exadata Expert course covers ExaCC VM Cluster design, Grid Infrastructure operations, ASM disk group management, and production database provisioning — because knowing the automation workflow is the foundation for every ExaCC deployment decision.