The Oracle environment and Oracle’s licensing terms are complex enough that it
is genuinely easy to become non-compliant without doing anything you would
recognise as wrong — and to be liable for additional licence costs on top. This
is the first of two articles setting out the most common reasons Oracle
licensing drifts out of compliance.
Part II covers usage tracking, indirect access, virtualisation and the Oracle
Server Worksheet.
Misunderstanding the terminology and the agreements
Not every Oracle licensing problem is technical. A good number start with the
paperwork.
Oracle licensing agreements are regularly tailored to the individual customer.
That flexibility is useful when the contract is signed and a liability
afterwards, because the environment keeps changing and the agreement does not.
A consolidation project, a new cluster, a migration that seemed purely
operational — any of these can leave you in breach of terms nobody has read in
three years.
Cores are not processors
The second recurring misunderstanding is the relationship between processors and
cores. It is tempting to treat them as the same thing. They are not.
A processor can contain one or more cores, and for Oracle technology products
you multiply the total number of cores by the core processor licensing factor
published in Oracle’s Processor Core Factor Table to arrive at the number of
licences required. The factor varies by processor family. Get it wrong on a
large server and the error scales with the hardware.
CerteroX SAM holds processor type and core factor per host and applies them in
the licence calculation rather than leaving the arithmetic to a spreadsheet, so
a hardware refresh that changes the factor changes the position automatically.
Obsolete licence types still in service
The mainstream metrics for Oracle technology products today are Named User Plus
and Processor. Alongside them, most long-standing Oracle customers are still
running licences on metrics that are no longer sold — acquired years ago, still
perfectly valid, and governed by rules that differ from the current ones.
Confusion here is common, and it usually takes the form of treating every
licence in the portfolio the same way and measuring usage against the wrong
metric. The position that results is wrong in both directions: you can be
exposed on one product and holding unused entitlement on another, and neither
shows up until somebody asks.
Understanding the complexity is the first step towards optimising it.
One user, several accounts
Named User Plus means what it says: every user of, say, a database needs a
licence. Straightforward enough — until the same person accesses a second Oracle
database.
Their existing licence already covers them. But without the right process in
place, it is very easy for a second licence to be allocated anyway. Do this at
scale and you accumulate duplicate consumption: licences booked against people
who are already licensed, unavailable to anybody who actually needs one, and a
compliance position that looks worse than reality while costing more than it
should.
The fix is de-duplication across systems rather than per system. CerteroX SAM
resolves users across Oracle instances so a person is counted once, and the
same principle runs through the SAP named-user analysis, where users are
de-duplicated across systems before licence types are proposed.
No centralised inventory
Given the complexity of the Oracle footprint and the shape of modern global
infrastructure, many organisations do not know which Oracle products they have
installed. Where they do know the product, the edition and version are often
not visible — and the cost difference between editions is very large indeed.
Then there is the trap that catches almost everybody at least once.
Many Oracle options and management packs are installed and enabled by
default, whether or not you are licensed for them. Using an option
inadvertently activates it for licensing purposes and puts you out of compliance
from that moment. Nobody sets out to enable Partitioning, Advanced Compression
or Diagnostics Pack without buying them. A DBA reaching for a feature that is
simply there is enough.
This is the single strongest argument for continuous, automated inventory rather
than a periodic manual survey. The CerteroX SAM Oracle engine records options
and packs with the supporting evidence and an override where a use is legitimate
and can be justified, tracks edition and version, and holds licence pools with
hosting rights, geographic rules and cover-down logic for Enterprise Edition so
that entitlement is applied where it genuinely reaches. Installed titles are
normalised against the Software Recognition Database — over 3.5 million publisher,
product and version entries — so “which edition is that, exactly” is a report
rather than an investigation.
None of this makes Oracle licensing simple. It does mean the answer exists
before somebody asks for it, which is the difference between a negotiation and a
scramble.
Part II covers what happens once you move to the technical side: tracking usage,
indirect access, the virtualisation rules that catch out more organisations than
anything else, and building the Oracle Server Worksheet that Oracle’s licensing
team — now trading as Global Licensing and Advisory Services, formerly License
Management Services — will compare against what you bought.