Oracle Advanced Compression Option Licensing

What Is the Oracle Advanced Compression Option?

Oracle Advanced Compression is a separately licensed option for Oracle Database Enterprise Edition that bundles a family of compression and storage-efficiency features designed for live, transactional data rather than just bulk-loaded archives. It exists because Oracle reserves the more capable compression — the kind safe to run on tables that are constantly updated — behind a paid licence, while leaving the simpler bulk-load compression free.

The option covers Advanced Row Compression (formerly OLTP Table Compression), Advanced LOB Compression and Deduplication for SecureFiles, advanced RMAN backup compression, Data Pump compression of exported data, Advanced Network Compression for Data Guard redo and client traffic, and the Information Lifecycle Management features Heat Map and Automatic Data Optimization. It is one entry in Oracle's broader paid-option portfolio alongside Partitioning and Advanced Security — see the full landscape in our Oracle database options licensing guide.

Which Oracle Compression Is Free vs Paid?

The distinction that catches people is between Basic and Advanced row compression. Basic Table Compression only compresses data loaded through direct-path operations such as INSERT /*+ APPEND */ or CREATE TABLE AS SELECT; rows inserted by ordinary DML are stored uncompressed. Advanced Row Compression maintains compression through normal OLTP inserts and updates — which is exactly why it is valuable, and exactly why Oracle charges for it.

Hybrid Columnar Compression deserves a specific warning. The feature itself is not part of the Advanced Compression option, but its free use is restricted to Oracle-engineered storage. Enabling HCC on a database running on third-party storage is both technically blocked in normal configurations and a licensing concern where workarounds exist. Our Exadata licensing guide explains how compression entitlements travel with the platform.

What Triggers the Advanced Compression License?

The licence requirement attaches on first use of any feature in the option, on every processor running the database — not just the segment or backup that used it. The most common triggers we see in compliance reviews are:

• Application schema defaults: ERP, data warehouse, and packaged applications increasingly ship table definitions with ROW STORE COMPRESS ADVANCED baked in. The customer holds the licence obligation, not the application vendor — exactly as with partitioned objects.
• DBA storage optimisation: A DBA compresses a large history table with OLTP compression to reclaim space. A single ALTER TABLE … COMPRESS FOR OLTP against one table switches on the option for the whole database.
• Backup window pressure: Turning on RMAN MEDIUM or HIGH compression to fit backups into a shrinking window is a near-universal habit — and a paid trigger that LMS reads straight from feature-usage history.
• SecureFiles LOBs: Enabling COMPRESS or DEDUPLICATE on SecureFile LOB columns, often set by application installers handling documents or images, invokes Advanced LOB Compression.
• ILM Heat Map: Setting HEAT_MAP=ON to track data access for tiering enables an Advanced Compression feature even before any Automatic Data Optimization policy compresses anything.

None of these produces an error or a prompt. This is the defining trait of an accidental-use option, and it is why we treat compression the same way we treat Diagnostics and Tuning packs in a compliance review — assume it is on somewhere until the feature-usage data proves otherwise.

Does RMAN Backup Compression Need the Option?

This single distinction generates a meaningful share of compression claims. DBAs reach for MEDIUM because it offers the best ratio-versus-CPU trade-off for backups, and the syntax to enable it — CONFIGURE COMPRESSION ALGORITHM 'MEDIUM' — looks no different from any other RMAN configuration. The fix during remediation is straightforward where the option is not otherwise needed: revert to 'BASIC' and document the change. Removing the trigger does not erase historical usage, but it stops the meter and supports a narrower claim. The Oracle database licensing guide covers the backup-and-recovery options buyers most often confuse.

How Much Does Advanced Compression Cost in 2026?

Oracle Advanced Compression is priced per processor at approximately $11,500 at list, or under Named User Plus licensing subject to per-processor user minimums. As with every database option, it is additive to the Enterprise Edition base licence of approximately $47,500 per processor, and processors are derived from the Oracle Core Factor Table.

The three-year figures apply Oracle's standard 22% annual support uplift compounding across the back-license period — the same mechanism that turns a modest option into a large settlement number. Negotiated discounts of 40–60% off list are routine on net-new option purchases, which is why proactively licensing or removing compression before an audit is almost always cheaper than settling a claim. Our license optimization service models whether to license, remediate, or fold the option into a broader contract negotiation.

How Does Oracle LMS Detect Advanced Compression Usage?

Oracle's License Management Services team detects Advanced Compression with two complementary techniques. The first is feature-usage tracking: DBA_FEATURE_USAGE_STATISTICS records named features such as "Advanced Row Compression", "Backup HIGH Compression", "Backup MEDIUM Compression", "HeatMap", "SecureFile Compression (user)", and "Data Guard" network compression, along with a usage count and first-/last-used dates. The second is a direct inventory: the COMPRESS and COMPRESS_FOR columns in DBA_TABLES, DBA_TAB_PARTITIONS, and DBA_TAB_SUBPARTITIONS reveal exactly which segments are compressed and how.

-- Which Advanced Compression features were used, and when?
SELECT name, detected_usages, first_usage_date, last_usage_date
FROM   dba_feature_usage_statistics
WHERE  name IN ('Advanced Row Compression',
                'Backup MEDIUM Compression',
                'Backup HIGH Compression',
                'Backup LOW Compression',
                'HeatMap',
                'SecureFile Compression (user)');

-- Which table segments are compressed, and how?
SELECT owner, table_name, compression, compress_for
FROM   dba_tables
WHERE  compression = 'ENABLED'
AND    compress_for IS NOT NULL;

Because feature-usage statistics persist the first-usage date, Oracle can propose a back-license period from that timestamp. The same data is your evidence base for narrowing it. For the wider script catalogue and what the USMM scripts capture, see our guide to Oracle LMS audit scripts.

How Do You Remediate Accidental Compression Usage?

If a review finds compression switched on and licensing is not the preferred outcome, remediation is achievable but must be deliberate. Unlike a setting you can toggle, compressed data stays compressed until the segment is rebuilt, and feature-usage history persists. The practical sequence is:

1. Inventory every trigger. Identify all compressed segments (COMPRESS_FOR), every backup configuration using a paid algorithm, SecureFile compression/deduplication, and any Heat Map or ADO policy in force across production and non-production.
2. Decompress segments. Rebuild affected tables and partitions with MOVE … NOCOMPRESS or ROW STORE COMPRESS BASIC where bulk-load compression is acceptable, validating row counts and rebuilding dependent indexes.
3. Revert backups and exports. Reset RMAN to ALGORITHM 'BASIC' and remove COMPRESSION=ALL/DATA_ONLY from Data Pump jobs.
4. Disable ILM features. Turn off Heat Map and drop ADO policies.
5. Validate and document. Re-run the detection queries to confirm no current paid usage remains, and retain the output and change dates as evidence.

Remediation before any audit measurement removes current exposure. After an audit letter arrives, it reduces ongoing liability but does not erase historical usage Oracle can read from feature-usage history — which is why timing and sequencing matter, and why we run remediation under audit defence rather than in isolation.

How Do You Defend an Inflated Compression Claim?

Advanced Compression claims are frequently larger than the customer owes, and the same disciplines that work on other database options apply here. Processor count is the first lever: misapplied core factors, counted hyperthreads, and decommissioned hosts inflate the base before the option is even priced. Feature precision is the second: LMS sometimes claims the full option where only a free feature (Basic compression, RMAN BASIC) was used — the COMPRESS_FOR inventory and feature-usage names settle that question. First-usage date is the third: Data Pump imports and clones do not preserve original timestamps, so a recent first-usage date may not support a multi-year arrears claim.

Across 600+ engagements, the average Oracle audit claim runs 3–5× what the customer actually owes once scope, metric, and date errors are corrected (Oracle Licensing Experts, 2026). One engagement documented in our case studies closed a multi-option database claim — compression included — for a fraction of the opening demand. Before returning any script output to Oracle, read our note on Oracle audit data disclosure.

Frequently Asked Questions: Oracle Advanced Compression Licensing