Home / OCI

OCIHow-toAdvanced

Optimization: Exadata Database Service - online CPU scaling, consolidation and resource management

Exadata Database Service bills enabled CPU by the hour, so leaving every VM cluster at peak capacity wastes money. Measure CPU per VM cluster and database, scale enabled CPUs online on a schedule, consolidate databases with Resource Manager and instance caging to share capacity safely, and review storage and licensing.

Deepak Bhardwaj3 min read

Applies toExadata Database Service on Dedicated Infrastructure and on Exascale Infrastructure (OCI), Exadata Database Service on Cloud@Customer; Oracle Database Resource Manager, instance caging

How the cost works (simplified)

infrastructure = Exadata infrastructure (or Exascale storage/VM) charges
compute        = enabled ECPUs/OCPUs per hour on VM clusters
licence        = License Included or BYOL rate on those CPUs

You can't shrink the infrastructure quickly, but enabled CPU on VM clusters can be scaled up and down online. That's the main lever.

1. Measure CPU per VM cluster and database

  • VM cluster metrics (CPU utilisation per node) in OCI Monitoring / Database Management.
  • Per database: AWR CPU Usage Per Sec, average active sessions, top consumers.
  • Map peaks: daily batch, month-end, quarter-end.

2. Scale enabled CPU online

oci db cloud-vm-cluster update --cloud-vm-cluster-id $VMC --cpu-core-count 16

(Use the command and parameter for your service flavour, such as Cloud@Customer VM clusters or ECPU-based models. Check the CLI reference.)

A common pattern: scheduled scale-up before month-end processing and scale-down afterwards, using Resource Scheduler or a Function triggered by a schedule, with checks that the operation succeeded. Scaling has minimums per node and granularity rules.

3. Consolidate safely

Exadata is designed for consolidation. Several databases share a VM cluster, with guardrails:

Control Purpose
Instance caging (cpu_count per instance + Resource Manager plan) Limit how much CPU each database can use
CDB resource plans Shares and limits between PDBs
IORM (I/O Resource Management) Prioritise I/O for critical databases on shared storage
Separate VM clusters Strong isolation for different security zones or lifecycles 
ALTER SYSTEM SET cpu_count = 8 SCOPE=BOTH SID='*';
ALTER SYSTEM SET resource_manager_plan = 'DEFAULT_PLAN' SCOPE=BOTH SID='*';

The sum of cpu_count across instances on a node can exceed physical CPUs (over-subscription) for non-critical databases. Keep critical ones within limits.

4. Use PDBs to reduce instance overhead

Many small non-CDB databases each carry their own SGA, background processes and management overhead. Consolidating them as PDBs in fewer CDBs frees memory and CPU, and simplifies patching.

5. Storage

  • ASM disk group usage (DATA/RECO) and sparse disk groups for test clones.
  • Snapshot/sparse clones for dev/test instead of full copies.
  • Backup retention and archive log management. RECO usage often grows unnoticed.

6. Licensing

With BYOL, enabled CPUs map to licence requirements. Scaling down outside peaks can reduce licence exposure as well as cost, but confirm how your agreement counts cloud CPUs before relying on it.

7. Review regularly

Quarterly: CPU utilisation per VM cluster vs enabled CPUs, databases that could move to a cheaper service (e.g. small ones to Autonomous Database), and dev/test VM clusters that could be scaled to minimum outside working hours.

Warning

Scaling down a VM cluster before stopping a heavy job can starve every database on it. Check running workloads and Resource Manager limits before scaling down, and automate checks into the schedule.

Checklist

  • CPU usage per VM cluster and database mapped to business cycles
  • Scheduled online CPU scaling for peaks
  • Instance caging, CDB plans and IORM configured
  • Small databases consolidated as PDBs
  • Sparse clones and storage retention reviewed
  • Licence counting confirmed

Related fixes