CPU, OCPU and ECPU Explained in Simple Words
If you are moving Oracle Database from on-premises to Oracle Cloud Infrastructure, this is one concept you must understand clearly.
During Oracle Database cloud migration, many teams get confused with three words: CPU, OCPU and ECPU.
On-premises servers normally talk in terms of CPU cores. Oracle Cloud Infrastructure uses OCPU for many database services and ECPU for Autonomous Database. If we do not understand the difference, we may oversize the cloud database, increase cost, or undersize it and create performance issues.
1. The Golden Rule to Remember
This is the most important line to remember. In simple words:
- CPU Core is the on-premises language.
- OCPU is the normal OCI database compute language.
- ECPU is mostly used with Autonomous Database.
- 1 OCPU = 2 ECPUs.
2. CPU vs OCPU vs ECPU
| Term | Where Used | Simple Meaning | Easy Memory |
|---|---|---|---|
| CPU | On-premises server | Physical processor core in your server | Traditional server world |
| OCPU | OCI Base DB, ExaCS, ExaCC | Oracle Cloud Processing Unit | 1 OCPU = 1 physical core |
| ECPU | Autonomous Database | Elastic CPU | 1 ECPU = half OCPU |
3. Do Not Copy On-Prem CPU Count Blindly
This approach can be costly. Your on-premises server may have 10 cores, but it may not be using all 10 cores all the time. In many production databases, CPU usage may be around 50% to 70% during normal workload, with higher peaks during batch jobs, month-end processing, or reporting.
The better approach is to check real workload data from AWR and ASH reports. Size based on actual peak CPU usage, not just the number of cores installed on the physical server.
4. Simple Sizing Formula
Use this easy formula:
Example
Suppose your on-premises database server has:
- 10 physical CPU cores
- Peak CPU usage around 70%
- You want to add 20% safety buffer
5. What About ECPU?
If you are moving to Autonomous Database, Oracle uses ECPU. Since 1 OCPU = 2 ECPUs, you simply double the OCPU number.
Autonomous Database also supports auto-scaling. This means it can automatically add more ECPUs during workload spikes and scale down when the load reduces.
6. Which OCI Database Service Uses Which Unit?
| OCI Database Service | Compute Unit | Best For |
|---|---|---|
| Base Database VM | OCPU | Lift-and-shift migrations, full DBA control, predictable workloads |
| Exadata Cloud Service | OCPU | Large, mission-critical, high-performance databases |
| Exadata Cloud@Customer | OCPU | Customers who need Exadata performance but must keep data in their data center |
| Autonomous Database | ECPU | Managed database, auto-scaling, less administration, variable workloads |
7. Why More OCPUs or ECPUs Improve Performance
Think of CPU like workers in a kitchen. More workers can handle more orders in parallel. Similarly, more OCPUs or ECPUs allow Oracle Database to process more work at the same time.
- Faster queries: More CPU can help large queries run faster using parallel processing.
- More concurrent users: More sessions can be served without waiting for CPU.
- Shorter batch window: Nightly jobs, reports, and month-end jobs can finish faster.
- Better workload handling: More compute gives better room during peak business hours.
8. Exadata Point to Remember
Exadata is different from normal servers because of features like Smart Scan. Smart Scan can offload some work to Exadata storage cells, which means the database server CPU does not have to do all the heavy lifting.
9. Important Checks Before Final Sizing
CPU is only one part of database sizing. Before finalizing your OCI configuration, check the complete picture.
- Collect 90 days of AWR/ASH data to understand real peak usage.
- Check RAM requirement because CPU alone cannot solve memory pressure.
- Check storage IOPS and throughput because many databases are I/O-bound, not CPU-bound.
- Understand batch windows such as month-end, payroll, reporting, and large data loads.
- Validate Oracle licensing because OCPU count can directly impact license cost.
- Add 15% to 20% buffer for growth and unexpected peaks.
- Test with real workload before production cutover.
10. Quick Cheat Sheet
| On-Premises Situation | OCI Sizing Thought Process | Recommended Check |
|---|---|---|
| 10 physical cores | Start by mapping to 10 OCPUs or 20 ECPUs | Then reduce or adjust based on AWR peak usage |
| 70% peak CPU usage | 10 × 70% = 7 OCPUs | Add 15% to 20% buffer |
| Steady workload | OCPU-based service may be suitable | Base DB VM, ExaCS, or ExaCC |
| Variable or bursty workload | ECPU-based ADB may be suitable | Enable auto-scaling and monitor |
| Mission-critical workload | Consider Exadata options | Evaluate ExaCS or ExaCC |
11. Key Takeaways
- 1 Physical Core = 1 OCPU = 2 ECPUs = 2 vCPUs.
- CPU is on-premises language.
- OCPU is used for OCI Base DB, ExaCS, and ExaCC.
- ECPU is used for Autonomous Database.
- Do not copy on-prem CPU count blindly.
- Use AWR/ASH reports to check actual peak CPU usage.
- Always add 15% to 20% buffer.
- Check CPU, memory, storage, IOPS, licensing, and real workload testing.
- Right-sizing can save cost and avoid performance problems.
Conclusion
CPU, OCPU and ECPU look confusing at first, but the concept becomes simple once we remember the conversion rule. The biggest mistake during cloud migration is copying on-premises CPU count directly into OCI sizing.
The right approach is to collect AWR/ASH data, understand real peak usage, add a practical safety buffer, validate licensing, and test with real workload before production cutover.
For DBAs and cloud architects, this understanding is very important because it directly impacts performance, Oracle licensing, and monthly cloud cost.
