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.
- Base Database Service Pricingoracle.com
- Cost Management Recommendationsdocs.oracle.com
- Change the Shape of a DB Systemdocs.oracle.com
- About DB Systemsdocs.oracle.com
- Available Metrics for Base Database Service Resourcesdocs.oracle.com
- Bare metal and virtual machine DB systems now use per-second billingdocs.oracle.com