Advanced Compression is the option most likely to be in use without anyone deciding to use it. Here is every feature it gates, the backup and Data Guard paths people miss, and how to detect and remediate before an audit prices it for you.
Oracle Advanced Compression prices at 11,500 dollars per Processor and switches on through a single object attribute, a backup setting, or a Data Guard parameter. Here is every feature the option gates, the accidental paths in, and how to detect and remediate before an audit does.
Advanced Compression is the Oracle database option most likely to be in use without a single deliberate decision behind it. It prices at the scale of the database engine, and it is invoked by attributes, defaults, and settings scattered across DDL, backup jobs, and network files.
This guide maps every gated feature, the free lookalikes beside each one, the accidental paths in, and the detection and remediation sequence that closes the exposure. It follows the same discipline as our management pack guide, applied to the compression option.
Ten distinct feature families, not just table compression. Advanced Compression is an Enterprise Edition option, and the authoritative feature map is the licensing chapter of the Database Licensing Information User Manual. Most buyers know the first row of the table below and get caught by the other nine.
Two structural facts explain why this option, more than almost any other, produces findings. It is invoked by syntax that looks harmless, and it is priced at the same line as Partitioning, so the finding is never small. Understanding the feature map below is the whole defense.
The licensed feature map, feature by feature
| Licensed feature | How it gets invoked | Where usage shows |
|---|---|---|
| Advanced Row Compression | ROW STORE COMPRESS ADVANCED in DDL, formerly COMPRESS FOR OLTP | DBA_TABLES, feature usage view |
| Advanced LOB compression | COMPRESS on a SecureFiles column | DBA_LOBS |
| Advanced LOB deduplication | DEDUPLICATE on a SecureFiles column | DBA_LOBS |
| Advanced Index Compression | COMPRESS ADVANCED LOW or HIGH on an index | DBA_INDEXES |
| RMAN backup compression | Algorithm set to LOW, MEDIUM, or HIGH | RMAN configuration, feature usage view |
| Data Pump export compression | COMPRESSION=ALL or DATA_ONLY on expdp | Job parameters, feature usage view |
| Data Guard redo transport compression | COMPRESSION=ENABLE on an archive destination | Instance parameters |
| Advanced Network Compression | Compression directives in sqlnet.ora | Network configuration files |
| Heat Map and Automatic Data Optimization | HEAT_MAP parameter plus ILM policies | Instance parameters, ILM views |
| Flashback Data Archive optimization | OPTIMIZE DATA on a history archive | Archive definitions |
The free list matters as much as the licensed one, because the difference is often a single keyword in the same statement.
Advanced Compression exists only on Enterprise Edition. Standard Edition 2 cannot buy it, and a compressed attribute that travels into an SE2 database in a downgrade project is a configuration error to fix, not a license to purchase.
Cloud shapes change the answer too. Oracle's own cloud services bundle the option at certain service tiers, while a bring your own license move to another cloud carries the on premises entitlement question with it. Confirm which bundle you are on before paying twice.
Backup compression is the quiet one. A DBA copies a hardening guide, runs CONFIGURE COMPRESSION ALGORITHM 'MEDIUM', and every subsequent backup consumes the option on that database. The setting persists in the RMAN configuration and never announces itself.
Data Guard has two separate traps. Setting COMPRESSION=ENABLE on the redo transport destination requires Advanced Compression, and buyers regularly confuse that with Active Data Guard, which is a different option with its own 11,500 dollar line. A standby database must also mirror the primary's option licensing, so compression adopted on the primary prices both sites.
Compression is a property of objects and settings, not an installable product, so nothing stops an unlicensed database from using it. Whoever writes DDL, clones schemas, or copies configuration can commit the estate. The paths below account for nearly every accidental finding we have reviewed.
Replatforming is when attributes move unseen. The target estate goes live, the project team disbands, and the compression settings sit there until a feature usage sweep finds them. Post migration license verification, run in the week after go live, is the cheap control almost nobody schedules.
Running the DBMS_COMPRESSION advisor creates temporary compressed objects while it estimates ratios, and those runs can leave entries in the usage statistics. Oracle's own measurement scripts try to separate advisor activity from production use. Check which one you are looking at before conceding anything.
Every accidental path runs through change control someone owns. A one line review rule, that no compression clause ships without a license check, closes most of them. The same review gate is what keeps the Diagnostics and Tuning Pack traps shut, so build one gate for both.
White Paper · Oracle Database
Oracle Options & Management Packs
Why the options cost more than the database. Read it free.
Four dictionary views and one configuration check answer the question in an afternoon. Run them on every Enterprise Edition database, licensed for the option or not, and keep the dated output.
The detection sweep
| Where to look | What to check | Licensed signal |
|---|---|---|
| DBA_TABLES | COMPRESSION and COMPRESS_FOR columns | COMPRESS_FOR of ADVANCED or OLTP |
| DBA_INDEXES | COMPRESSION column | ADVANCED LOW or ADVANCED HIGH |
| DBA_LOBS | COMPRESSION and DEDUPLICATION columns | Any value other than NO or NONE |
| DBA_FEATURE_USAGE_STATISTICS | Rows naming compression features | Detected usages with recent dates |
| RMAN SHOW ALL | Configured compression algorithm | LOW, MEDIUM, or HIGH |
Sweep non production as well. Development and test databases are fully licensable environments in Oracle's model, and they are where compressed schemas usually appear first, cloned straight from production. A finding there prices in exactly the same way.
DBA_FEATURE_USAGE_STATISTICS records first usage date, last usage date, and a detected usages counter per feature per database. Those dates set the settlement window in a dispute, so never assert clean history without reading them first.
Oracle's auditors run the option usage measurement script from My Oracle Support, which maps raw feature rows to billable options. Run the same script yourself first. Matching Oracle's own tooling means no surprises in the closing meeting.
The view samples periodically, so a compressed object created and dropped between samples may not appear, while the object level views still would. Conversely, historic rows persist after remediation. There is no supported purge, which is why dated remediation evidence matters more than a clean query result.
List price is 11,500 dollars per Processor with 2,530 dollars of annual support, or 230 dollars per Named User Plus, as our annotated technology price list sets out. The option must be licensed on the same metric and quantity as the database it runs under, which is what turns one table into an estate number.
Timing matters as much as arithmetic. A compression finding surfaced inside a renewal negotiation becomes leverage against you on every other line. Surfaced by your own sweep a quarter earlier, it becomes a remediation memo nobody pays for.
Take a 16 core Intel server licensed for Enterprise Edition at a 0.5 core factor, so 8 Processor licenses. One compressed table there implies 8 option licenses: 92,000 dollars of license plus 20,240 dollars a year of support at list.
Now let that database live on a 3 node cluster licensed at 24 Processors, and the same single attribute implies 276,000 dollars plus support. Back support for the years since first usage date gets added on top of whatever is negotiated.
On a database licensed by Named User Plus, the option must be licensed by Named User Plus too, at the same user count and subject to the option's own per processor minimums. At 230 dollars per user that looks cheap until the minimums bite.
Mixed metric estates should model both routes before responding to a finding. Sometimes restating the affected database on the cheaper metric, where the contract allows it, changes the option bill more than any discount will.
With a three way decision per database: revert, license, or negotiate. The inventory you built in the detection sweep is what makes the decision honest, because it tells you whether the compression is earning anything.
The pattern for measuring, disputing, and pricing pack usage is the same one that governs compression, which is why the two reviews belong in the same quarter. One sweep, one evidence file, one negotiation posture.
Setting a table back to NOCOMPRESS stops future compression but leaves existing blocks compressed until the object is rebuilt. Do the rebuild, or an inspection still finds compressed data. Keep before and after evidence with dates, because the usage history itself cannot be erased.
Test the storage impact before a mass revert. Decompressed objects grow, and a schema that shrank by a third under compression needs that space back. Sequence big rebuilds through maintenance windows with the storage team in the room.
A note on evidence discipline: keep every sweep output, every revert script, and every rebuild log in one dated folder owned by the license manager, not the DBA team. When the audit letter arrives, the folder is the response, and assembling it calmly two years early beats reconstructing it under deadline.
Scope beats discount in a compression dispute. The three moves that consistently shrink the number: present the revert evidence with dates, hold the option quantity to the databases with genuine usage, and price back support from the documented first usage date rather than an assumed one.
Refuse the estate wide proposal politely and in writing. Oracle's opening position usually licenses every Enterprise Edition processor you own. Your inventory is the instrument that cuts it down to the databases where usage actually occurred.
The standard advice is to license Advanced Compression across the estate because compression is everywhere and an audit will find it. We disagree. In roughly three out of four estates we have swept, the licensed compression in use was set by accident, usually by a migration tool default, on objects where compression delivered little benefit. The buyer side move is to inventory every compressed object, revert accidental use where it adds no value, and license the option only on the databases where compression genuinely pays for itself. Paying estate wide for a setting a tool flipped is the most avoidable Oracle cost there is.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Nobody buys Advanced Compression. A migration tool buys it for them, one default attribute at a time, and the audit collects.
White Paper · Advisory
Oracle Database Options & Management Packs Licensing
The separately licensed options and packs that ship enabled by default, trigger on one click, and drive most Oracle audit findings: how feature usage is detected, prevented, and defended. Read it free.
An Enterprise Edition option listing at 11,500 dollars per Processor that gates ten feature families: advanced row, index, and LOB compression, deduplication, RMAN backup levels beyond BASIC, Data Pump export compression, redo transport compression, network compression, Heat Map, and Automatic Data Optimization.
Yes, several kinds. Basic table compression for direct path loads, index key compression, the RMAN BASIC backup algorithm, and metadata only Data Pump compression all cost nothing on Enterprise Edition. Hybrid Columnar Compression is free but only on Exadata class storage.
Only above the default. The BASIC algorithm is free, while configuring LOW, MEDIUM, or HIGH consumes the option on that database. Check RMAN SHOW ALL on every unlicensed database, because copied backup scripts carry the setting.
Yes, enabling compression on a redo transport destination requires it, and it is separate from Active Data Guard, which is its own priced option. The standby must carry the same option licenses as the primary.
Query DBA_TABLES, DBA_INDEXES, and DBA_LOBS for compression attributes, read DBA_FEATURE_USAGE_STATISTICS for dated usage rows, and check the configured RMAN algorithm. Together those five checks match what Oracle's own measurement script will find.
The option must match the database's licensed processors, so an 8 Processor database implies 92,000 dollars at list plus 20,240 dollars of annual support. Clusters multiply it, and back support runs from the first usage date.
Yes, and it is usually the right call. Revert the attributes, rebuild the objects so stored blocks decompress, and keep dated evidence. The usage history remains visible, so the documentation is what carries the argument.
No. In most estates we swept, the usage was accidental and delivered little benefit. Inventory first, revert what earns nothing, then license the narrow set of databases where compression genuinely pays.
Every option and pack licenses on the full processor count of the database beneath it, and the two cheapest switch on by default. The worked math and the strip and prove playbook.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
