Oracle In-Memory Option Licensing & Hidden Triggers

What Is the Oracle In-Memory Option?

Oracle Database In-Memory, introduced in Oracle Database 12.1.0.2, stores selected tables, partitions, and materialized views in a compressed columnar format in a dedicated region of the System Global Area (SGA) called the In-Memory Column Store. Queries that scan large volumes of data run dramatically faster against the columnar copy, because the engine can skip irrelevant columns and use SIMD vector processing. It is a performance option aimed at analytics and reporting workloads running on the same database as transactional data.

The licensing trap is structural. Unlike a feature that requires a deliberate, visible action, In-Memory is armed by a single initialization parameter. A DBA evaluating whether In-Memory would help a slow report sets INMEMORY_SIZE, restarts the instance, and the column store is allocated. Nothing warns them that the option is unlicensed, and the database does not refuse to start. Oracle's playbook relies on this: the easier an option is to enable without thinking, the larger the eventual back-license claim.

What Triggers the Oracle In-Memory Option License?

The option is licensed per processor on the same metric and footprint as the underlying Enterprise Edition database. The following actions each create a license requirement, and several of them happen without any explicit decision to "use In-Memory":

• Setting INMEMORY_SIZE above zero: The single most common trigger. Allocating the column store is recorded as feature usage even with no objects marked INMEMORY.
• Marking an object INMEMORY: Using ALTER TABLE ... INMEMORY on a table, partition, or materialized view triggers the option independently of the parameter at the segment level.
• In-Memory aggregation (VECTOR GROUP BY): Queries that invoke the In-Memory aggregation optimization use the option.
• In-Memory expressions and virtual columns: Materializing computed expressions into the column store is option usage.
• In-Memory on Active Data Guard standby: Allocating a column store on a standby database requires the In-Memory option on the standby's processors, in addition to the Active Data Guard option.

Licensing follows the Oracle Core Factor Table: physical cores multiplied by the applicable core factor (typically 0.5 on x86) give the processor count to license. There is no minimum size threshold above the Base Level and no grace period. Our Oracle compliance review measures which databases have a non-zero INMEMORY_SIZE before Oracle's LMS team does.

Is the 16GB In-Memory Base Level Really Free?

Oracle introduced the In-Memory Base Level in 19c to let customers try In-Memory at small scale without buying the option. The Base Level is genuinely free, but it comes with strict guardrails that are easy to miss. INMEMORY_FORCE must be set to BASE_LEVEL, and INMEMORY_SIZE must not exceed 16GB. If a DBA sets INMEMORY_SIZE to, say, 32GB without setting INMEMORY_FORCE to BASE_LEVEL, the database is using the full option and the Base Level protection does not apply. The 16GB limit is also per-instance, and the Base Level is explicitly excluded on Oracle Engineered Systems such as Exadata.

In audit practice, the Base Level is both a defense and a trap. It is a defense where a customer genuinely configured INMEMORY_FORCE = BASE_LEVEL and stayed under 16GB — in that case no option license is owed and the claim should be rejected. It is a trap where a customer assumed "under 16GB means free" without setting the parameter, because Oracle will treat the unguarded allocation as full option usage. Establishing exactly how the parameters were configured is central to defending an In-Memory claim — see our Oracle audit defense guide for how parameter-level evidence is used.

How Much Does the Oracle In-Memory Option Cost?

The list price is the basis Oracle uses for back-license settlements, and it is rarely discounted in an audit context. The table below shows In-Memory cost at list across common Intel x86 deployments using the 0.5 core factor, including the multi-year back-license claim Oracle constructs once it establishes a first-use date from the feature-usage history.

Oracle applies a 22% annual support uplift on top of the base back-license value and calculates the claim from the first date In-Memory was used. In our engagements, roughly half of In-Memory option claims trace to a non-production database where a DBA tested the feature and never reset INMEMORY_SIZE to zero (Oracle Licensing Experts benchmark, 2026). That pattern — a test that was never unwound — is frequently the strongest basis for narrowing scope and challenging the back-license period. Our Oracle audit defense service works the parameter and feature-usage evidence to reduce these claims.

How Does Oracle LMS Detect In-Memory Usage?

Detection is more certain than for almost any other option, because the trigger is a visible parameter rather than buried usage. The USMM and Review Lite scripts capture In-Memory from several sources and correlate them. The representative queries below show what the LMS team runs:

-- In-Memory Column Store size (the primary trigger)
SELECT name, value FROM v$parameter
WHERE name IN ('inmemory_size','inmemory_force');

-- Objects currently populated in memory
SELECT owner, segment_name, segment_type, bytes_in_mem
FROM v$im_segments;

-- Objects marked INMEMORY at the table level
SELECT owner, table_name, inmemory, inmemory_priority
FROM dba_tables WHERE inmemory = 'ENABLED';

-- Historical feature activation with first-use date
SELECT name, detected_usages, first_usage_date, last_usage_date
FROM dba_feature_usage_statistics
WHERE name LIKE 'In-Memory%';

The decisive view is DBA_FEATURE_USAGE_STATISTICS, populated by DBMS_FEATURE_USAGE_STATISTICS. It records the first and last dates In-Memory was used and is not reset by setting INMEMORY_SIZE back to zero. This is why post-audit remediation reduces ongoing liability but cannot erase the historical record. V$OPTION additionally reports whether In-Memory is installed and enabled at the instance level, independent of segment-level population.

Where Does In-Memory Option Exposure Hide?

Based on our forensic compliance reviews across hundreds of enterprise estates, the following scenarios are the most common sources of undiscovered In-Memory exposure.

Abandoned proof-of-concept testing: The classic case. A DBA enables In-Memory on a development or staging database to benchmark a slow report, sees the improvement, files it away as "something to consider," and never resets INMEMORY_SIZE. Months later the parameter is still non-zero and the feature-usage history is accumulating.

Templated database builds: Where a gold-image or DBCA template was created with INMEMORY_SIZE set, every database provisioned from that template inherits the parameter. A single misconfigured template can propagate In-Memory exposure across dozens of databases without anyone deciding to use the feature.

Cloned production-to-test refreshes: When a production database that uses In-Memory is cloned to build test or QA copies, the parameter and the INMEMORY object attributes travel with it. Non-production environments require the option on the same basis as production.

Cloud and Exadata migrations: In-Memory is included differently across Oracle Cloud Infrastructure and Exadata. Workloads migrated from OCI or Exadata to standard on-premises Enterprise Edition servers carry the In-Memory dependency with them — a trap our cloud advisory team sees repeatedly, and the Base Level is unavailable on Engineered Systems.

Mergers and acquisitions: Acquired databases arrive with unknown parameter histories. Oracle's LMS team targets recently acquired companies, anticipating unlicensed options. Quantifying In-Memory exposure before close is part of any disciplined Oracle database licensing due-diligence process.

How Do You Remediate or Right-Size In-Memory Exposure?

If a compliance review reveals In-Memory exposure and buying the option is not the preferred outcome, remediation is technically simple but the evidence handling is what matters. The right path depends on whether an audit letter has already arrived.

1. Inventory every database: Check INMEMORY_SIZE and INMEMORY_FORCE on every instance — production, standby, test, dev, and DR — and pull first-use dates from feature-usage statistics. Identify any object carrying the INMEMORY attribute.
2. Reset the parameter where unused: On databases where In-Memory was enabled but is not genuinely needed, set INMEMORY_SIZE to zero and remove INMEMORY attributes from objects, then restart at the next maintenance window.
3. Apply the Base Level where small-scale use is wanted: Where up to 16GB of column store delivers the value, set INMEMORY_FORCE = BASE_LEVEL and keep INMEMORY_SIZE within 16GB to use In-Memory legitimately without the option — but never on Engineered Systems.
4. Consolidate genuine In-Memory workloads: Concentrate workloads that truly need full In-Memory onto a smaller, fully licensed footprint so the option is licensed only where required — right-sizing rather than estate-wide licensing.
5. Document the remediation date: Save query output proving INMEMORY_SIZE is zero (or Base Level) with timestamps. This evidence narrows the back-license window if Oracle later references historical usage.

The evidence question is decisive. Oracle's scripts measure current state, but DBA_FEATURE_USAGE_STATISTICS retains the historical first-use date — so remediation before any audit measurement eliminates current exposure, while remediation after an audit letter reduces future liability without erasing the historical claim. If you genuinely need In-Memory at scale, the option is often worth licensing within an Oracle contract negotiation or ULA, where the incremental cost of bundling In-Memory is far lower than a standalone back-license settlement. Our case studies document multi-million-dollar reductions achieved by combining remediation with negotiation leverage, and our license optimization service right-sizes the option footprint across the estate.

Frequently Asked Questions