Oracle Database In-Memory Licensing

Database In-Memory is one of the easiest options to enable by accident and one of the most expensive to license retroactively. A single initialisation parameter and one populated table are enough to register the feature, and because the parameter is sometimes set during proof of concept work or copied from a template, the usage appears on databases nobody intended to license. This article explains how the option is triggered, how it is licensed, and how a buyer side estate prevents an experimental setting from becoming a settlement. It sits under the database licensing pillar alongside the options and packs overview.

What is Oracle Database In-Memory?

Database In-Memory is an Enterprise Edition option that maintains a copy of selected tables, partitions, or columns in a compressed columnar format held in a dedicated area of memory called the In-Memory column store. Analytic queries that scan and aggregate large volumes of data run far faster against this columnar copy than against the traditional row format, while transactional queries continue to use the row store. The two formats are kept consistent automatically.

The benefit is dramatic acceleration of analytic and reporting workloads on the same database that serves transactions, removing the need to move data to a separate analytic system. That dual format capability is what Oracle charges for, and the option carries its own price line on top of the Enterprise Edition database, governed by the same full footprint rule as the Diagnostics and Tuning packs.

How the INMEMORY_SIZE parameter triggers the option

The option is controlled by the INMEMORY_SIZE initialisation parameter, which allocates memory to the column store. By default this parameter is zero, meaning the feature is inactive. Setting it to any non zero value allocates the column store, and populating an object into that store with the INMEMORY attribute is what records usage of the option. The combination of a non zero size and a populated object is the trigger.

This is deceptively simple. An administrator setting INMEMORY_SIZE during a proof of concept, a database cloned from a template that carries the parameter, or a developer marking a table INMEMORY to test performance, each crosses the line. The parameter looks like routine memory tuning, but it is the gateway to a chargeable option, in the same way that an Enterprise Edition only feature can be enabled without realising it crosses the boundary described in the Enterprise Edition article.

How Database In-Memory is licensed

Database In-Memory is licensed on the same metric as the database and for the same quantity. A Processor licensed database needs the option for the identical core count with the same core factor; a Named User Plus database needs it for the same user count under the Named User Plus minimums. Populating a single small table into the column store licenses the option across the entire database footprint.

As with every option there is no partial licensing. The scope is the database, not the populated object, which is why even a minimal test of the feature carries the full database cost.

The In-Memory base level and its limits

Oracle introduced an In-Memory base level intended to let customers use a limited amount of column store without the full option licence. The base level caps the column store at a small fixed size and disables several of the advanced In-Memory capabilities. It is narrow, version specific, and surrounded by conditions, so it must be configured exactly to Oracle's stated limits to stay within the free allowance.

The risk is that the base level is misconfigured, or that an object is populated beyond the permitted size, which silently moves the database back into chargeable territory. Relying on the base level requires the same contractual precision applied to the failover allowances: the exact wording and limits must be met and documented, not assumed. Treating the base level as a general right to use In-Memory for free is a misreading that collapses in an audit.

How does Oracle detect In-Memory usage?

Oracle reads the feature usage statistics views, which record Database In-Memory usage with first and last usage dates as soon as an object is populated into the column store. The setting of INMEMORY_SIZE and the population of objects are both visible to Oracle's review scripts. As with all options the database reports its own usage, so the finding rests on Oracle's instrumentation rather than on interpretation.

Because the trigger is so easy to hit during testing, In-Memory frequently appears in the usage history of non production databases, development copies, and proof of concept environments that were never meant to be licensed. These accidental records are exactly what the options audit surfaces, and they are difficult to dispute once the database has recorded them.

What Database In-Memory costs

The option is licensed for the full database core count, so the cost scales with the size of the database rather than the size of the column store. On a large multi processor database, licensing In-Memory across years of inadvertent usage with back support can be a significant settlement, particularly when the usage was a forgotten proof of concept that delivered no lasting value.

Where In-Memory is genuinely adopted for analytic acceleration, the economic comparison is against the cost and complexity of moving data to a separate analytic platform. That comparison often favours In-Memory, but it must be made deliberately with the option cost visible. Modelling that decision per database is the work the database licensing service brings to analytic architecture, and it should precede any production rollout.

How to contain In-Memory exposure

Containment starts with the parameter. On any database not licensed for the option, INMEMORY_SIZE should be zero and protected by configuration standards, so it cannot be set during tuning or carried in from a template. Database creation templates and clone sources should be audited to ensure they do not propagate a non zero setting. Developers should understand that marking a table INMEMORY is a licensing action.

The standing controls are scheduled queries of the feature usage views, configuration management that enforces a zero parameter on unlicensed databases, and a clear rule that any proof of concept involving In-Memory runs only on a database explicitly licensed or covered for the purpose. Where the base level is relied upon, its configuration must be documented against Oracle's exact limits. Catching usage early is far cheaper than the audit defence that follows discovery.

The buyer side view

The buyer side discipline on Database In-Memory is to treat a single initialisation parameter as a licensing control point. Keep INMEMORY_SIZE at zero on every unlicensed database, audit templates and clones so the setting cannot spread, and require any experiment with the feature to run on a database that is explicitly covered. Where the option delivers real analytic value, license it deliberately and justify it against the alternative of a separate analytic platform. Governed this way, a powerful accelerator never becomes an accidental liability. To model your own position, see the database pillar, the database licensing white paper, or request a consultation.