There is no need to decrease the number of cores on your ODA when using Standard Edition 2, because your license is based on the number of physical CPU. So why would you do that? Obviously, the more cores you have, the more performance you should get. But that simply isn’t always true.

Base CPU speed and Turbo Boost

If you didn’t read my previous blog, please do so to understand how Xeon processors work in your ODA: Oracle database appliance and CPU speed

Basically, the Xeon processors inside your ODA can benefit from Turbo boost technology, meaning that CPU speed can automatically increase (and decrease) depending on various factors. So the main question is: what should I do to maximize the CPU speed and leverage the Xeon(s) inside my appliance? As you may guess, there is something to do with this Turbo boost.

What happens to my processors when all cores are enabled?

When all the cores are enabled on your ODA, like typically if you are using Standard Edition 2, CPU will most probably not run at maximum speed. On an ODA X8-2S, it means that the 16 cores will run somewhere between 2.3GHz and 3.9GHz. This is what I get on my server:

cat /proc/cpuinfo | grep MHz
cpu MHz : 2799.980
cpu MHz : 2799.993
cpu MHz : 2799.971
cpu MHz : 2799.945
cpu MHz : 2779.100
cpu MHz : 2800.195
cpu MHz : 2799.870
cpu MHz : 2799.964
cpu MHz : 2799.838
cpu MHz : 2804.276
cpu MHz : 2800.073
cpu MHz : 2791.581
cpu MHz : 2800.005
cpu MHz : 2800.106
cpu MHz : 2799.988
cpu MHz : 2800.032
cpu MHz : 2799.805
cpu MHz : 2799.913
cpu MHz : 2799.999
cpu MHz : 2799.891
cpu MHz : 2697.071
cpu MHz : 2799.752
cpu MHz : 2799.983
cpu MHz : 2799.845
cpu MHz : 2799.625
cpu MHz : 2799.864
cpu MHz : 2799.999
cpu MHz : 2631.688
cpu MHz : 2799.967
cpu MHz : 2799.815
cpu MHz : 2799.677
cpu MHz : 2799.876

All the 32 threads are running at 2.8GHz. It can eventually go lower.

It will be the same for an ODA X8-2M, all the cores of both processors will run at quite low frequency (X8-2M is basically a X8-2S with twice the amount of RAM and a second identical CPU).

What happens if I disable half of the cores?

What to expect from disabling half of the cores? In my case, I can do that because my server is only dedicated to 3 databases, so no doubt I will never be able to use the 16 cores of my X8-2S. Remember that Standard Edition 2 cannot use parallelism, thus having less cores will probably not make any difference.

odacli update-cpucore -c 8
"jobId" : "4cd51240-6501-4633-8575-0e0ff697bd07",
"status" : "Created",
"message" : null,
"reports" : [ ],
"createTimestamp" : "August 24, 2020 12:11:22 PM CEST",
"resourceList" : [ ],
"description" : "CPU cores service update",
"updatedTime" : "August 24, 2020 12:11:22 PM CEST"
sleep 120; cat /proc/cpuinfo | grep MHz
cpu MHz : 3600.000
cpu MHz : 3600.160
cpu MHz : 3600.165
cpu MHz : 3600.016
cpu MHz : 3600.071
cpu MHz : 3600.137
cpu MHz : 3600.003
cpu MHz : 3600.026
cpu MHz : 3600.019
cpu MHz : 3600.037
cpu MHz : 3600.001
cpu MHz : 3599.999
cpu MHz : 3600.018
cpu MHz : 3599.990
cpu MHz : 3600.010
cpu MHz : 3599.992

Remaining cores are now running at higher speed. But is it better? Let’s try with a basic statistics compute:

Before decreasing (16 cores):
sqlplus / as sysdba
host date
Mon Aug 24 13:39:02 CEST 2020
exec dbms_stats.gather_database_stats;
host date
Mon Aug 24 13:40:14 CEST 2020

Statistics were completed in 34 min.

After decreasing (8 cores):
sqlplus / as sysdba
host date
Mon Aug 24 12:12:28 CEST 2020
exec dbms_stats.gather_database_stats;
host date
Mon Aug 24 12:39:59 CEST 2020

Statistics were completed in 27 min.

True, it’s better. Higher core speed made my statistics compute 20% faster with my core running 23% faster: what a surprise!

Let’s try on the other ODA (located in a different site) on nearly the same database to confirm that:

Before decreasing (16 cores):
sqlplus / as sysdba
host date
Mon Aug 24 13:48:03 CEST 2020
exec dbms_stats.gather_database_stats;
host date
Mon Aug 24 14:21:49 CEST 2020

Same duration of 34 min.

After decreasing (8 cores):
sqlplus / as sysdba
host date
Mon Aug 24 14:30:10 CEST 2020
exec dbms_stats.gather_database_stats;
host date
Mon Aug 24 14:57:59 CEST 2020

27 min.

The same behaviour has been seen. I have now less cores available on my systems but the enabled cores are running at 3.6GHz.

Which number of cores should I enable?

It mainly depends on your number of databases. If your ODA is running much more databases than the cores available, do nothing. If your databases number is somewhere between 1 and half the cores available, you surely will benefit from a core decrease. The best would probably to proceed step by step, start by halving the enabled cores, the biggest gain is here. On a X8-2, the jump is from 2.8 to 3.6GHz, not bad. If you divide again by 2 you can expect to reach maximum speed of 3.9GHz: very interesting for small number of databases with very demanding batches. Note that you will have to use the –force option to decrease several times the number of cores, because this feature is made for those using Enterprise Edition, and with this edition you cannot decrease the number of licenses dedicated to your ODA (you can only increase). If you decreased too much, you can increase again without any problem (and it doesn’t require a reboot). There is no problem playing with the number of enabled cores with your license: Standard Edition is NOT related to the number of cores. You can decide how many cores you want, and configure the perfect setting for your databases.

And regarding Enterprise Edition?

The core speed will be the same, because which edition you’re using doesn’t make any difference: it’s hardware and OS related. The best setting would probably to never enable more than half of the cores: meaning 8 cores on a X8-2S, 16 cores on a X8-2M and 32 cores on a X8-2HA (2x 16). If you plan to consolidate your databases on a small number of ODAs, maybe it’s better to distribute your Enterprise licenses on more ODAs.


If you’re running on ODA X7 or X8 with Standard Edition 2, and have deployed one of the 19c releases (it doesn’t work with previous versions), don’t miss this important feature to leverage at best your ODAs.