Oracle Advanced Compression Licensing
Advanced Compression is a separately licensed Enterprise Edition option that enables OLTP table compression, advanced row and index compression, RMAN backup compression, Data Pump compression, and network compression. Basic table compression for direct path loads is free, but the moment any Advanced Compression feature is used the option must be licensed for every core on the database at the same metric as the database itself.
Advanced Compression is a classic example of an option that delivers genuine storage savings while quietly creating a licence liability across an entire database. The features are easy to enable, several are switched on by well meaning storage optimisation projects, and the usage record is permanent. This article sets out exactly what the option covers, what compression remains free, and how a buyer side estate keeps the option from becoming an audit finding. It sits under the database licensing pillar and belongs with the options and packs overview.
What is Oracle Advanced Compression?
Advanced Compression is an Enterprise Edition option that bundles a family of compression and storage efficiency capabilities. The headline feature is OLTP table compression, which compresses data during normal insert and update activity rather than only during bulk loads. The bundle also includes advanced index compression, RMAN backup compression at the higher levels, Data Pump export compression, Data Guard redo transport compression, and heat map and automatic data optimization in some database releases.
The value proposition is storage reduction and improved cache efficiency, which translates into hardware and backup savings. That value is precisely what Oracle prices, and the option carries its own line on the price list on top of the Enterprise Edition database and any other options in use, following the same all or nothing footprint rule as the Diagnostics and Tuning packs.
What compression is free versus licensed?
The free capability is basic table compression, sometimes called direct path or bulk load compression, which compresses data only when it is loaded through a direct path operation and does not maintain compression on subsequent conventional inserts and updates. This is included with Enterprise Edition at no option cost and is appropriate for read mostly data warehouse tables loaded in bulk.
Everything beyond that basic capability requires the option. The moment compression is maintained during normal OLTP activity, or any of the bundled features such as backup or network compression is used, Advanced Compression is in play. The line is narrow and easy to cross without noticing, much like the Enterprise versus Standard boundary covered in the Standard Edition licensing article.
| Capability | Free with EE | Advanced Compression |
|---|---|---|
| Basic compression on direct path load | Included | Not required |
| OLTP compression maintained on insert and update | Not available | Requires the option |
| RMAN backup compression at higher levels | Low level only | Requires the option |
| Data Pump and network compression | Not available | Requires the option |
Which features the option covers
The option's breadth is what makes it dangerous. It is not a single feature an administrator turns on deliberately, but a family of capabilities that surface across storage, backup, and replication work. A database administrator compressing a backup to save space, a developer enabling OLTP compression on a busy table, and a Data Guard configuration using redo compression are three different teams, each capable of triggering the same option charge independently.
This breadth means Advanced Compression usage frequently appears on databases where no one believes the option is in use, because the trigger came from a backup script or a replication setting rather than a deliberate compression project. Tracing the source of usage is part of the wider options audit discipline, where multiple options surface together from the same feature usage views.
How does Oracle detect Advanced Compression usage?
Oracle reads the feature usage statistics views, which record each Advanced Compression feature separately with first and last usage dates. OLTP compression, backup compression, and the other bundled capabilities each appear as distinct entries, so an audit can see not just that the option was used but which feature triggered it and when. This granularity makes the finding hard to dispute, because the database itself reports the specific feature and date.
The permanence of the record is the trap. A one off compressed backup taken two years ago still shows in the usage history, and Oracle's scripts will report it as option usage regardless of whether compression is in use today. This is the same detection mechanism that governs the Enterprise Edition option set as a whole.
What Advanced Compression costs
The option is licensed for the full database footprint on the same metric as the database, whether Processor or Named User Plus, calculated with the same core factor. The cost therefore scales with the core count of the database, not with the volume of data compressed. Compressing a single table on a large multi processor database licenses the option across every core.
The irony is that the option is bought to save storage cost, yet retroactive licensing in an audit can dwarf the storage savings many times over. A buyer side estate weighs the storage benefit against the full option cost across the database before enabling any chargeable feature, the same way it weighs every option in the options catalogue.
Key findings
- 1Basic direct path compression is free; OLTP and bundled compression require the option.
- 2The option is a family of features, triggerable by storage, backup, and replication teams independently.
- 3Each feature is recorded separately and permanently in the feature usage views.
- 4The option is licensed for the full database core count, not the volume of data compressed.
Where hidden compression usage comes from
The most common hidden source is backup compression, where an RMAN configuration set to a higher compression level uses the option without anyone associating a backup setting with a database licence. The second is Data Guard redo transport compression, enabled to save bandwidth on a slow network link between sites. The third is OLTP compression applied during a storage reclamation project, often by a storage team rather than the database team.
Each of these is a different team solving a different problem, and none of them is thinking about option licensing. Catching the usage requires monitoring the feature views centrally rather than relying on any one team to flag it. The same cross team blind spot drives accidental usage of the disaster recovery related options.
How to contain Advanced Compression exposure
Containment combines monitoring with configuration standards. The estate should query the feature usage views on a schedule so any new compression usage is detected quickly, and backup, replication, and storage standards should explicitly state which compression levels and features are permitted on unlicensed databases. RMAN scripts in particular should be reviewed to ensure they do not default to a chargeable compression level.
Where the option is genuinely wanted for its storage benefits, it should be licensed deliberately on the databases that need it, and those databases isolated so the usage does not spread through cloning. Modelling the storage saving against the option cost, and deciding per database, is the work the database licensing service brings, and it is far cheaper than reconstructing the history under audit defence.
The buyer side view
The buyer side position on Advanced Compression is to govern it as a multi headed option rather than a single feature. Standardise backup and replication configurations so they cannot quietly invoke a chargeable level, monitor the feature usage views continuously across every team that touches the database, and license the option deliberately only where the storage benefit justifies the full database cost. Treated as a standing control, the option delivers real savings where paid for and never becomes a surprise. To model your own exposure, begin with the database pillar, the database licensing white paper, or request a consultation.
Common questions.
Is table compression free in Oracle Enterprise Edition?
Basic table compression for direct path bulk loads is free with Enterprise Edition. It compresses data only at load time and does not maintain compression on subsequent conventional inserts and updates. OLTP compression, which maintains compression during normal activity, and all other bundled compression features require the separately licensed Advanced Compression option.
Does RMAN backup compression need Advanced Compression?
Higher level RMAN backup compression requires the Advanced Compression option. A basic low level compression is available without the option, but the more effective compression levels are chargeable. Many estates trigger the option inadvertently through an RMAN configuration set to a higher level, and the usage is recorded permanently in the feature usage views.
How is Advanced Compression licensed?
Advanced Compression is licensed on the same metric as the underlying database, Processor or Named User Plus, and for the same quantity calculated with the same core factor. There is no partial licensing, so using any chargeable compression feature requires the option across the full database core count regardless of how much data is compressed.
How does Oracle detect Advanced Compression usage?
Oracle reads the database feature usage statistics views, which record each Advanced Compression feature separately with first and last usage dates. OLTP compression, backup compression, and network compression each appear as distinct entries, so an audit can identify the specific feature and date that triggered the option, making the finding difficult to dispute.