Oracle Database is sold in two principal commercial editions. The Admodum read on what separates SE2 from EE, the named feature list that elevates a deployment, the socket-versus-processor metric divide and what the buyer should hold in any edition decision.
Oracle Database is sold in two principal commercial editions: Standard Edition 2 and Enterprise Edition. The Express Edition and Personal Edition are out of scope for enterprise procurement. The two commercial editions differ on the per-deployment metric, the per-deployment feature surface and the deployment-substrate restriction.
SE2 is sold per socket and is limited to servers with a maximum of two sockets (or two sockets per cluster node in a clustered configuration). The maximum allowed CPU thread count under SE2 is sixteen. The feature surface is restricted to the core SE2 catalogue; the wider EE catalogue (options and management packs) is not available under SE2.
EE is sold per processor under the core-factor table (see the companion processor-metric article and the core-factor table article). EE has no socket cap and no thread limit. The full EE catalogue plus the named options and management packs is available under EE.
A short, named list of features is available only under Enterprise Edition. Activating any feature on the list against an SE2-licensed deployment elevates the deployment to EE for the purpose of licence count and creates an audit exposure if the EE licences have not been purchased.
The note on RAC: Real Application Clusters is available under SE2 in a restricted form (SE2 cluster nodes are capped at one socket each, with a maximum of two cluster nodes). The unrestricted RAC option is an EE-only feature. The buyer running a clustered SE2 deployment should record the cluster topology explicitly to defend the SE2 read against any future audit.
An LMS audit reads the deployed feature use against the contracted edition. The LMS scripts collect the data from DBA_FEATURE_USAGE_STATISTICS (the data dictionary view that records the historical feature activations on the database). The view records the time of first use, the time of last use and the count of uses for each named feature.
The audit position will be that any activation of an EE-only feature against an SE2-contracted deployment is a compliance event. The publisher reading expands the audit exposure across the entire historical feature-use record (not just the current activation).
The buyer-side defence reads the activations against the deployment topology and the contractual entitlement. A feature that activated once under a DBA test, never used in production and not active at the current date is a different audit position from a feature in active production use. The defensible reading sits inside the audit-quality inventory.
A buyer running EE today may have a defensible commercial position to downgrade to SE2 in the next renewal cycle. The downgrade reads against three questions: does the deployment use any EE-only feature today; would the workload run on SE2 without functional degradation; does the deployment topology fit the SE2 cap (two sockets per server, sixteen-thread limit)?
Where the answers align (no EE-only feature in use, workload runs on SE2, topology fits the cap), the renewal can repackage the EE licences as SE2 entitlements at a materially lower commercial position. The Admodum methodology runs the downgrade audit as part of the renewal cycle. The downgrade is reflected in the Schedule A repackaging.
Where one of the answers does not align, the EE position is the correct position. The Admodum methodology then audits the EE feature use to ensure that the contracted entitlement matches the deployed reality. The full reading sits in the ULA Certification paper for the ULA case and the LMS Audit Defence paper for the audit case.
SE2 deployments on AWS, Azure or GCP run under the Oracle Cloud Authorisation document. The cloud authorisation reads SE2 against the vCPU count rather than against the socket count (the socket cap does not directly translate to the hyperscaler instance shape). The authorisation document publishes its own conversion rule for SE2 on the cloud substrates.
The buyer-side methodology reads the SE2 cloud authorisation rule before any cloud migration. A workload sized for an on-premise SE2 footprint may require a different licence count on the cloud authorisation read. The wider read sits in the companion article The Oracle Cloud Authorisation document.
For most enterprise cloud deployments, EE remains the commercially sensible edition because the cloud substrate removes the socket-cap protection that SE2 enjoys on-premise. The Admodum methodology runs the edition decision as part of the cloud architecture review.
The buyer holds three positions in any SE2-versus-EE decision. The first is the feature-use audit, reconciled against the contracted edition. The second is the deployment topology audit, reconciled against the SE2 socket cap. The third is the workload-functional audit, recording whether any EE-only feature is load-bearing for the workload.
Where the three audits support SE2, the renewal can repackage the licences at the SE2 position. Where one or more audits do not support SE2, EE is the correct position and the feature-use audit becomes the input to the renewal-cycle commercial position.
The wider editorial context sits in the Oracle licensing pillar. The engagement entry point sits in the Oracle practice. Active LMS audits route through the Audit Defence programme.
Partitioning, Advanced Compression, Diagnostic Pack, Tuning Pack.
The view the LMS scripts read; what the report sees.
The Multitenant Pluggable Database scheme and the four-PDB threshold.
A senior Admodum Oracle advisor will run the SE2-versus-EE audit against your deployed estate on a private call. Active audits route to the Audit Defence programme.