Advanced Compression is a separately licensed Enterprise Edition option, and it is one of the easiest to trigger by accident. The capability reduces storage and improves I/O by compressing table data, indexes, backups and network traffic — genuinely valuable, which is why administrators reach for it. The problem is that enabling it is a single configuration step, while licensing it requires entitlement across every processor or Named User Plus where it runs. The gap between those two facts is where audit findings live. This note is part of our wider Oracle licensing guide and pairs with our audit defence work.
What is included versus what is paid
Oracle Database includes basic table compression for certain bulk-load scenarios at no extra option cost. The Advanced Compression option covers the richer capabilities — advanced row compression for ordinary transactional activity, advanced index compression, heat-map and automatic data optimisation behaviours, backup and Data Pump compression, and network compression. The line between "included basic compression" and "the paid option" is exactly where teams get caught, because both are reached through similar-looking syntax and parameters.
| Capability | Typically included | Requires the option |
|---|---|---|
| Basic table compression (bulk load) | Yes | — |
| Advanced row compression (OLTP-style) | — | Yes |
| Advanced index compression | — | Yes |
| RMAN backup / Data Pump compression (advanced) | — | Yes |
| Network / Data Guard redo compression | — | Yes |
How Oracle detects usage
Oracle's measurement scripts read the database's feature-usage tracking views, which record whether option-specific features have been exercised — often regardless of whether the feature is still in use today. A one-off test of advanced compression months ago can leave a flag that an Oracle review will surface. This is the same detection mechanism we describe for other options; understanding what the usage views capture is central to defending an audit.
Why this option over-triggers: compression is attractive to DBAs solving an immediate storage or performance problem, and the commands to enable it do not warn that a chargeable option is being activated. Once a feature-usage flag is set, removing the compression later does not erase the historical record. The defensible posture is to govern enablement up front, not to clean up afterwards.
How it is licensed
Advanced Compression follows the host database's metric. If the database is licensed by Processor, the option must be licensed for the same processor count, adjusted by the core factor; if by Named User Plus, the same NUP population applies, subject to minimums. You cannot license the option for a subset of a clustered or RAC database where the feature could run on any node — entitlement must cover the full licensable footprint. The same rule extends to Exadata and Cloud@Customer, where it maps to enabled OCPUs.
Keeping usage defensible
Three controls keep Advanced Compression from becoming a liability. First, decide deliberately whether you own the option, and if not, establish a policy that blocks its features in standard build scripts. Second, periodically review the feature-usage views across the estate so you discover any accidental enablement before Oracle does. Third, where the option delivers real value, license it correctly and document the entitlement against the cores it runs on. The capability is worth owning when storage savings justify it — the cost only becomes a problem when usage is unmanaged.
For a feature-usage review across your database estate, or help quantifying whether to license Advanced Compression formally, see our Oracle licensing experts service and the Oracle vendor hub. The broader option catalogue is covered in our Database 23ai licensing guide.
When the option is worth owning
Advanced Compression is not a trap to be avoided at all costs; for the right estate it pays for itself. Where storage growth is a material cost, where I/O is a performance bottleneck, or where backup and network volumes are large, the compression ratios the option delivers can justify licensing it outright. The discipline is to make that a deliberate, costed decision rather than an accidental one. Quantify the storage and performance benefit against the licence cost for the cores or users involved, and if the case holds, license it properly and document the entitlement. If it does not, ensure the option's features are blocked in your standard build and operational scripts.
Clusters, RAC and Data Guard
Licensing complexity rises in clustered and high-availability configurations. In a Real Application Clusters environment, the option must be licensed across every node where the feature could execute, not merely the node where it was first used. Standby and Data Guard configurations raise similar questions, because redo compression and backup compression can run on secondary systems. Treat the full set of nodes that could exercise the feature as the licensable footprint, consistent with the approach we describe for Exadata and Cloud@Customer.
If you find unlicensed usage
Discovering an option flag set without entitlement is uncomfortable but manageable if handled before an audit. The first step is to establish the facts: when the feature was enabled, whether it is still in use, and across how many cores or users. From there the choices are to license the option to cover the usage, or to remediate by disabling the feature and documenting the remediation. Doing this on your own timetable, with your own evidence, is materially stronger than responding to an Oracle measurement after the fact. Our audit defence guidance covers how to build that evidence.