Why your Oracle Core Counts might be wrong!

Many enterprise software licenses, in particular Oracle products, are measured using a core metric. In simple terms the amount you pay is directly linked to the number of CPU cores on the physical server they are running on. There are lots of other factors that also impact the license cost (core factor, virtualization, DR, etc.) but it all comes back to the number of cores.

A quick glance at the Oracle price list before discounts for Database Enterprise Edition gives you a starting figure of $47,500, so getting the core count wrong is a very significant cost.

The problem is if you are relying on the standard methods of interrogating the operating system you might be significantly over counting the number of cores and paying significantly more than you should.

Without getting into too much technical detail the cause of the issue is that the operating system can, for certain makes and models of chip, report back the wrong number of cores.

Example:

Scan of large server estate containing 54 servers running Itanium 9340 each reported 3 different core counts.

Row	Servers	Reported Cores	Actual Cores	Reporting Error	Core Count	Corrected Core Count
1	12	4	4	Correct	48	48
2	6	2	4	Under	12	24
3	40	8	4	Over	320	160
	54				380	232

This is a net error of 148 cores!

To put this into perspective, if these servers were running Oracle Database Enterprise Edition (common on these servers) with a core factor of 0.5 you have a license error of $3,515,000. With a 70% discount this is still a significant error of over $1,000,000.

In our example the total compliance gap was in the customer’s favor but it could just as easily have been against the customer (row 2 under reported cores).

Although our example focuses on UNIX operating systems this problem also affects Windows servers.

What to do next?

If you have a small number of servers your team can manually check that the core count reported matches the manufacture’s specification.

If you have a large number of servers this requires significantly more effort and needs to be automated if you are to avoid costly mistakes.

Conclusion

As you have seen from the example you cannot afford to ignore the problem of core counts being reported wrongly by the operating system as the risks are real and very expensive.