Licensing Oracle on engineered systems means counting the enabled database server cores and applying the core factor table, so only the cores you switch on through capacity on demand drive the processor count.
How is Oracle licensed on an engineered system?
Oracle is licensed on an engineered system by counting the enabled cores on the database servers and applying the core factor table to reach a processor count. An engineered system such as Exadata ships with a fixed hardware configuration, but you do not automatically license every physical core in the rack. You license the database tier cores that are actually enabled, which means the configuration choices you make at install time and during growth set your exposure. This is a different counting model from a generic server, and findings sometimes apply the wrong one.
How does capacity on demand work?
Capacity on demand works by letting you enable a subset of the physical cores on each database server and license only the cores you have enabled. The unused cores stay switched off until you choose to grow, at which point you enable more and license the increase. Capacity on demand is a contractual mechanism, so the enablement must be done within the rules and recorded, but used well it keeps the licensed footprint aligned to real workload rather than to the full rack. A finding that counts every physical core ignores a capacity on demand configuration you are entitled to use.
How does the core factor apply?
The core factor applies to the enabled database server cores exactly as it does on other Oracle hardware, reducing the raw core count to a processor count. The relevant factor depends on the processor family in the engineered system, so confirm the factor against the published core factor table rather than assuming a value. On a large configuration the difference between the right and the wrong factor is substantial, which is why the factor is one of the first things to verify on any engineered system finding.
| Driver | Buyer side check |
|---|---|
| Enabled cores | Confirm capacity on demand enablement, not full rack |
| Core factor | Apply the correct factor for the processor family |
| Database options | List the priced options actually in use |
| Storage software | Read its own terms against the contract |
Are the storage cells licensed?
Database licensing applies to the enabled database server cores rather than the storage cells, but the storage software on an engineered system carries its own terms that you should read against your contract. Treating the whole rack as if it were one undifferentiated pool of licensable cores is a common overcount. The buyer side position is to separate the database tier from the storage tier, license each according to its own rules, and decline a single blended count that inflates the figure.
Where do options and packs creep in?
Options and management packs creep in on engineered systems because the platform is built for performance and many features are close to hand. A single Enterprise Manager click can flag Diagnostics or Tuning Pack as used, and several options install by default. On a high value engineered system the options exposure can rival the database exposure, so the same discipline applies here as on any Enterprise Edition estate: know which options are genuinely used, and remove or properly license the rest before a finding does the counting.
A worked example
Consider an anonymized financial services firm running a quarter rack engineered system. The preliminary finding counted every physical core in the rack and ignored the capacity on demand configuration that had only a portion of the cores enabled. The defense produced the capacity on demand records, applied the correct core factor, and separated the database tier from the storage software. The defensible processor count landed well below the opening number. No client names, sector level example only.
The buyer moves
The buyer moves on an engineered system are to document the capacity on demand enablement, apply the correct core factor to the enabled cores, separate database and storage software, and inventory the options actually used. Each move counters a specific overcount, and together they keep an engineered system finding tied to the configuration you really run rather than to the full hardware in the rack.
Where to go next
This piece links up to the Oracle Database Licensing Guide. Keep reading across the cluster:
To pressure test an engineered system finding, book a strategy call or read the Oracle Database Licensing Guide.