Oracle Database Options: The Hidden Costs That Multiply Your Licence Bill

Database Options vs Base EE: The Pricing Structure

Oracle Database Enterprise Edition includes the core relational database engine, basic replication, and a limited set of built-in features. Everything beyond the base engine — partitioning, advanced analytics, high availability features, security features, management tools, and performance diagnostics — requires a separately purchased option or management pack. Oracle publishes a Technology Price List that lists individual option prices, and most options are priced at 20–100% of the base EE list price per processor.

This pricing model means that a fully optioned Oracle Database EE deployment — one that uses the features many enterprise DBAs consider standard — can cost three to five times the base EE processor price. A four-processor EE deployment at list price costs $190,000 in perpetual licences. Add Diagnostics Pack ($110,000), Tuning Pack ($110,000), Partitioning ($92,000), Advanced Security ($150,000), and Real Application Clusters ($230,000), and the total reaches nearly $882,000 — before annual support. This is not a hypothetical: it is the compliance exposure profile we routinely encounter in Oracle Audit Defence engagements for mid-size enterprise environments.

The critical distinction is between options that an organisation deliberately purchased and licensed versus options that were enabled inadvertently through standard database management activities. Oracle does not distinguish between deliberate and accidental usage in its audit claims — the LMS scripts identify usage, Oracle calculates the licence requirement, and the back-licence claim is issued regardless of intent. Understanding which options require licences is therefore a fundamental ITAM requirement for any organisation running Oracle Database EE.

Diagnostics Pack and Tuning Pack: The Default Trap

Oracle Diagnostics Pack and Oracle Tuning Pack are management packs that are enabled by default in Oracle Enterprise Manager (OEM). The Diagnostics Pack provides Automatic Workload Repository (AWR), Active Session History (ASH), and Automatic Database Diagnostics Monitor (ADDM). The Tuning Pack provides the SQL Tuning Advisor, SQL Access Advisor, and automatic SQL tuning. Both packs are priced at $11,000 per processor (list price, perpetual).

The trap is structural: Oracle Enterprise Manager Cloud Control's default configuration enables these packs via a global parameter called CONTROL_MANAGEMENT_PACK_ACCESS, which is set to "DIAGNOSTIC+TUNING" by default in Oracle Database 11g and later. When a DBA installs OEM and connects to Oracle Database instances, the management packs are active and generating usage data that Oracle's LMS scripts capture. A DBA who uses AWR reports to investigate a performance issue — a completely routine database administration task — is generating evidence of Diagnostics Pack usage that Oracle treats as requiring a separately purchased licence for every processor on which the database runs.

Disabling management pack access is possible by setting CONTROL_MANAGEMENT_PACK_ACCESS to "NONE" — but this disables fundamental OEM monitoring capabilities that DBAs depend on for performance management. Oracle's commercial model here is deliberate: the features are useful enough that DBAs enable them by default, creating a licence requirement that the business side of the organisation may not know about, and that Oracle can assert retroactively during an audit covering periods years in the past.

See our dedicated article on Oracle Diagnostics Pack licensing for a detailed breakdown of AWR, ASH, ADDM usage detection and how to challenge Oracle's findings where usage was incidental or inadvertent.

Partitioning Option: The Most Common Accidental Usage

Oracle Partitioning is a separately licensed database option priced at $23,000 per processor (list price, perpetual). It enables table and index partitioning — the ability to divide large tables into smaller, more manageable segments based on key values (range partitioning), lists (list partitioning), or hash values (hash partitioning). Partitioning is a performance optimisation and manageability feature that Oracle requires a separate licence for regardless of whether the partitioning is used for performance reasons or for data management purposes.

The accidental usage trap for Partitioning arises from Interval Partitioning — a partitioning feature introduced in Oracle 11g that automatically creates new partitions as data is inserted. DBAs who use Interval Partitioning for what they consider standard date-range table management (e.g., creating a monthly partition for log or audit data) are using the Partitioning option. Oracle's LMS scripts identify all uses of the $PART$ segment in the database dictionary as evidence of Partitioning option usage.

Reference Partitioning, System Partitioning, and Composite Partitioning are similarly chargeable. The key point is that any use of Oracle's Partitioning option — even a single partitioned table created by a DBA for routine administrative purposes — creates a Partitioning licence requirement for every processor on which that Oracle EE instance runs. In a four-processor environment, a single accidentally-partitioned table generates a $92,000 licence obligation (at list price, perpetual).

Remediating accidental Partitioning usage requires: identifying all partitioned objects in the database via the DBA_TAB_PARTITIONS, DBA_IND_PARTITIONS, and DBA_PART_TABLES views; assessing whether partitioning can be removed without performance or functional impact; implementing non-partitioned alternatives; and updating the DBA_FEATURE_USAGE_STATISTICS record to reflect current (not historical) usage. The last point is important: Oracle's LMS scripts capture the LAST_USAGE_DATE and DETECTED_USAGES columns from DBA_FEATURE_USAGE_STATISTICS, and if Partitioning was used even once the historical record will show detected usage. Our Audit Defence team challenges these findings by demonstrating that current usage is zero and negotiating the back-licence period.

In-Memory Database Option

Oracle Database In-Memory is an EE-only option that maintains a columnar in-memory copy of selected database objects to accelerate analytics and mixed workloads. It is priced at $23,000 per processor (perpetual list). The in-memory option is activated by setting the INMEMORY_SIZE database parameter to any non-zero value. When a DBA sets this parameter — even experimentally, even for a performance test that was never put into production — Oracle's LMS scripts record it as In-Memory option usage.

The In-Memory trap is particularly acute in environments that experimented with Oracle Database 12c or later performance features during a database upgrade evaluation. DBAs who set INMEMORY_SIZE during a proof-of-concept test and then reset it to zero may have generated LMS evidence of In-Memory usage that covers the test period. Oracle's position is that any enablement, regardless of duration or intent, constitutes usage requiring a licence.

Challenging In-Memory findings involves demonstrating that the INMEMORY_ENABLED attribute was set to DISABLED for all tables (even when the parameter was non-zero), that no data was actually loaded into the IM column store, and that the parameter was set for evaluation purposes with no production business benefit. These arguments reduce but may not eliminate Oracle's claim without skilled commercial negotiation.

Advanced Security Option

Oracle Advanced Security (OAS) is one of the most commonly cited options in Oracle audit findings, particularly since Transparent Data Encryption (TDE) — a key component of OAS — has become a compliance requirement under GDPR, PCI DSS, and HIPAA. OAS is priced at $15,000 per processor (perpetual list), and includes TDE, data redaction, Oracle Data Masking, network encryption (native network encryption is a separate matter), and various authentication features.

The critical point for many organisations is that TDE has been included in Oracle Database EE without an additional option licence since Oracle Database 12.2 in some contexts, but Oracle's licensing policy for TDE has been inconsistently communicated and is the subject of ongoing commercial disputes. Oracle's published technology price list and Oracle's T&Cs differentiate between "Transparent Data Encryption (TDE)" and the broader "Advanced Security Option" — but Oracle's LMS team has historically claimed that any TDE usage constitutes OAS usage regardless of this distinction.

Organisations that implemented TDE to meet regulatory requirements for encryption at rest — without purchasing the Advanced Security Option — should seek independent legal and licensing analysis before responding to any Oracle audit letter that cites OAS as a finding. The regulatory compulsion argument does not automatically create a safe harbour, but it can significantly influence the commercial settlement of an audit claim. Our Oracle Audit Defence service specifically handles TDE/OAS disputes and has successfully challenged Oracle's OAS claims in multiple regulatory environments.

Real Application Clusters Option

Oracle Real Application Clusters (RAC) is both Oracle's highest-value database option and the most commonly cited option in large audit back-licence claims. RAC enables multiple Oracle instances to share access to a single database running on shared storage, providing both horizontal scalability and high availability. The RAC option is priced at $23,000 per processor (perpetual list) in addition to the EE base licence — meaning a four-processor two-node RAC cluster requires eight EE processor licences ($380,000) plus eight RAC option licences ($184,000), for a perpetual list price of $564,000 before support.

RAC audit findings typically arise in three scenarios: organisations that inherited RAC deployments through acquisition without a full licence review; organisations that deployed Oracle SE2 in a cluster environment (prohibited as discussed in the SE2 article); and organisations that use Oracle Clusterware or Oracle Grid Infrastructure for reasons other than RAC (e.g., for standalone server management) but inadvertently enable RAC components. Our Compliance Review specifically checks for RAC Clusterware installations that may trigger unexpected licence requirements.

RAC licensing for virtualised environments is particularly complex: in VMware vSphere and similar environments, Oracle requires all physical sockets on all hosts that could run the RAC node VMs to be licensed. A two-node RAC cluster running as VMs across a four-host VMware cluster may require all processors on all four physical hosts to be licensed — a requirement that can multiply the RAC licence requirement by 4x compared to a native physical deployment.

How Oracle Detects Options Usage

Oracle's primary options detection mechanism is the DBA_FEATURE_USAGE_STATISTICS view — a dictionary view that Oracle Database automatically populates to record feature usage. This view tracks the first usage date, last usage date, and number of detected usages for every Oracle feature, option, and management pack that has ever been activated in the database. Oracle's LMS audit scripts query this view and export the results as part of the standard measurement package that Oracle requests organisations to submit during an LMS audit.

Key aspects of DBA_FEATURE_USAGE_STATISTICS that create audit exposure: the DETECTED_USAGES column counts every time Oracle internally samples feature usage (every seven days by default), so a feature that was enabled for six months and then disabled will show approximately 26 detected usages — creating evidence of a six-month licence obligation. The LAST_USAGE_DATE column shows when Oracle last observed the feature in use, which Oracle uses to determine the retrospective period of the back-licence claim. The CURRENTLY_USED column shows current status, which can be "FALSE" while LAST_USAGE_DATE shows historical usage — Oracle claims the licence obligation for the entire historical period regardless of current status.

Oracle also uses the USMM (Usage Statistics Management Metadata) tool in some audit contexts, and Oracle License Management Services has access to detailed technical analysis of collected data that goes beyond the raw DBA_FEATURE_USAGE_STATISTICS output. Options that show as "not used" in Oracle's own technical documentation may appear as "used" in LMS scripts due to the way Oracle's internal feature tracking counts background processes, automated jobs, and system-initiated operations.

The implication: organisations that disable options today are not protected from back-licence claims covering the period during which the options were enabled. The remediation strategy must include both disabling current usage and preparing a forensic challenge to Oracle's historical usage calculations.

Remediation: Disabling Options Without Business Disruption

The goal of options remediation is to eliminate future licence obligations for options that are not delivering business value, while preserving the operational capabilities that DBAs and applications depend on. Remediation must be approached methodically because disabling options can have immediate functional consequences for databases, applications, and monitoring infrastructure.

Management Pack remediation (Diagnostics and Tuning Packs): set CONTROL_MANAGEMENT_PACK_ACCESS to "NONE" at the database level. This disables AWR reports, ASH data collection, ADDM reports, SQL Tuning Advisor, and SQL Access Advisor within Oracle Enterprise Manager. Alternative: purchase Diagnostics Pack licences for production databases only and implement a policy that prevents management packs from being enabled on non-production environments. The second approach is commercially viable if only a subset of databases genuinely requires these features.

Partitioning remediation: identify all partitioned tables and assess whether they can be converted to non-partitioned objects. For interval-partitioned tables used for data lifecycle management, evaluate whether range partitioning with manual partition management (which still requires the Partitioning licence) can be replaced with other data archiving approaches. Consider PostgreSQL or other open-source databases for log, audit, or time-series workloads that are currently driving Partitioning usage in Oracle EE.

In-Memory remediation: set INMEMORY_SIZE to 0 at the database or CDB level and verify that no PDB-level override exists. Confirm via DBA_OBJECTS that no objects have INMEMORY attributes set. In-Memory disablement is operationally straightforward and rarely has application-level impacts since applications that truly depend on In-Memory performance will have that dependency surfaced in testing.

For organisations under active Oracle audit pressure, the remediation sequence matters: disabling options before submitting data to Oracle's LMS team allows the current compliance position to be demonstrated — but Oracle will still claim the historical usage period. Engage our Audit Defence team before submitting any LMS script output to Oracle. The data you submit defines the scope of Oracle's back-licence claim.