Licensing ODA on NUP’s and with different metrics

Job Oprel 2
0 0
Read Time:3 Minute, 52 Second

Since Oracle launched the Oracle Database Appliance a few years ago it has become clear that only the Enterprise Edition is allowed on the machine. But when NOT using the bare metal setup (not the OracleVM) it’s not always quite transparent what kind of licensing requirements is needed and allowed. More direct :

1. Is it allowed to license the ODA on NUP´s ? Spoiler alert: yes, this is allowed.

2. Is it allowed to license with different metrics within 1 ODA, e.g. 1 node on NUP’s and the other node processor-based?

I’ll try to explain and answer the two questions in the next chapter.


1. Is it allowed to license the ODA on NUP´s ?

This question may be well known to some of us, but for the context of the second question and the new model x5-2 it’s worth mentioning.

The Documentation is not completely clear about this. In a former version of the documentation it was stated as: “Customers are only required to license processor cores”. That phrase disappeared in the current documentation somehow, but is still valid: licensing on processor cores, but not processor metric!

In the FAQ :

What database licenses are required for the Oracle Database Appliance X5-2?

–> Answer:  The Oracle Database Appliance enables customers to purchase database licenses using a capacity licensing model. Therefore, customers are only required to license processor cores that they plan to use.

In the partitioning document:

Oracle recognizes a practice in the industry to pay for server usage based on the number of CPUs that are actually turned on – the “Capacity on Demand,” or Pay as You Grow” models. Oracle allows customers to license only the number of cores that are activated when the server is shipped. Note: Oracle does not offer special licensing terms for server usage models where the number of CPUs used can be scaled down or their usage varied – the “Pay Per Use” or “Pay Per Forecast” models.

So basically in all the papers it´s stated that you have to licence on cores, but not which processor metric…

So I asked LMS a while ago to verify the ‘Note’ in the partitiong document. They had (in the former days) to go to Corporate level to get this question answered:

There is no “licensing” requirement to license ODA with any specific metric. Whichever metric they can stay in compliance with, based on their usage, they can license by that.

So, yeah, it’s possible to license by NUP´s. Now there are more opportunities to use the ODA in development or testing environments..

Example for a scaling to 4 cores per node (8 cores total), based on the core-factor table:

–> 8 cores x 0,50 (core factor) x 25 (min.users per oracle processor for database usage) = 100 users.

2. Is it allowed to license 1 node on NUP’s and the other node processor-based?

Two sources gave already an answer:

– This Oracle blog-post.

– This Oracle Data Sheet X-5 of the X5-model:

Both servers must have the same number of cores enabled, however it is possible to license
software for only one of the servers or both servers, depending on the high availability requirements

but that’s not the official LMS statement. So to be sure, we asked LMS. Here’s the answer (to be clear: this is not the original quote, it’s translated from Dutch):

When both nodes within the ODA act as each other’s data-recovery environment, than they must be licensed with the same metric. Is one node acting as a production server and the other as a test server, than the nodes are allowed to differ from metric.   

So it’s allowed to license one server on NUP’s and the other one as processor. But, as always, for questions about your definitive configuration, contact your local Oracle Representative.

And just to be clear, this is only possible when creating single E.E.-databases within the ODA. When creating such a database with the OAKCLI-tool, you will get a question like this where the database should reside:





ODA-licensing doc:


Partitioning doc:

Core-factor table:

Oracle blogging:

ODA X5 datasheet: 

About Post Author

Job Oprel

Until February 2019, Job worked as a solution architect at AMIS Services with a special interest in Oracle licensing, High Availability architectures and managing complex (Oracle) environments, which includes Cloud environments.With a background as Oracle developer, DBA, team-manager and license-consultant he is able to utilize the Oracle technologies to a cost-efficient architecture for his customers.He is regularly involved in consultancy regarding: - Unlimited License Agreements (ULA). - License compliancy-checks and advice regarding optimizing the environment. - Second opinions. - Education / presentations about licensing and managing your infrastructure in the most cost-efficient manner.Twitter: @jobaclenl
0 %
0 %
0 %
0 %
0 %
0 %

Average Rating

5 Star
4 Star
3 Star
2 Star
1 Star

2 thoughts on “Licensing ODA on NUP’s and with different metrics

  1. Interesting info. However, I disagree on the first point,

    1. Is it allowed to license the ODA on NUP´s ? Spoiler alert: yes, this is allowed. ==> TRUE, BUT…. you have to license all the CPUs. The only way to apply sub-capacity licensing is through the generation of a core key associated to your CSI# and this only works if the CSI is for processor licensing

  2. Thanks for an interesting blog post Job!

    I disagree with this LMS statement though and wonder what it’s based on. I have been told multiple times by Product Management that the “10 day fail-over rule” can be applied to ODA (since each node is connected to shared storage in a single data center) so I would have thought you could still do fail-over (for up to 10 days/10 occasions per year) even if one node (or its ODA Base if you’re using ODA VP) is licensed by Oracle Processor (for production) and the other by NUP. Of course if a node fails you may well find the second node has insufficient cores to run both production and test databases adequately, in which case you may have to sacrifice some test databases until the first node had been repaired, so it won’t suit everyone.


Comments are closed.

Next Post

De business case voor vervanging van maatwerksoftware

IT-projecten rond maatwerk software voldoen vaak niet aan de financiële verwachtingen. Niet zelden is een voorname oorzaak dat naast de functionele uitbreidingen waar de business case en het budget op gebaseerd zijn, ook een flinke technische inhaalslag moet worden gemaakt die niet expliciet in de begroting is opgenomen. Vervanging van […]
%d bloggers like this: