Contents
Key takeawaysWhat the option coversWhat it costsHow it gets switched onHow to check your databasesReverting it in an auditStandard Edition and cloudWhat we have seenAnswering OracleWhat to do nextFAQAdvanced Compression must cover every processor or user of the database it runs on, at the Partitioning price, and a migration default or copied script usually switches it on. Check all ten features, revert what no one chose, and license only where compression pays.
- Ten features sit under one option. Table compression is only the first; backup levels, Data Pump export, Data Guard redo transport and network compression are licensed under the same option.
- The free variant is one keyword away. Basic table compression, the BASIC backup algorithm and metadata only export are free, while the variant one word along in the same statement is licensed.
- One object prices the whole database. The option must match the database license in metric and quantity, at the same price line as Partitioning, so a single compressed object covers every processor.
- Most use is accidental. In 3 out of 4 customer environments we reviewed, the compression had been set without a decision, usually by a migration tool default.
- Check beyond the tables. Six of the ten families live in instance parameters, RMAN configuration and network files, where a compressed table query never looks.
- Remediation cuts the finding. Reverting accidental use with dated evidence, and licensing only where compression earned its keep, cut proposed findings by 18 to 30 percent.
What does Oracle Advanced Compression licensing cover?
Advanced Compression is an extra cost option for Oracle Database Enterprise Edition, and it covers ten feature families, of which table compression is only the first. You do not install it. It is a property of objects and settings, so nothing in the software stops an unlicensed database from using it.
Whoever writes a schema, clones an environment or copies a backup configuration can commit a database to the option. Each family below is switched on by a keyword or parameter in routine DBA work, and none of them raises a license prompt.
- Advanced row compression. ROW STORE COMPRESS ADVANCED on a table or partition, written COMPRESS FOR OLTP in 11g.
- Advanced index compression. COMPRESS ADVANCED LOW or HIGH on an index.
- Advanced LOB compression. COMPRESS on a SecureFiles large object column.
- Advanced LOB deduplication. DEDUPLICATE on the same kind of column.
- Backup compression. The RMAN LOW, MEDIUM and HIGH algorithms.
- Export compression. Data Pump with COMPRESSION=ALL or DATA_ONLY.
- Redo transport compression. COMPRESSION=ENABLE on a Data Guard LOG_ARCHIVE_DEST_n destination.
- Network compression. Advanced Network Compression, set with SQLNET.COMPRESSION in sqlnet.ora.
- Heat Map with Automatic Data Optimization. ILM policies that compress or move segments as the data cools.
- Archive optimization. Optimization of Flashback Data Archive history tables, which current releases call Flashback Time Travel.
Where the free line sits, feature by feature
Most of the free features sit one keyword away from the licensed ones, often in the same statement. A hardening guide or a copied script that changes one word is enough to commit the database.
| Area | Free | Licensed | Syntax that crosses the line |
|---|---|---|---|
| Table compression | Basic, for direct path loads | The advanced row variant | ROW STORE COMPRESS ADVANCED |
| Index compression | The older prefix style, COMPRESS n | The advanced variants | COMPRESS ADVANCED LOW or HIGH |
| Backup compression | The default BASIC algorithm | The higher compression levels | CONFIGURE COMPRESSION ALGORITHM 'MEDIUM' |
| Export compression | Metadata only | Full or data only | COMPRESSION=ALL or DATA_ONLY |
| Large object storage | The SecureFiles storage format itself | Compression and deduplication on top of it | COMPRESS or DEDUPLICATE in the LOB clause |
| Columnar compression | Hybrid Columnar Compression, included on engineered storage | Only row level locking for it | ROW LEVEL LOCKING on a COLUMN STORE table |
What Oracle's own list adds to the ten families
Oracle's licensing guide names 14 items under the option. Beyond the ten families it adds four narrower ones.
- Storage Snapshot Optimization. Allows third party storage snapshots without placing the database in backup mode.
- Online Move Partition. Covers moving a partition online into any compressed format.
- Exadata Flash Cache Compression. The widest reach of the four, because once it is enabled on the storage servers, every database processor that accesses them must be licensed for the option.
- Row level locking for Hybrid Columnar Compression. Relevant only on Exadata, ZFS and the other Oracle storage that supports HCC.
Version also matters: the 12c guide listed Heat Map as a licensed feature in its own right, while the current guide lists Automatic Data Optimization only, so read a Heat Map entry against the guide for that release.
How to Prepare for Your Oracle SaaS Negotiation
How much does Oracle Advanced Compression cost?
Oracle lists Advanced Compression at $11,500 per processor with $2,530 annual support, or $230 per Named User Plus with $50.60 support. That is the same price line as Partitioning, and Oracle's current technology price list still shows those figures.
The option must match the database license in metric and quantity. One compressed object therefore prices every licensed processor under that database, on every node it runs on. The same matching rule for options applies under Named User Plus, where you license the full user count and the Enterprise Edition minimum of 25 users per processor still applies.
Worked example: three databases and one accidental import
Say an auditor flags Advanced Compression on three Enterprise Edition databases, all on Intel servers where Oracle's core factor is 0.5. Production uses advanced row compression on its archive tables by design. A reporting copy picked up the attributes through a Data Pump import, and a test database inherited a MEDIUM backup setting from a copied script.
| Database | Cores | Processor licenses | How compression arrived | License at $11,500 | Support per year at $2,530 |
|---|---|---|---|---|---|
| Production, two nodes of 32 cores | 64 | 32 | Chosen by the DBA team | $368,000 | $80,960 |
| Reporting copy | 12 | 6 | Data Pump import | $69,000 | $15,180 |
| Test | 4 | 2 | Copied RMAN script | $23,000 | $5,060 |
| Total as flagged | 80 | 40 | $460,000 | $101,200 |
Oracle licenses test databases the same way as production, so the test server counts in full.
Reverting the two accidental cases with dated evidence takes 8 processor licenses out of scope, worth $92,000 in license fees and $20,240 a year in support. The production database stays in scope, and there the conversation turns to price because the compression is in real use.
The Oracle CIO guide
How to control database option exposure, prepare evidence and plan Oracle spend over five years.
Get the white paper →How does Advanced Compression get switched on by accident?
Most often a migration tool default switches it on, with no decision behind it. In the environments we review, it arrives by one of five routes, and each one looks like routine administration at the time.
- Imports carry attributes. An export and import recreates the compression attributes of the source schema, so one licensed source can seed a dozen unlicensed targets.
- Tablespace defaults cascade. A tablespace created with a compressed default compresses every table later created in it, which turns one line of setup into a standing exposure.
- Vendor scripts decide for you. Some third party installers and schema upgrade kits ship compressed definitions, and the customer's DBAs rarely read the DDL before running it.
- Copied backup configuration. An RMAN script cloned from another environment brings the higher algorithm with it, and the setting persists without any warning.
- Standby parameter drift. A latency fix that enables redo transport compression turns a network change into a licensing decision, and a standby must mirror the primary's option licensing anyway.
Why migrations create most of the exposure
Most of the exposure we find starts in a migration project. Attributes move unseen with the data, the target goes live, and the project team disbands before anyone checks feature usage on the new servers.
A license verification run in the week after go live is the cheapest control available, and most teams never schedule it. Write it into the migration statement of work so the integrator owns it, and repeat it after any database upgrade.
How do you check whether Advanced Compression is in use?
Look in the place each feature records itself, across all ten families. A query for compressed tables misses six of them, which is how companies arrive at an audit convinced they had already checked.
| Feature | Where to look |
|---|---|
| Advanced row compression | COMPRESS_FOR in DBA_TABLES and DBA_TAB_PARTITIONS, showing ADVANCED (OLTP on 11g) |
| Tablespace defaults | DEF_TAB_COMPRESSION and COMPRESS_FOR in DBA_TABLESPACES |
| Advanced index compression | COMPRESSION in DBA_INDEXES, showing ADVANCED LOW or ADVANCED HIGH |
| LOB compression and deduplication | COMPRESSION and DEDUPLICATION in DBA_LOBS |
| Backup compression | SHOW COMPRESSION ALGORITHM in RMAN, plus the backup scripts that set it per job |
| Export compression | Data Pump parameter files and scheduled job scripts |
| Redo transport compression | LOG_ARCHIVE_DEST_n settings on the primary and every standby |
| Network compression | sqlnet.ora on database servers and application hosts |
| Heat Map and ADO | The HEAT_MAP parameter and DBA_ILMPOLICIES |
| Archive optimization | Flashback archives created with OPTIMIZE DATA |
DBA_FEATURE_USAGE_STATISTICS pulls much of this together, but it records history. Its detected and currently used columns and the first and last usage dates tell you when use began and whether it stopped. Run the report before Oracle's script does, so you see the same rows first.
Why the compression advisor can produce a false positive
Running the compression advisor, DBMS_COMPRESSION, creates temporary compressed objects while it estimates ratios, and those runs can leave entries in the usage statistics. This caveat works in your favor, so know it before conceding anything.
Oracle's own measurement script, published in My Oracle Support note 1317265.1, attempts to separate advisor activity from production use. Establish which one each flagged entry reflects, with the date of the advisor run, instead of accepting the raw statistic.
Why we push back on licensing it for the storage savings
Once compression is found, the account team and sometimes the internal DBA team suggest keeping it and buying the option, on the grounds that it pays for itself in storage. For accidental use we disagree. Fewer than 1 in 3 of the accidentally compressed objects we examined delivered any measurable benefit.
Measure each object instead: segment size before and after, query times and backup windows. License only the databases where the saving clearly exceeds the $2,530 a year per processor that support alone costs, and revert the rest.
Does reverting Advanced Compression hold up in an Oracle audit?
Yes. Remediation is legitimate and it is the whole defense, as long as every change is dated and the before and after evidence is kept together. The revert has to reach existing data as well as the setting, which is where many attempts fall short.
- Tables. ALTER TABLE with NOCOMPRESS changes only future inserts. Existing blocks stay compressed until you move the table or partition with NOCOMPRESS or ROW STORE COMPRESS BASIC, then rebuild any indexes left unusable.
- Indexes. Rebuild with NOCOMPRESS, or with prefix compression where that gives most of the benefit at no license cost.
- Large objects. Rebuild SecureFiles segments with NOCOMPRESS and KEEP_DUPLICATES, through a LOB move or online redefinition.
- Tablespaces. Set DEFAULT NOCOMPRESS so new tables stop inheriting the attribute.
- Backups and exports. Set CONFIGURE COMPRESSION ALGORITHM 'BASIC', and change Data Pump parameter files to METADATA_ONLY or NONE.
- Standby, network and ILM. Remove COMPRESSION=ENABLE and SQLNET.COMPRESSION, disable the ILM policies and set HEAT_MAP to OFF.
Keep a change log with the object, the old attribute, the date of the change and the evidence of the new state. The dates are what make the remediation hold up when the usage statistics still show the earlier period. The wider register of these exposures sits in hidden Oracle audit exposures.
Does Advanced Compression apply on Standard Edition or in Oracle Cloud?
The option exists only on Enterprise Edition. A compressed attribute that travels into a Standard Edition 2 database during a downgrade project is a configuration error to fix rather than a license to purchase, and it belongs with the other Enterprise features found on SE2.
Which cloud tiers include the option
On OCI, Base Database Service Enterprise Edition High Performance and Extreme Performance include Advanced Compression, as does Exadata Database Service. The plain Enterprise Edition package does not. A bring your own license deployment carries the on premises entitlement question with it, so confirm the model for each database before you pay twice.
The BYOL versus license included comparison shows how to price both routes. The wider option exposure, including Partitioning and the security options, sits in the options pricing and audit guide.
What have we seen in recent Advanced Compression reviews?
Across the 20 to 26 Oracle compression reviews we ran through 2024 and 2025, accidental use was the dominant pattern. Three findings recurred.
- Set by accident. Licensed compression had been set with no deliberate decision in 3 out of 4 customer environments, most often by a migration tool default.
- Little benefit. Fewer than 1 in 3 of the accidentally compressed objects delivered a measurable gain once examined.
- Smaller findings. Reverting the accidental use and licensing only where compression earned its keep cut the proposed finding by 18 to 30 percent.
Advanced Compression is switched on by syntax that looks like tuning, so the decision seldom reaches anyone who owns the license budget.
Because the option sits on the Partitioning price line, a finding is rarely small enough to absorb in a routine true up. That combination is why compression produces audit findings more reliably than almost any other database option.
What will Oracle say about a compression finding, and how should you answer?
Expect the first position to be that any recorded usage requires the option on every processor. The negotiation then turns on dates, on which feature triggered each entry and on which databases it touched.
Lines you will hear, with replies
- "Usage statistics show Advanced Compression, so every processor needs it." Ask which feature row triggered it, per database, with first and last usage dates. Then show which entries are advisor runs and which were reverted, with the change log.
- "Reverting now does not change what you used." Past use during a migration window is a question about that period. It does not justify perpetual licenses and support on every processor from here on.
- "Your standby needs the option as well." That is correct when the primary uses it. If the only trigger was redo transport compression, disabling it removes the question for both servers.
- "Move to OCI High Performance and compression is included." Price that subscription against the on premises support you would drop, and check you are not paying for both during the transition.
Contract wording to ask for in a settlement
- Named scope. List the databases and hosts licensed for the option, so a later audit cannot extend it to every processor under the agreement.
- Remediated use. State that features reverted on a dated change log fall outside the license requirement from the revert date.
- Advisor runs. Record that compression advisor entries do not count as use of the option.
- Price hold. Hold the settlement discount for later additions of the option, using a price hold clause, in case more databases need it.
What to do next
- Sweep every Enterprise Edition database. Check all ten feature families, including RMAN configuration, LOG_ARCHIVE_DEST_n settings and sqlnet.ora files as well as table attributes.
- Separate advisor runs from production use. Date each flagged entry in the usage statistics before conceding anything.
- Revert what was never chosen. Move or rebuild the affected objects, date every change and keep the before and after evidence together.
- Fix the sources. Reset tablespace defaults and review vendor supplied DDL, since these two paths turn one setup line into a standing exposure.
- Measure what remains. License the option only on databases where compression earns more than it costs.
- Schedule the post migration check. Book a license verification for the week after every go live. Our Oracle practice runs the sweep with you.
Frequently asked questions
What does Oracle Advanced Compression cost?
List price is $11,500 per processor with $2,530 a year in support, or $230 per Named User Plus. Support runs at 22 percent of the license fee, so over five years it adds $12,650 per processor on top of the license. Multiply by every processor under the database, since the option cannot be licensed for part of it.
What does the option gate beyond table compression?
Nine more families, from index and LOB compression to backup, export, redo transport and network compression, ADO and archive optimization. Most buyers know the table feature and get caught by the others, particularly the backup and standby settings a DBA changes outside the schema, where no one reviewing DDL will see them.
Where does the free line sit?
Usually at the default. RMAN compresses with the BASIC algorithm and Data Pump compresses metadata only unless someone asks for more, and basic table compression is included with Enterprise Edition. Crossing into the licensed variant takes one extra keyword or parameter, which is why the change so often goes unnoticed.
How does accidental use happen?
Through imports that recreate source attributes, tablespace defaults, vendor installers with compressed DDL, cloned backup scripts and standby parameter changes made for latency. The first place to look is any database built, moved or upgraded in the last few years, and any server whose RMAN or Data Guard settings were copied from another environment.
Is remediation legitimate?
Yes. Oracle's usage statistics keep the historical rows after you revert, so remediation does not erase the past. What it does is give you a dated point after which the option is no longer used, and a change log with before and after evidence is how you prove that date to an auditor.
Does the compression advisor create a false positive?
It can, because the advisor builds temporary compressed objects that may register as usage. Keep a record of every advisor run with its date and database, and where you can, run it on a database that already carries the option. That makes any later entry easy to explain.
Does the option apply on Standard Edition or in the cloud?
It is an Enterprise Edition option only, so on Standard Edition 2 the fix is to remove the attribute. On OCI, the High Performance and Extreme Performance packages include it. Under BYOL on AWS or Azure, Oracle's cloud policy counts 2 vCPUs as one processor license when hyperthreading is on, and the option follows that count.
When is the exposure usually created?
During migration projects. Make a feature usage check part of the cutover acceptance criteria, so the project cannot close until someone has compared the target database against the source and signed off that no licensed compression came across.
Is basic table compression free with Oracle Enterprise Edition?
Yes. Basic table compression is included with Enterprise Edition, but it compresses only data loaded through direct path operations such as bulk loads and CREATE TABLE AS SELECT. Rows added by ordinary inserts and updates are stored uncompressed, which is why teams reach for the advanced variant and cross the license line.