Some Oracle features are included with Enterprise Edition. Others sit a parameter away and carry a separate licence at full list price. The two kinds look identical from inside the database, behave identically in a query plan, and appear side by side in the same documentation. That is the trap. The feature line is the boundary between what you already paid for and what an audit will say you owe, and Advanced Compression and Database In Memory are two of the most common places that line gets crossed without anyone noticing.
Is Advanced Compression a separate licence?
Advanced Compression is a separately licensed option on top of Enterprise Edition, while basic table compression is included at no extra charge. The distinction is sharp and easy to miss. Basic compression covers direct path bulk loads. The moment a workload uses advanced row compression for ordinary transactional changes, or any of the option's other capabilities such as advanced index or backup compression, it has stepped over the line into priced territory. Nothing in the syntax warns you. A storage administrator chasing a capacity target can enable the priced behaviour believing they used a standard feature.
This is why compression findings are so common. The benefit is real and the temptation is obvious: less storage, faster backups, lower cost on paper. The licensing cost arrives later, when the feature usage views show the option was active across a set of processors and the finding values every one of them at list. The capability did its job. The contract simply never covered it.
Does Database In Memory cost extra?
Database In Memory is a separately licensed option, and it can be switched on by setting a single initialization parameter to a non zero value. That is all it takes. An engineer testing whether a reporting query runs faster sets the in memory area size, runs the test, and moves on. The parameter stays set. The column store populates. The feature usage views record that Database In Memory was used, and the configuration sits quietly until an audit reads those views and prices the option across the server.
The mechanics make this one of the cleanest examples of accidental exposure in the whole database. There is no installer to run, no separate component to deploy, no obvious moment of decision. The option is present in the binary and waiting for the parameter. Oracle's own position is that usage is usage, and the feature usage statistics are the record that decides it. The buyer's defence has to start from those same views, not from anyone's memory of what they intended.
A finance reporting database shows Database In Memory and Advanced Compression both flagged as used in the feature usage views. The opening finding prices each option across all twelve processors on the host. A review establishes that the In Memory parameter was set during a two week proof of concept eighteen months earlier and never used in production, and that the compression in play was the included basic type on a bulk load, not the advanced option. The parameter is reset, the compression type is documented, and the finding for both options falls away, removing the largest single line in the audit.
Where exactly does the feature line sit?
The feature line sits between capabilities bundled into Enterprise Edition and the named options and management packs that carry their own licence, and the only authoritative map of it is your contract read against Oracle's options and packs documentation. Included territory covers a great deal: the core engine, basic compression, standard partitioning of the data dictionary, and much of day to day administration. Priced territory covers the options such as Advanced Compression, Database In Memory, Partitioning, Advanced Security, Real Application Clusters, and the Diagnostics and Tuning management packs, where a single Enterprise Manager click can trigger Diagnostics or Tuning Pack usage.
What makes the line hard to hold is that priced features are installed and ready by default. Many options ship enabled in the binary, so the boundary is enforced by discipline rather than by the software refusing to run. That design puts the responsibility on the customer to know where the line is and to stay on the right side of it. An estate without a feature governance habit drifts across the line one well meaning change at a time, and the drift only becomes visible when the audit reads the usage views.
How do you defend a compression or In Memory finding?
You defend a compression or In Memory finding by separating genuine, deliberate production use of the priced option from incidental, test, or misidentified usage, and then correcting the processor base the finding was priced against. Pull the feature usage views yourself and read them carefully. Distinguish an option that was briefly enabled and abandoned from one woven into production. Check whether an included feature, such as basic compression, actually covers the activity that was flagged. Confirm which processors truly ran the option rather than accepting the whole host.
Each of these moves shrinks the finding, and the priced options are where the largest reductions live because list prices are high and accidental usage is common. An independent line by line review of Oracle findings typically cuts a claim 60 to 80 percent, and option findings are a major part of that, since so many are switched on without intent and switched off again once identified. The contract decides what was licensed, the usage views decide what ran, and the gap between them is the only thing you should ever pay for.
If a finding has landed and the options column is doing the damage, the next step is to have it read by someone who does this for a living. See detecting accidentally enabled options and disputing options enabled but never used for the detection and dispute mechanics, and the full method in the Oracle database licensing guide.