1. Measure database load
- DB system metrics: CPU utilisation, storage utilisation (DATA/RECO).
- Inside the database: AWR/ASH (Enterprise Edition with Diagnostics Pack) or Statspack (SE): average active sessions vs CPU count over a few weeks, including month-end.
-- average and peak DB CPU (approx.) per hour from AWR, last 30 days
SELECT TO_CHAR(begin_time, 'YYYY-MM-DD HH24') AS hour,
ROUND(AVG(value), 2) AS avg_cpu_per_sec,
ROUND(MAX(value), 2) AS max_cpu_per_sec
FROM dba_hist_sysmetric_summary
WHERE metric_name = 'CPU Usage Per Sec' AND begin_time > SYSDATE - 30
GROUP BY TO_CHAR(begin_time, 'YYYY-MM-DD HH24')
ORDER BY max_cpu_per_sec DESC FETCH FIRST 20 ROWS ONLY;
CPU Usage Per Sec is in centiseconds per second: divide by 100 to get CPUs in use.
2. Scale CPU
On flexible VM DB system shapes, change the CPU (OCPU or ECPU, depending on the shape and billing model) from the console or CLI. Check whether your shape supports online scaling or needs a restart, and for RAC how nodes are handled:
oci db system update --db-system-id $DBS --cpu-core-count 4
With Enterprise Edition licences (BYOL), fewer CPUs also means fewer licences consumed.
3. Edition: pay for what you use
| Edition | Includes (simplified) |
|---|---|
| Standard Edition | Core database; limits on sockets/threads, no EE options |
| Enterprise Edition | Core EE features (e.g. Data Guard); most options and management packs not included |
| Enterprise Edition High Performance | EE + many options and management packs |
| Enterprise Edition Extreme Performance | Adds options such as RAC, In-Memory, Active Data Guard |
Check what the databases actually use (DBA_FEATURE_USAGE_STATISTICS) before choosing:
SELECT name, detected_usages, currently_used, last_usage_date
FROM dba_feature_usage_statistics
WHERE detected_usages > 0 ORDER BY name;
A database on Extreme Performance that uses no RAC, In-Memory or Active Data Guard features may be paying for options it doesn't need. Changing edition usually requires a new DB system and migration, so plan it for the next upgrade or rebuild.
4. Licence model
| Model | Use when |
|---|---|
| License Included | No eligible on-prem licences |
| BYOL | Existing Oracle licences with support can be applied. Lower hourly price |
Confirm with your licensing owner. BYOL rules for cloud CPU counting differ from on-prem.
5. Storage
- Block storage DB systems: storage can be increased, not reduced. Start with realistic sizes and use alerts on DATA/RECO usage (see the "out of storage" Sev1 post).
- Purge old archive logs and backups per policy (RMAN retention, automatic backups retention days).
- Large reporting data that's rarely queried: consider partitioning and moving old partitions to compressed tablespaces, or to Object Storage via external tables.
6. Stop non-production
oci db node list --compartment-id $C --db-system-id $DBS --query 'data[].id' --raw-output
oci db node stop --db-node-id <node-ocid>
oci db node start --db-node-id <node-ocid>
Compute billing stops while nodes are stopped (storage continues). Check current billing behaviour for your shape.
7. Consider other services
- Many small databases with simple needs: Autonomous Database (with elastic pools) may cost less to run and operate.
- Very large estates: Exadata Database Service consolidates many databases with online CPU scaling.
Warning
Scaling CPU down on a database with peaks you haven't measured (month-end close, payroll) can cause outages at the worst time. Use at least one full business cycle of AWR data.
Checklist
- AWR/Statspack load over a full business cycle
- CPU scaled to real need
- Feature usage checked; edition matched
- Licence model confirmed
- Storage, archive log and backup retention reviewed
- Non-production nodes stopped out of hours