Skip to content
Cloud Efficiency Hub

Overprovisioned CPU on OCI Base Database Systems

The short version

OCI Base Database Service virtual machine DB systems are billed for every enabled OCPU or ECPU on each node, whether the database uses them or not.

PointFive Research

Cloud cost research at PointFive

Category
Databases
Reference
CER-0554
Type
Overprovisioned Resource

Explanation

Why the waste happens and who it affects.

DB systems sized for an expected peak, a migration or a vendor sizing guide and then left at that size run for months at low CPU utilization. On the ECPU metric, each ECPU is billed for compute infrastructure plus a license-included edition rate (Standard, Enterprise or High Performance) or a BYOL rate, so each surplus core also carries database software cost, which makes oversizing more expensive than on a plain compute instance.

Oracle's Cloud Advisor has a dedicated cost recommendation, Downsize Underutilized Base Database System, for this case, and the Change Shape documentation lists reducing OCPUs to reduce cost as a reason to reshape. Multi-node RAC systems multiply the waste, since each node is billed for its own cores.

Billing model

The pricing dimensions that drive this cost.

VM DB systems are billed per second with a one-minute minimum, on enabled cores plus block storage.

Enabled OCPUs or ECPUs
Billed per OCPU-hour or ECPU-hour for each node, at a license-included or BYOL rate depending on the edition chosen
Storage
Billed per GB-month separately from cores, as Database Storage on ECPU shapes or Block Volume storage and performance units on OCPU shapes
Flexible shapes
AMD E4, Intel X9 and Ampere A1 shapes where the OCPU count, and memory with it, can be changed; shape change from AMD E5 is currently not supported
ECPU x86 shapes
VM.BaseDB.x86 and VM.Standard.x86, sized in increments of 4 ECPUs with 8 GB of memory per 4 ECPUs

How to detect

4 checks to find it in your estate.

  • Review Cloud Advisor's Downsize Underutilized Base Database System recommendation, which flags systems whose maximum node-average CPU over the last seven days is below the profile threshold (5%, 10% by default, or 15%); note that it only scans older VM.Standard1 and VM.Standard2 shapes
  • For flexible and ECPU shapes, chart CpuUtilization, MemoryUtilization and LoadAverage in the oci_database_cluster namespace per DB system, and CpuUtilization in the oci_database namespace per database, over a period that includes month-end and batch peaks
  • Enable Database Management (Cloud Advisor raises an Enable Database Management recommendation when it is off) to get database performance metrics before resizing; basic management adds no cost, full management does
  • Compare the enabled core count per node with peak observed usage and flag systems that never exceed a fraction of their cores

How to fix

4 ways to remove the waste.

  • Reduce the OCPU or ECPU count with Change Shape (for ECPU shapes, Update ECPU count per node); on flexible shapes memory scales down proportionally, so confirm SGA and PGA settings fit the new memory
  • Use the Cloud Advisor fix-it flow for supported shapes, or change the shape manually; Cloud Advisor keeps the node count the same
  • Plan a change window: changing shape requires a restart, which multi-node RAC systems perform in a rolling fashion without database downtime; shape change from the AMD E5 flexible shape is currently not supported
  • Where existing licenses qualify, compare the BYOL rate; since the VM.Standard.x86 shape and OCPU-metered SKUs were retired effective July 31, 2026 (existing deployments keep running, new provisioning and renewals are affected), size any replacement VM.BaseDB.x86 system from measured usage rather than copying the old core count

Documentation

Vendor references for pricing and configuration.