The Oracle database options and management packs read as separately licensed priced add-ons against Oracle Database Enterprise Edition. The Admodum read on the named options, the named management packs, deployment discipline at the instance level and the feature-use defence inside an LMS engagement.
Oracle Database Enterprise Edition is licensed at the base under the processor metric (read against the core-factor table) or the named-user-plus metric. On top of the base, Oracle sells a catalogue of priced options (technical features that extend the engine) and a catalogue of priced management packs (operational features around the engine). Each is licensed separately, at its own list price, on the same metric as the Enterprise Edition base.
Options and packs cannot be licensed without an Enterprise Edition base; a buyer cannot license Partitioning without licensing the database. The list price for an option or pack is therefore an addition to the database list price; the typical option carries roughly 50% of the database list at the same metric (other options sit higher or lower in the catalogue).
The wider editorial sits in the Oracle pillar and the Enterprise Edition versus SE2 boundary sits at SE2 versus EE. The processor-metric read sits at the processor metric.
The most commercially load-bearing options are Partitioning (table partitioning and partitioned index management), Advanced Compression (OLTP and basic table compression, network compression, RMAN compression), Advanced Security (Transparent Data Encryption, Data Redaction), Real Application Clusters (RAC, the cluster database extension) and RAC One Node (the single-active-node variant of RAC).
Other named options include Active Data Guard (standby database with read-only / standby query workloads), Real Application Testing (RAT, the workload-replay tool), Spatial & Graph (spatial / graph features, note that as of Oracle Database 19c the prior packaging was modified, with selected features now included), Multitenant (the pluggable-database container architecture, where the third pluggable database in a CDB triggers the priced option), Database In-Memory (column-store extension to the database) and the Database Vault option (privileged-access controls).
The management packs are operational tooling around the database, licensed separately from the engine. The most-cited packs in audits are the Diagnostics Pack (AWR, the Automatic Workload Repository, ADDM, Active Session History and the database performance monitoring features), the Tuning Pack (SQL Tuning Advisor, SQL Access Advisor, SQL Profiles), the Database Lifecycle Management Pack (cloud-control-driven configuration management and patching automation) and the Cloud Management Pack (the Enterprise Manager extension for cloud operations).
The Diagnostics Pack and the Tuning Pack are the most-frequent unintended-use findings in an LMS engagement because the AWR feature is on by default in the database, and a database administrator who runs AWR or Statspack-with-AWR for a single tuning task triggers a feature-use signal even where the buyer has no ongoing pack deployment. The buyer-side discipline is to disable AWR at the database parameter level on instances not licensed for the Diagnostics Pack.
The wider editorial on feature-use detection sits at database feature-use. The audit defence around feature use sits at LMS scripts.
The buyer-side deployment discipline runs at the instance level. An option or pack is enabled on an instance through the database initialisation parameter (or through a SQL command that activates the feature). A buyer that has licensed Partitioning on three instances must not enable it on the fourth; the buyer-side runbook should treat the licensed-instance set as a controlled list and the unlicensed-instance set as a do-not-enable list.
The control-plane disciplines around the do-not-enable list include the database parameter control_management_pack_access (which gates the Diagnostics Pack and Tuning Pack at the AWR layer), the disablement of partitioning on unlicensed instances at the parameter level, the routine review of feature-use statistics where contractually permissible and the documentation of any one-time accidental use.
The deployment discipline also runs against the development / test / production deployment pattern. The Oracle Master Agreement does not by default carve out development or test instances; the licensing position is therefore that any instance running an option or pack feature is in scope. The buyer-side discipline is to either license the development / test instances or to keep them clear of priced-feature use.
The LMS feature-use script reads the database control file for evidence of feature use since database creation (or, in newer Oracle versions, since the AWR retention window). A signal against a priced feature on an unlicensed instance becomes an audit finding line; the buyer-side defence is to read the signal against the use case.
The defence framings include: trial use (a one-time evaluation, with documented evidence of disablement post-trial), accidental use (a non-deliberate enablement by a database administrator, immediately remediated), test-environment use that has been migrated to a licensed environment for production, and historical use that pre-dates a settlement or a contract closure. Each framing reads against the deployment-as-of-the-audit-window position; the settlement value varies materially.
The wider editorial on feature-use defence sits at database feature-use. The settlement framing at the close of an audit sits at LMS settlement position.
The buyer holds three positions on options and packs: the licensed set (what the buyer has bought against what the Enterprise Edition base), the deployed set (where the licensed features are actually enabled and used) and the audit-exposed set (where feature-use signals have been generated). The discipline is to align the three: the deployed set should sit inside the licensed set, and the audit-exposed set should sit inside the deployed set.
Where the three diverge, the buyer-side remedy depends on the divergence direction. A licensed-but-not-deployed option is a renewal-cycle reclassification opportunity (the option can be dropped at the next renewal). An exposed-but-not-licensed signal is an audit-defence question (handled through the feature-use defence). A deployed-but-not-exposed feature is a deployment-discipline question (the feature should be brought into the licensed framing or out of deployment).
The wider editorial sits in the Oracle licensing pillar and the engagement entry sits in the Oracle practice. The aggregated reading sits in the Oracle knowledge hub.
A senior Admodum Oracle advisor will read the database options and management-pack position against your deployed estate on a private call. Active audits route to the Audit Defence programme; renewal-cycle work routes to the Renewal Programme.