Oracle Database In-Memory Option Licensing

What Is Oracle Database In-Memory?

Oracle Database In-Memory, introduced in Oracle Database 12c Release 1 (12.1.0.2), provides a dual-format in-memory columnar store that runs alongside the traditional row-based buffer cache. The column store allows analytical queries — aggregations, range scans, and joins over large data sets — to execute directly against in-memory columnar data rather than reading row-format data from disk or the row cache. The performance improvement for analytical query patterns can be dramatic: Oracle reports typical speed improvements of 100× or more for the right workload types.

The In-Memory option uses the INMEMORY_SIZE initialisation parameter to allocate memory for the column store. By default, INMEMORY_SIZE is set to 0, meaning the column store is disabled. However, the option can be activated through a simple parameter change or through the INMEMORY attribute applied to individual tables, tablespaces, or materialised views. The ease of activation is precisely what makes this option a frequent inadvertent compliance issue: a DBA or developer experimenting with performance can activate the In-Memory column store with a single command, and Oracle's audit scripts will record that activation from the moment it occurs.

Licensing Cost and Metrics

Database In-Memory is an Enterprise Edition option, available only on Oracle Database Enterprise Edition. It is priced at $23,000 per processor or $460 per Named User Plus. The NUP minimum rule applies: if your deployment is processor-licenced, you need In-Memory option licences for every processor in the deployment. There is no partial licensing of an option for a subset of processors — once the option is in use on a server, all processors on that server must be covered.

Annual support for the In-Memory option follows the standard Oracle support structure: 22% of the net licence fee in year one, increasing by 8% per year thereafter. For a 12-processor deployment, the first-year perpetual licence cost for the In-Memory option alone is $276,000, with first-year support adding a further $60,720 — increasing to $65,577 in year two, $70,823 in year three, and so on. The cumulative 5-year cost of the option (perpetual plus support) for a 12-processor deployment exceeds $400,000 at list prices.

In practice, Oracle's options are negotiable. List prices represent the ceiling, not the floor, and experienced Oracle negotiators typically secure meaningful discounts on options purchased as part of broader commercial conversations. However, the discounted price is still substantial, and options that are licenced reactively — in response to an audit finding rather than proactively — are rarely discounted because Oracle holds the commercial leverage in that situation. See our EE options pricing and audit guide for the broader context.

The Accidental Activation Risk

The most significant compliance risk with the In-Memory option is accidental activation. Several common scenarios create this risk:

• Parameter experimentation: DBAs testing the performance impact of the In-Memory column store may set INMEMORY_SIZE to a non-zero value and apply the INMEMORY attribute to one or more tables. Even brief experimental use creates a DBA_FEATURE_USAGE_STATISTICS record that Oracle's audit scripts will detect. The fact that the parameter was later reset to zero and the INMEMORY attribute removed does not eliminate the historical record.
• Third-party application configuration: Some third-party applications that run on Oracle Database — including SAP applications on Oracle — may configure INMEMORY attributes as part of their installation or tuning scripts. Organisations running SAP on Oracle should verify that their SAP landscape has not activated the In-Memory option through its own configuration procedures without a deliberate licensing decision being made.
• Default configurations in newer Oracle versions: From Oracle Database 12.1.0.2 onward, the In-Memory infrastructure is present in the database kernel regardless of whether INMEMORY_SIZE is set to zero. Some third-party tools and DBAs have reported that certain operations can inadvertently populate In-Memory usage statistics even without an explicit activation. Organisations should run internal DBA_FEATURE_USAGE_STATISTICS queries to verify the current usage status of the In-Memory option before assuming it has never been activated.

RAC Environments and Per-Node Licensing

In a Real Application Clusters (RAC) environment, the In-Memory option must be licenced for every processor on every node in the RAC cluster. If the In-Memory column store is activated on even one node of a four-node RAC cluster, all processors on all four nodes must be covered by the In-Memory option licence. This is consistent with Oracle's standard rule that options must be licenced for all processors in the deployment, but it has a particularly amplified cost impact in large RAC clusters.

A four-node RAC cluster with 8 processors per node (32 processors total) where the In-Memory option is activated incurs an In-Memory option perpetual licence requirement of $736,000 at list price — before accounting for any other options or the base EE database licence. In RAC deployments, the cost impact of an unlicensed In-Memory finding in an Oracle audit can be substantial enough to make the audit outcome commercially determinative rather than just a compliance correction.

How Oracle Detects In-Memory Usage

Oracle's LMS audit scripts query DBA_FEATURE_USAGE_STATISTICS for the "In-Memory Column Store" feature. This view records the first time the feature was detected as used, the last time it was used, and a usage count. Oracle's scripts also look for non-zero INMEMORY_SIZE settings in the database initialisation parameters, and for any tables, tablespaces, or materialised views that carry the INMEMORY attribute — even if those attributes are currently set to INMEMORY NO (which disables In-Memory for a specific object but still registers as usage of the feature infrastructure).

This creates a technical nuance: applying INMEMORY NO to an object — which is sometimes done to explicitly exclude it from the column store — can itself be treated as evidence of In-Memory option usage by Oracle's audit methodology. Organisations that have applied INMEMORY attributes to any database objects (even to disable In-Memory for those objects) should consider that this may be surfaced in an audit and seek independent advice on how Oracle would likely treat it.

Governance Controls for In-Memory Compliance

Preventing inadvertent In-Memory activation requires a combination of technical controls and governance processes. For databases where the In-Memory option is not licenced, consider implementing a database trigger or policy that prevents INMEMORY_SIZE from being set to a non-zero value without explicit DBA approval, and that prevents INMEMORY attributes from being applied to any object without a licensing review. These controls are not technically enforced by Oracle — you must implement them yourself.

From a governance perspective, the following processes reduce In-Memory compliance risk. First, run a quarterly check of DBA_FEATURE_USAGE_STATISTICS across all EE databases to verify In-Memory is not recorded as used on any database where it is not licenced. Second, maintain a register of all Oracle Database options licenced per deployment, updated whenever a new deployment is created or an existing one changes. Third, require explicit licensing sign-off before any performance tuning activities that involve the INMEMORY_SIZE parameter or INMEMORY attributes. Fourth, brief all DBAs — including contractors and third-party application support teams — on the licensing implications of activating Oracle EE options.

If an internal compliance review reveals that the In-Memory option has been used without a licence, seek independent advisory advice before taking any action. How you present this finding, and in what commercial context, significantly affects the outcome. Redress Compliance has advised clients on In-Memory licence exposures ranging from single-server deployments to multi-node RAC clusters, and we consistently achieve better outcomes when we control the framing of the disclosure rather than allowing Oracle to define it through an audit finding. Contact our Oracle advisory team for a confidential discussion.