The pack that licenses itself the moment you open the console
The Cloud Management Pack is a paid Oracle Enterprise Manager pack, priced per managed database processor, not bundled with Enterprise Manager. It enables itself the moment an administrator opens the matching console pages, and that usage is exactly what an Oracle audit reads back to you. The audit does not discover anything. It reads a record you already kept for it, in a database view that cannot be purged.
Prepared by Redress Compliance · August 9, 2026 · Oracle advisory. Based on 30 to 40 Oracle estates reviewed with an Enterprise Manager question 2024 to 2025.
Executive summary
It lists at 7,500 dollars per managed database processor plus 22 percent support, and the count follows the fleet, not the console.
The pack only exists inside Enterprise Manager Cloud Control, but you license it per managed database processor, so one small Enterprise Manager host managing a large fleet produces a large pack requirement.
The name misleads in an expensive direction: the Cloud Management Pack for Oracle Database runs a private database service inside your own estate through the self-service portal, metering and chargeback, and it is not a license to manage Oracle Cloud Infrastructure.
Teams assume it is covered because they are moving to OCI, and a seller lets the assumption stand, so read the pack name in full on the ordering document before either side relies on it.
Enterprise Manager ships with Management Pack Access switched on, so one console click registers priced usage with no purchase gate.
On a fresh Cloud Control install the pack boxes are ticked, and an administrator who opens the self-service or chargeback pages triggers priced usage with nothing signed and no warning.
It is one of a family of five priced database packs that self-enable the same way, Diagnostics at 7,500, Tuning at 5,000, Cloud Management at 7,500, Database Lifecycle Management at 12,000, and Data Masking at 11,500.
And treating one alone is how the second finding arrives six months after the first.
Set Management Pack Access to deny by default, the single change that stops the most common cause of unintended pack usage.
The database records feature names, never product names, so an internal review that reads the raw view goes wrong.
DBA_FEATURE_USAGE_STATISTICS returns rows like Automatic Workload Repository or SQL Tuning Advisor, and nothing in it says Cloud Management Pack: the mapping to priced products lives in options_packs_usage_statistics.sql.
Attached to My Oracle Support Doc ID 1317265.1, which prints a PRODUCT USAGE line reading Cloud Management Pack for Oracle Database over a FEATURE USAGE DETAILS section.
Read the detail, not just the verdict, because CURRENTLY_USED reflects only the most recent weekly sample while DETECTED_USAGES against TOTAL_SAMPLES is the ratio that separates a three-click demo from production use. Run the script yourself, on your own schedule, before any Oracle request arrives.
The exposure is a scoping fight, and cloning quietly makes it worse.
On a 192 core fleet at a 0.5 core factor the pack is 720,000 dollars at list; scoping it to the two servers that actually ran the portal takes it to 180,000, a 75 percent cut resting entirely on being able to show which six servers never registered the feature.
Feature usage history lives inside the database, not on the host, so restoring a production backup into a test environment carries the usage rows with it, and the test system inherits a FIRST_USAGE_DATE it never earned, indistinguishable from real usage unless you can show the clone lineage.
Keep the refresh records: a dated ticket that server B was seeded from server A is the only thing that separates one instance of usage from two.
Which console areas switch a priced pack on
| Console area in Enterprise Manager | What the click does | Pack it can register |
|---|---|---|
| Self Service Portal and service catalog | Requests, creates or destroys a database service | Cloud Management Pack |
| Chargeback and metering pages | Assigns rates and produces internal bills | Cloud Management Pack |
| Resource providers and quotas under Setup, Cloud | Defines the pool the portal provisions into | Cloud Management Pack |
| Performance Hub, AWR and ADDM pages | Opens or generates a workload repository report | Diagnostics Pack |
| SQL Tuning Advisor and SQL Access Advisor | Runs an advisor task against a statement or set | Tuning Pack, which also needs Diagnostics |
| Provisioning, patching and compliance pages | Compares configurations or drives a patch plan | Database Lifecycle Management Pack |
This is the table nobody hands the database administrators.
Each row is a place in the console where a normal-looking click writes a priced feature row into the database, and the family self-enables the same way, which is why treating the Cloud Management Pack alone is how the second finding arrives six months after the first.
Diagnostics is the usual gateway, because the performance pages depend on it and Tuning arrives attached since it cannot be licensed on its own; the mechanics of that pair sit in the Diagnostics and Tuning pack guide, and the masking equivalent in the Data Masking pack guide.
Confirm the current per-processor numbers against the Oracle price list, and read the licensing chapter for your exact Enterprise Manager release, because menu labels move between 13.4, 13.5 and later while the pack boundary does not.
Proving which packs are actually on
- Pull two records, because two exist and they do not always agree: the database keeps its own count in DBA_FEATURE_USAGE_STATISTICS, and Enterprise Manager keeps a separate one in its repository under MGMT$LICENSE_DETAIL. When they disagree, the database wins, because the database is what Oracle reads.
- Force a sample before you trust the output, with DBMS_FEATURE_USAGE_INTERNAL.EXEC_DB_USAGE_SAMPLING, because the sampling job runs weekly under MMON and a database restarted or patched this week can still read empty.
- Run the container-aware query on every consolidated platform: on a container database the standard view shows only the container you are connected to, so query CDB_FEATURE_USAGE_STATISTICS joined to V$CONTAINERS or you miss a pluggable database that ran the feature and arrived with its own history.
- Read FIRST_USAGE_DATE and DETECTED_USAGES against TOTAL_SAMPLES: the first anchors backdated support and is the most expensive value in the row; the ratio separates a demo from production, and DETECTED_USAGES quoted without its denominator is a number with no meaning.
- Untick every pack not on an ordering document at Setup, Management Packs, Management Pack Access, write down the date, then re-read the feature usage output after one full sampling cycle and confirm CURRENTLY_USED has flipped to FALSE. The full script family sits in the compliance scripts guide.
Oracle options and management packs
Why the packs cost more than the database, how usage is detected, and the strip and prove playbook worked end to end.
Get the white paper →From cores to licenses to dollars
Per processor does not mean per socket and does not mean per core: it means cores multiplied by the value in the Oracle Processor Core Factor Table, counted across the databases Enterprise Manager manages.
Take a fleet of eight two-socket servers with twelve cores per socket, 192 cores at the 0.5 Intel core factor, which is 96 processor licenses, 720,000 dollars of Cloud Management Pack at list and 158,400 a year in support, 1,195,200 dollars across license plus three years of support.
Change one row and the bill doubles: put the same 192 cores on IBM POWER9 where the core factor is 1.0 rather than 0.5 and you need 192 licenses, 1,440,000 at list, so the platform decision someone made three years ago is the pack decision you are living with now.
The number that comes off the ask is the scoping: in that fleet only two of the eight servers hosted the self-service portal and the other six had never run a provisioning request, so scoping the pack to 48 cores, 24 processor licenses, 180,000 at list, takes 540,000 off the number.
A 75 percent cut resting entirely on being able to evidence the six.
Named User Plus rarely rescues this, because although the pack lists at 150 dollars per NUP and the 96 processor position at the 25 per processor minimum is 2,400 users at 150, or 360,000, an option must be licensed on the same metric as the database beneath it.
So if those servers run Enterprise Edition per processor the pack is per processor and the NUP number is not available.
Check the metric printed on your ordering document and the current core factor table before anyone carries either figure into a meeting.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across Enterprise Manager pack reviews, 2024 to 2025
Across the 30 to 40 Oracle estates Fredrik Filipsson reviewed in 2024 and 2025 with an Enterprise Manager question attached, the finding was consistent: the pack was almost never a decision anyone had made.
It was a checkbox nobody had unticked, found years later by a script, and only one of the three components in Oracle's opening ask is actually contractual:
Estates running at least one priced pack with nothing on the ordering document to cover it, every finding out of feature usage output rather than anyone's recollection.
How far FIRST_USAGE_DATE ran before the audit letter in one estate, where the usage traced to a proof-of-concept self-service portal demoed and never torn down.
Management Pack Access was still sitting at the install default in most of them, so a database administrator opening the wrong console page was enough to register priced usage, and not one estate had a dated internal report of its own pack position.
So Oracle's script was the first measurement anybody had run.
Of Oracle's three-part ask, only the license fee for the shortfall is grounded in the audit paragraph of your Master Agreement, which obliges you to pay fees applicable to use in excess of your license rights but does not define those fees as list price.
So the backdated support and the list anchoring are both negotiable.
Run the five-step evidence routine this quarter: force a sample and export the feature usage per instance to a dated file, run the options script on the same day keeping both PRODUCT USAGE and FEATURE USAGE DETAILS, export the Management Pack Access state noting who changed it last.
Match each flagged database to the ordering document line by metric and quantity, and file the unmatched rows with their DETECTED_USAGES ratio and a named owner.
The wider three-way reconciliation sits in the license information guide, the cadence in the Oracle SAM guide, and the post-letter response in the audit secrets guide.
Your first five moves
- Set Management Pack Access to deny by default at Setup, Management Packs, untick every pack not on an ordering document, and write down the date you did it.
- Run options_packs_usage_statistics.sql on every managed database yourself, before any Oracle request, and read the FEATURE USAGE DETAILS, not just the PRODUCT USAGE verdict.
- Scope the exposure to the servers that ran the feature, evidencing which hosts never registered it, because that scoping is where the 75 percent comes off the ask.
- Keep clone and refresh lineage records, the dated ticket that separates one instance of usage from an inherited FIRST_USAGE_DATE on a test copy.
- Read the actual audit clause on your ordering document, because only the license shortfall is contractual and neither the backdated support nor the list anchoring is fixed. The Oracle practice runs the defense with you.
Frequently asked questions
What does the Oracle Cloud Management Pack license?
The cloud-style management features inside Enterprise Manager: self-service database provisioning, resource metering and chargeback, the service catalog, cloud lifecycle policies, and the resource providers the portal draws from.
It lists at 7,500 dollars per managed database processor plus 22 percent support. Despite the name it runs a private database service inside your own estate, and it is not a license to manage Oracle Cloud Infrastructure resources, a confusion that costs money in both directions.
How does the Cloud Management Pack get enabled by accident?
Enterprise Manager Cloud Control ships with Management Pack Access switched on, so on a fresh install the pack boxes are ticked.
An administrator who opens the self-service portal, the chargeback and metering pages, or the resource provider setup registers priced usage with no purchase gate in front of it, nothing signed and no warning.
The database then records that usage permanently in DBA_FEATURE_USAGE_STATISTICS, which is exactly what an audit reads back to you.
How is the Cloud Management Pack licensed and counted?
Per managed database processor, never per Enterprise Manager server, so the count follows the fleet under the console. Processor means cores multiplied by the Oracle core factor: 192 cores at the 0.5 Intel factor is 96 processor licenses, 720,000 dollars at list.
An option must be licensed on the same metric as the database beneath it, so if those databases run Enterprise Edition per processor, the pack is per processor and the cheaper Named User Plus metric is not available to you.
How do you reduce a Cloud Management Pack finding?
By scoping it to the databases that actually ran the feature.
On a 192 core fleet where only two of eight servers hosted the self-service portal, scoping the pack to those two takes it from 720,000 dollars at list to 180,000, a 75 percent cut, resting entirely on being able to evidence that the other six never registered the feature.
Read the FEATURE USAGE DETAILS in the options script output, and keep clone lineage records so an inherited FIRST_USAGE_DATE on a test copy is not counted as separate usage.
Why does DBA_FEATURE_USAGE_STATISTICS not name the pack?
Because the database records feature names, not product names: rows read Automatic Workload Repository or SQL Tuning Advisor, and nothing says Cloud Management Pack.
The authoritative mapping from feature rows to priced products is Oracle's, published in options_packs_usage_statistics.sql attached to My Oracle Support Doc ID 1317265.1, which prints a PRODUCT USAGE summary line for Cloud Management Pack for Oracle Database over a FEATURE USAGE DETAILS section.
A stale internal spreadsheet of that mapping is worse than none, because the row names change between releases.
Can Oracle charge backdated support on a Cloud Management Pack finding?
Oracle opens with three components, but only one is contractual. The license fee for the shortfall is grounded in the audit paragraph of your Master Agreement, which obliges you to pay fees applicable to use in excess of your license rights, but it does not define those fees as list price.
The backdated support and the list-price anchoring are both negotiable, and FIRST_USAGE_DATE, which sets how far back the claim reaches, is a value you should pull and reconcile before Oracle does.
How to Negotiate an Oracle OCI Deal: The Discount Is Set. The Deal Is Not.
OCI discounts are set by commitment volume, so the negotiation is the commit itself: Support Rewards at 25 to 33 cents per dollar, multicloud rights across Azure, AWS, and Google, and the higher discounts earned by workloads migrating off other clouds.
