CPU vs OCPU vs ECPU: The Simple Oracle Cloud Sizing Guide Every DBA Should Know

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

1 Physical CPU Core = 1 OCPU = 2 vCPUs = 2 ECPUs

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.

10 physical cores = 10 OCPUs = 20 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

Common mistake: “We have 10 CPU cores on-premises, so let us provision 10 OCPUs in OCI.”

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:

OCPUs Needed = Peak CPU Usage × Physical Cores + 15% to 20% Safety Buffer

Example

Suppose your on-premises database server has:

• 10 physical CPU cores
• Peak CPU usage around 70%
• You want to add 20% safety buffer

0.70 × 10 = 7 OCPUs Add 20% buffer: 7 × 1.20 = 8.4 Round up: 9 OCPUs

So instead of blindly provisioning 10 OCPUs, you may start with around 9 OCPUs, validate workload performance, and then adjust if needed.

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.

9 OCPUs = 18 ECPUs

Autonomous Database also supports auto-scaling. This means it can automatically add more ECPUs during workload spikes and scale down when the load reduces.

For ADB: Start with the right base ECPU count, keep auto-scaling enabled, monitor usage, and then right-size.

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.

On ExaCS or ExaCC, you may sometimes need fewer OCPUs than a normal server because Exadata architecture can process Oracle workloads more efficiently.

9. Important Checks Before Final Sizing

CPU is only one part of database sizing. Before finalizing your OCI configuration, check the complete picture.

1. Collect 90 days of AWR/ASH data to understand real peak usage.
2. Check RAM requirement because CPU alone cannot solve memory pressure.
3. Check storage IOPS and throughput because many databases are I/O-bound, not CPU-bound.
4. Understand batch windows such as month-end, payroll, reporting, and large data loads.
5. Validate Oracle licensing because OCPU count can directly impact license cost.
6. Add 15% to 20% buffer for growth and unexpected peaks.
7. 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.

Easy memory line: CPU is on-prem, OCPU is OCI, ECPU is Autonomous DB. 1 OCPU = 2 ECPUs. Always size from AWR peak usage plus 20% buffer.

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.

Note: This article is written as a simplified DBA learning note for Oracle Database migration planning. Always validate final sizing, licensing, and architecture with Oracle documentation, Oracle representatives, and real workload testing.

A key difference between TP and TPURGENT

Difference between TP and TPURGENT TP

When you are using Autonomous Transaction Processing database, as well as the LOW, MEDIUM and HIGH services that are also present on the Autonomous Data Warehouse offering, there are TP and TPURGENT services that you can use. Difference  as you can see below:

SQL> select plan, group_or_subplan, cpu_p1
  2  from DBA_RSRC_PLAN_DIRECTIVES
  3  where group_or_subplan like '%TP%';

PLAN         GROUP_OR_SUB     CPU_P1
------------ ------------ ----------
OLTP_PLAN    TP                    8
OLTP_PLAN    TPURGENT             12

there is another important difference to be aware of. As the name suggests, TP is designed for “transactional processing” which means the expectation is for short, snappy transactions. A consequence of this, is that there is no capacity to perform operations in parallel when connecting to the TP service, even if you try to force it.

SQL> conn ADMIN/xxxx@myatp_tp
Connected.

SQL> create table t as select * from dba_objects;

Table created.

SQL> select owner, count(*) from t group by owner;

OWNER                            COUNT(*)
------------------------------ ----------
SYS                                 19401
SYSTEM                                472
DBSNMP                                 59
APPQOSSYS                               6
...

43 rows selected.

SQL> select * from dbms_xplan.display_cursor();

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------
SQL_ID  gupp4rhyp22fz, child number 0
-------------------------------------
select owner, count(*) from t group by owner

Plan hash value: 47235625

-----------------------------------------------------------------------------------
| Id  | Operation                  | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |      |       |       |    22 (100)|          |
|   1 |  HASH GROUP BY             |      |    43 |   430 |    22  (14)| 00:00:01 |
|   2 |   TABLE ACCESS STORAGE FULL| T    | 68290 |   666K|    20   (5)| 00:00:01 |
-----------------------------------------------------------------------------------


14 rows selected.

SQL>
SQL> select /*+ parallel */ owner, count(*) from t group by owner;

OWNER                            COUNT(*)
------------------------------ ----------
SYS                                 19401
SYSTEM                                472
DBSNMP                                 59
APPQOSSYS                               6
...

43 rows selected.

SQL> select * from dbms_xplan.display_cursor();

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------
SQL_ID  caw2nz87gxkja, child number 0
-------------------------------------
select /*+ parallel */ owner, count(*) from t group by owner

Plan hash value: 47235625

-----------------------------------------------------------------------------------
| Id  | Operation                  | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |      |       |       |    22 (100)|          |
|   1 |  HASH GROUP BY             |      |    43 |   430 |    22  (14)| 00:00:01 |
|   2 |   TABLE ACCESS STORAGE FULL| T    | 68290 |   666K|    20   (5)| 00:00:01 |
-----------------------------------------------------------------------------------

Hint Report (identified by operation id / Query Block Name / Object Alias):
Total hints for statement: 1 (U - Unused (1))
---------------------------------------------------------------------------

   0 -  STATEMENT
         U -  parallel

Note
-----
   - automatic DOP: Computed Degree of Parallelism is 1


25 rows selected.

SQL>

Compare that to when you connect to the TPURGENT service. By default, just like the TP service operations are expected to the business transactions and thus no parallelism is activated.

SQL> conn ADMIN/xxxx@myatp_tpurgent
Connected.

SQL> create table t as select * from dba_objects;

Table created.

SQL> select owner, count(*) from t group by owner;

OWNER                            COUNT(*)
------------------------------ ----------
SYS                                 19317
SYSTEM                                472
DBSNMP                                 59
APPQOSSYS                               6
...


44 rows selected.

SQL> select * from dbms_xplan.display_cursor();

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------
SQL_ID  gupp4rhyp22fz, child number 0
-------------------------------------
select owner, count(*) from t group by owner

Plan hash value: 47235625

-----------------------------------------------------------------------------------
| Id  | Operation                  | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |      |       |       |    23 (100)|          |
|   1 |  HASH GROUP BY             |      |    44 |   440 |    23  (14)| 00:00:01 |
|   2 |   TABLE ACCESS STORAGE FULL| T    | 71476 |   698K|    21   (5)| 00:00:01 |
-----------------------------------------------------------------------------------


14 rows selected.

However, under TPURGENT you can obtain parallel processing should you need it by explicitly nominating it with hint:

SQL> select /*+ parallel */ owner, count(*) from t group by owner;

OWNER                            COUNT(*)
------------------------------ ----------
SYS                                 19317
SYSTEM                                472
DBSNMP                                 59
APPQOSSYS                               6
...


44 rows selected.

SQL> select * from dbms_xplan.display_cursor();

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------
SQL_ID  caw2nz87gxkja, child number 1
-------------------------------------
select /*+ parallel */ owner, count(*) from t group by owner

Plan hash value: 129087698

--------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |          |       |       |    13 (100)|          |        |      |            |
|   1 |  PX COORDINATOR                  |          |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)            | :TQ10001 |    44 |   440 |    13  (16)| 00:00:01 |  Q1,01 | P->S | QC (RAND)  |
|   3 |    HASH GROUP BY                 |          |    44 |   440 |    13  (16)| 00:00:01 |  Q1,01 | PCWP |            |
|   4 |     PX RECEIVE                   |          |    44 |   440 |    13  (16)| 00:00:01 |  Q1,01 | PCWP |            |
|   5 |      PX SEND HASH                | :TQ10000 |    44 |   440 |    13  (16)| 00:00:01 |  Q1,00 | P->P | HASH       |
|   6 |       HASH GROUP BY              |          |    44 |   440 |    13  (16)| 00:00:01 |  Q1,00 | PCWP |            |
|   7 |        PX BLOCK ITERATOR         |          | 71476 |   698K|    11   (0)| 00:00:01 |  Q1,00 | PCWC |            |
|*  8 |         TABLE ACCESS STORAGE FULL| T        | 71476 |   698K|    11   (0)| 00:00:01 |  Q1,00 | PCWP |            |
--------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   8 - storage(:Z>=:Z AND :Z<=:Z)

Note
-----
   - automatic DOP: Computed Degree of Parallelism is 2


29 rows selected.

SQL>

Autonomous Transaction Processing (ATP)

So its important to be aware of the parallelism facilities defined for MEDIUM and HIGH. We’ll do operations in parallel whenever possible. You get faster queries and faster DML but there are implications on the way you write your scripts, the locking that will result and how commit processing must be handled. HIGH and MEDIUM are not just “bigger” versions of the LOW service.

Predefined Database Service Names for Autonomous Transaction

The predefined service names provide different levels of performance and concurrency for Autonomous Transaction Processing.

• tpurgent: The highest priority application connection service for time critical transaction processing operations. This connection service supports manual parallelism.
• tp: A typical application connection service for transaction processing operations. This connection service does not run with parallelism.
• high: A high priority application connection service for reporting and batch operations. All operations run in parallel and are subject to queuing.
• medium: A typical application connection service for reporting and batch operations. All operations run in parallel and are subject to queuing. Using this service the degree of parallelism is limited to four (4).
• low: A lowest priority application connection service for reporting or batch processing operations. This connection service does not run with parallelism.

 For standard transactional activities on ATP, make sure it uses the TP or TPURGENT services. If you need faster performance for volume operations, then HIGH and MEDIUM are your friend, 

but understand the locking and commit implications.

Predefined Database Service Names for Autonomous

 Databases 

Regarding parallelism for different services.

Oracle doc -

https://docs.oracle.com/en-us/iaas/autonomous-database/doc/connecting.html#GUID-07401C82-6A01-4CDF-AAE5-54B78B50CA0A

Ref - Connor Mcdonald ( TP AND TP URGENT )

U

R

GENTA key difference between

 TP and TPURGENT

Autonomous Database

 Benefits of Oracle Autonomous database

Youtube links-

https://www.youtube.com/watch?v=nyo3FsBpKBE

How to share AWR data for your Autonomous Database to help analyze performance

 

How to share AWR data for your Autonomous Database to help analyze performance

Occasionally, you may need help analyzing performance irregularities or errant SQL. To help solve the problem, Oracle Support or specialist teams will ask for an extract of the AWR data from the database for the period spanning the issue. For on premise databases, you follow the instructions found here. You do it a little differently with Autonomous Database. Here's how it's done:

Before running the extract of the data from the database, you need to get the information used as input parameters to the data extract procedure. In this guide, we will run all the commands from the SQL worksheet in Database Actions; but, they can be run from any other SQL tool like SQLcl, SQLPlus or SQL Developer.

The first thing to do is find a directory for the procedure to write the output file to. Run the following query against your database to list the current directories available in the ADB:

select *
from all_directories;

By default, an Autonomous Database is created with two directories: DATA_PUMP_DIR and SQL_TCB_DIR. You can use these destincation directories or any other directory where you have privileges to write data. You can also create a new directory specifically for this task. If you want to do the latter, you can find how to do that here.

In our case we will use the DATA_PUMP_DIR directory.

The next step is to get the DBID of our database and the beginning and end snap IDs of the range of snapshots to include in the extract. This information can be read from the AWR_PDB_SNAPSHOTS table. You can use the begin_interval_time and end_interval_time for each snapshot to make sure the time range is contained within the snapshot range. I used this query to get those values (replacing the time range).

select dbid,snap_id
from awr_pdb_snapshot
where to_date('2023-09-20 11:02:00','YYYY-MM-DD HH24:MI:SS') between begin_interval_time and end_interval_time
or to_date('2023-09-20 14:02:00','YYYY-MM-DD HH24:MI:SS') between begin_interval_time and end_interval_time
order by snap_id;

The output in my example is:

Now that we have all the parameters, let's run the extract procedure:

begin

/* call PL/SQL routine to extract the data */
  dbms_workload_repository.extract(dmpfile => '<filename>',
     dmpdir => '<directory to write file to (case sensitive)>',
     bid => <begin snapshot id>,
     eid => <end snapshot id>,
     dbid => <DBID>);
end;
/

Replace:

<filename> with the name without and extension, ie. awrdump
<directory to write file to (case sensitive)> with the directory name, ie. DATA_PUMP_DIR
<begin snapshot id> with the first snap_id in the list if you used the supplied query, ie. 3
<end snapshot id> with the second snap_id in the list if you used the supplied query, ie. 6
<DBID> with the DBID of on the query, ie. 2946909002 

This should run for a while depending on the number of snaps in the extract. Once it completed successfully you check that the file has been written to the selected directory. You can do this by running:

SELECT * FROM DBMS_CLOUD.LIST_FILES('<directory name>');

The next step would be to move this file into object storage so it can be shared with the requester. The steps to do this is described in the documentation.

The final step once the credential has been created should be copying the file, which is done by running the following.

BEGIN
DBMS_CLOUD.PUT_OBJECT (
          credential_name => '<credential name>'                      
          ,object_uri =>'<object storage bucket URI with file name>'                            
          ,directory_name =>'<source directory on ADB>'
          ,file_name =>'<source file name>');       
end;
/

Once the file is in an object storage bucket it can be shared by either downloading it or by creating a pre-authenticated request.

Ref:-Article link