The Cloud Management Pack is one of the priced Enterprise Manager packs. It enables itself inside the console and then shows up in an audit. Read the cost and the control before the next true up.
The Cloud Management Pack is a paid Oracle Enterprise Manager pack. 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.
It licenses the cloud style management features inside Enterprise Manager. The headline capabilities are self service database provisioning, resource metering, and chargeback. Everything it covers sits behind console pages that look like ordinary Enterprise Manager.
Oracle defines the pack boundaries in the Oracle Enterprise Manager documentation. Read the licensing chapter for your exact release before you assume a console page is free. Menu labels move between 13.4, 13.5 and later; the pack boundary does not.
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.
Console areas and the pack they can register
| 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 |
The Cloud Management Pack only exists inside Enterprise Manager Cloud Control. You license the pack per managed database processor, not per Enterprise Manager server. The metric rule is set out in the Oracle Database Licensing Information manual.
That distinction decides the size of the bill. One small Enterprise Manager host managing a large fleet produces a large pack requirement, because the count follows the fleet.
The name misleads buyers in a specific and expensive direction. The Cloud Management Pack for Oracle Database is about running a private database service inside your own estate through Enterprise Manager. It is not a license to manage Oracle Cloud Infrastructure resources.
We have seen this confusion produce two errors in the same meeting. A team assumes the pack is already covered because it is moving to Oracle Cloud Infrastructure, and a seller lets that assumption stand. Read the pack name in full on the ordering document before either side relies on it.
Five database packs carry a price and self enable the same way. The Cloud Management Pack is one of a family, and treating it alone is how the second finding arrives six months after the first.
Priced Enterprise Manager database packs in 2026
| Pack | 2026 list per processor | Dependency | Common trap |
|---|---|---|---|
| Diagnostics Pack | 7,500 dollars | None | AWR and ADDM usage |
| Tuning Pack | 5,000 dollars | Requires Diagnostics | SQL Tuning Advisor |
| Cloud Management Pack | 7,500 dollars | Enterprise Manager | Self service portal left on |
| Database Lifecycle Management Pack | 12,000 dollars | Enterprise Manager | Patch and config tracking |
| Data Masking and Subsetting Pack | 11,500 dollars | Enterprise Manager | Masking in non production |
Most pack exposure starts with the Diagnostics Pack, because the performance pages depend on it. Tuning then arrives attached to it, because the Tuning Pack cannot be licensed on its own. Confirm the current numbers against the Oracle Technology Price List.
The database records what was used, in its own vocabulary. Nothing in the view says Cloud Management Pack. Knowing roughly which family a row belongs to is what stops a team from panicking at the wrong line.
Treat that list as orientation, not as the mapping. The authoritative mapping is the one Oracle publishes and updates, inside the script covered below. Row names change between releases and a stale internal spreadsheet is worse than none.
Because Enterprise Manager turns packs on by default and the database records the usage permanently. The audit does not discover anything. It reads a record you already kept for it.
On a fresh Cloud Control install, management pack access is enabled for the pack set. An administrator who opens the self service or chargeback pages triggers priced usage with no purchase gate in front of it. Nobody signs anything and nobody is warned.
Oracle reads the database feature usage statistics and, where it is in scope, the Enterprise Manager repository. Both retain history, so a trial from two years ago still counts. The audit right itself sits in the Oracle contract terms printed on your ordering document.
Feature usage history lives inside the database, not on the host. Restore a production backup into a test environment, or clone a production database to build a reporting copy, and the usage rows travel with it.
The test database then reports a FIRST_USAGE_DATE for a feature that was never used on that system. In a settlement conversation that row is indistinguishable from real usage unless you can show the clone lineage.
Keep the refresh records. A dated ticket showing that server B was seeded from server A on a specific date is the only thing that separates one instance of usage from two.
Source: Redress Compliance advisory engagement file, 2024 to 2025. Estate count and the seven in ten ratio are stated as the ranges they are, not as measured counts. The price is the Oracle Technology Price List, list before discount.
An Enterprise Manager pack does not need to be bought to be used. That single default is the reason packs dominate Oracle compliance findings.
Pull two records, because two exist and they do not always agree. The database keeps its own count in DBA_FEATURE_USAGE_STATISTICS. Enterprise Manager keeps a separate one in its repository.
Do this before anyone writes a word to Oracle. The same measurement is the backbone of the wider three way check on your Oracle license position, which reconciles usage against entitlement and support records.
Run this on every managed database, as a user with SELECT on the data dictionary. It is described in the Oracle Database Reference.
SELECT name,
version,
detected_usages,
total_samples,
currently_used,
first_usage_date,
last_usage_date,
aux_count
FROM dba_feature_usage_statistics
WHERE detected_usages > 0
ORDER BY first_usage_date;The sampling job runs weekly under MMON, so a database restarted or patched this week can still read empty. Force a sample before you trust the output:
EXEC DBMS_FEATURE_USAGE_INTERNAL.EXEC_DB_USAGE_SAMPLING(SYSDATE);
On a container database, DBA_FEATURE_USAGE_STATISTICS shows the container you are connected to. Query the root and you can miss a pluggable database that ran the feature.
SELECT c.name AS container,
f.name,
f.detected_usages,
f.total_samples,
f.currently_used
FROM cdb_feature_usage_statistics f
JOIN v$containers c ON c.con_id = f.con_id
WHERE f.detected_usages > 0
ORDER BY c.name, f.name;Run the container aware version on every consolidated platform. A pluggable database moved in from another estate arrives with its own usage history attached, exactly as a clone does.
This is where internal reviews go wrong. DBA_FEATURE_USAGE_STATISTICS returns feature names and nothing in it says Cloud Management Pack. The mapping from feature rows to priced products belongs to Oracle, and Oracle publishes it.
The script is options_packs_usage_statistics.sql, attached to My Oracle Support Doc ID 1317265.1 in the My Oracle Support portal. It prints a PRODUCT USAGE summary carrying one line per priced option and pack, including the line reading Cloud Management Pack for Oracle Database.
Under that summary sits a FEATURE USAGE DETAILS section showing the rows that produced each verdict. Read the detail, not just the summary. The verdict line is a conclusion; the detail lines are the evidence you will argue from.
Run it yourself, on your own schedule, before any Oracle request arrives. It is the same script a licensing review will ask you to run, and the full family is covered in our guide to Oracle license compliance scripts. The only question is who reads the output first.
| Column | What it records | Why it decides the number |
|---|---|---|
| FIRST_USAGE_DATE | The date of the earliest weekly sample that flagged the feature | Oracle anchors backdated support to this field. It is the most expensive value in the row. |
| LAST_USAGE_DATE | The most recent sample that flagged it | If this is two years stale and the portal is gone, the argument is about a dead feature, not a live license. |
| DETECTED_USAGES | How many samples flagged the feature | Three detections is a demo. Two hundred is production. A settlement template does not distinguish. You have to. |
| TOTAL_SAMPLES | How many samples the database has taken | The denominator. DETECTED_USAGES quoted without it is a number with no meaning. |
| CURRENTLY_USED | TRUE or FALSE at the most recent sample | The field that tells you whether the deny change actually took effect. |
| AUX_COUNT | A feature specific counter, populated for some features and null for others | Sanity check on scale where it is populated. |
Two phrases in that output get read as opposites and are not. CURRENTLY USED describes the last sample. PAST USAGE describes the history. A feature that is currently unused and historically used is still a finding, and a feature that is currently used once is still a purchase conversation.
In Enterprise Manager Cloud Control the control sits at Setup → Management Packs → Management Pack Access. That page lists every managed target type and every pack that can attach to it, with a checkbox each. On a fresh install those boxes are ticked.
Untick every pack that is not on an ordering document, save, and write down the date you did it. Then re read the feature usage output after one full sampling cycle and confirm CURRENTLY_USED has flipped to FALSE.
Enterprise Manager holds its own copy of that state in the repository, in the MGMT$LICENSE_DETAIL view under the SYSMAN schema. Your Enterprise Manager administrator can query it directly for the console side view.
It tells you which packs the console believes are licensed against which targets. That is a different question from which features the database actually executed. When the two records disagree, the database wins, because the database is what Oracle reads.
The pack lists at 7,500 dollars per processor of managed database, plus 22 percent annual support. Both numbers scale with the fleet under the console, not with the console itself.
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. Here is a fleet shape we have priced more than once.
| Line | Value | How it is derived |
|---|---|---|
| Database servers under one Cloud Control console | 8 | Counted from the Enterprise Manager target list |
| Sockets per server | 2 | Standard two socket x86 |
| Cores per socket | 12 | From the server bill of materials |
| Total cores | 192 | 8 × 2 × 12 |
| Core factor, Intel Xeon | 0.5 | Oracle Processor Core Factor Table |
| Processor licenses required | 96 | 192 × 0.5 |
| Cloud Management Pack, per processor | $7,500 | Oracle Technology Price List, list before discount |
| License at list | $720,000 | 96 × $7,500 |
| Annual support at 22 percent | $158,400 | $720,000 × 0.22 |
| License plus three years of support | $1,195,200 | $720,000 + (3 × $158,400) |
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 processor licenses.
That is $1,440,000 at list and $316,800 a year in support. The platform decision someone made three years ago is the pack decision you are living with now. Check the current core factor table before you commit either number.
In that fleet, two of the eight servers hosted the self service portal. The other six had never run a provisioning request, and the feature usage output proved it. Scope the pack to the two:
That is $720,000 down to $180,000. $540,000 of list price removed, a 75 percent cut, resting entirely on being able to show which six servers never registered the feature.
Substitute your own server count, socket count and cores per socket into the same four lines. The arithmetic does not change. What changes is whether you can evidence the six.
The Oracle Technology Price List carries a second metric for the pack: $150 per Named User Plus, list. Enterprise Edition minimums apply at 25 Named User Plus per processor. On the 96 processor position that is 2,400 users at $150, or $360,000, exactly half the processor number.
Buyers see that and start building a case. It usually collapses on one rule: an option or pack must be licensed on the same metric as the database beneath it.
If those eight servers run Enterprise Edition licensed per processor, the pack is licensed per processor and the $360,000 is not available to you. Check the metric printed on your ordering document before anyone carries the Named User Plus number into a meeting.
Only one of the three components in the opening ask is contractual. That is the question that sets the size of the settlement, and it is the one most pack explainers skip entirely.
| The ask | Where it comes from | What we have seen it settle at |
|---|---|---|
| License fees for the shortfall, priced at list | The audit paragraph of your Oracle Master Agreement, or the older Oracle License and Services Agreement. Find the agreement identifier printed on your ordering document and read the actual words. It obliges you to pay fees applicable to use in excess of your license rights. It does not define those fees as list price, and it says nothing about support. | Settled inside the wider transaction. Oracle publishes no discount schedule for management packs. |
| Support backdated to FIRST_USAGE_DATE | No published Oracle policy. This part exists because the field exists and is trivial to read. | Most often removed, or capped at a single year, once the customer commits to a forward purchase. Engagement experience, not an entitlement. |
| Reinstatement on a support line that lapsed | Published. Oracle Technical Support Policies, under the heading Reinstatement of Oracle Technical Support. | Priced by formula. It does not move the way the first two move. |
They get argued in the same meeting and they behave nothing alike. Back support is Oracle asking you to pay maintenance for years in which you held no license at all. Reinstatement is Oracle's price for putting support back onto a license you already own, after the support line lapsed.
Reinstatement is published. It sits in the Oracle Technical Support Policies, under the heading Reinstatement of Oracle Technical Support. That document is versioned and carries an effective date on its first page.
Your ordering document incorporates one specific version, not the one sitting on the website today. Check which. The version most customers are operating under prices reinstatement at 150 percent of the last annual support fee, with the fees for the lapsed period added on top.
Put the scoped position through it. Support on 24 licenses runs $39,600 a year at list. Let it lapse for eighteen months and the conversation opens at $59,400, before the lapsed period is added.
Both sit in the same Technical Support Policies document, and both have names you can search for.
Support is 22 percent of the net license fee, not of list. Every point of discount you win on the forward license also comes off every backdated year Oracle is claiming. On the scoped 24 license position, $180,000 at list:
The gap between those two outcomes is $35,640, which is nine tenths of a full year of support at list. Oracle publishes no discount rates for management packs.
The 40 to 70 percent band above is what we have seen management pack license settle at when it is negotiated inside a larger Oracle transaction. It is engagement experience, not a rate card.
FIRST_USAGE_DATE records when a weekly sample first flagged the feature. It does not record that the feature ran continuously from that date, and nothing in the view claims it does. DETECTED_USAGES against TOTAL_SAMPLES is what shows the shape of the usage.
A row reading 3 detections against 214 samples describes a portal that was stood up, demoed and abandoned. The same row reading 214 against 214 describes production. A settlement template treats both as continuous use from FIRST_USAGE_DATE forward.
Pull both columns, put the ratio in writing, and pair it with the change record that decommissioned the portal. A dated ticket beats an argument. In the pack settlements we have run, that pairing moved the back support line further than any debate about the wording of the audit clause.
Four moves close most of the exposure, and they only work in this order.
Run the report across the fleet to see exactly which packs are in use today. Keep the dated output as a file, not as a screenshot in a slide.
Change the Enterprise Manager control so administrators cannot trigger priced packs by accident. Record who made the change and on what date.
Buy only the packs a team genuinely needs, then re run the report each quarter. Anything that reappears is a process problem, not a licensing problem.
Name a person accountable for pack access state, in the same way a firewall rule has an owner. Unowned controls drift back to the default at the next upgrade, which is a software asset management question rather than a database one.
The common advice is to buy the pack set and stop worrying. Resellers sell Enterprise Manager the way an insurer sells a policy: take all five packs, never think about it again. It is a comfortable sale and a poor trade.
What it insures against is a console setting you can change in an afternoon, and the premium never stops. The five priced packs in the table above total $43,500 per processor. On the 96 processor fleet that is $4,176,000 at list before a dollar of support, against a measured requirement of $180,000.
Set Management Pack Access to deny, wait one sampling cycle, read DBA_FEATURE_USAGE_STATISTICS again, and buy what is still lit. Order matters. Buy first and you have licensed the default, not the use.
There is a mirror error, and asset management teams make it more often than resellers do. Turning pack access off does not clear the record, because DBA_FEATURE_USAGE_STATISTICS keeps FIRST_USAGE_DATE for the life of the database.
Disabling stops the meter; it does not rewind it. That is why the deny change and the evidence pull belong on the same day, in that order. You want the dated before and after sitting in your file, not only in Oracle's.
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.
White Paper · Oracle Database
Oracle Options & Management Packs
Why the options cost more than the database. Read it free.
No. The Cloud Management Pack is a separately priced Enterprise Manager pack at 7,500 dollars per processor plus support. Enterprise Manager enables it by default, which is why usage often accrues with no purchase decision.
It licenses the cloud style management features inside Enterprise Manager, mainly self service database provisioning, resource metering, and chargeback. It is licensed per managed database processor, not per Enterprise Manager host.
No, and the name causes real confusion. The pack covers running a private database service inside your own estate through Enterprise Manager. It does not grant any right to manage Oracle Cloud Infrastructure resources, so never let a cloud migration plan stand in as coverage for it.
Enterprise Manager records pack usage in the database feature usage views and its own repository. The audit reads that record. A single old self service trial can register usage years after the fact.
Set management pack access to deny by default in Enterprise Manager. That stops administrators from triggering priced packs by clicking through standard console pages, which is the most common cause of exposure.
It is 7,500 dollars per processor of managed database in 2026, plus 22 percent annual support. The cost scales with the number of database processors the console manages, so a large fleet adds up quickly.
Not strictly, but most Enterprise Manager exposure begins with the Diagnostics Pack because the performance pages depend on it. Review all priced packs together, since they share the same self enable behavior.
Yes. You license the specific database processors the pack manages. The buyer side approach is to license to measured usage and exclude targets where the pack features are not used.
Pull the feature usage report across the fleet, record which packs are in use and since when, and confirm the access control posture. A clean usage baseline is the strongest lever in a pack negotiation.
Query DBA_FEATURE_USAGE_STATISTICS on every managed database, then run options_packs_usage_statistics.sql from My Oracle Support Doc ID 1317265.1, which maps raw feature rows to the priced options and packs. Force a fresh sample first with DBMS_FEATURE_USAGE_INTERNAL.EXEC_DB_USAGE_SAMPLING, because the collection runs weekly and a recently restarted database can still read empty.
Currently used describes the most recent weekly sample, while past usage describes the whole recorded history. A feature that stopped last year still shows historical usage and is still a finding. Read both fields together with DETECTED_USAGES and TOTAL_SAMPLES, because a feature touched once registers exactly like a feature used daily.
It can, because feature usage history lives inside the database and travels with a restore or clone. The copy will report a FIRST_USAGE_DATE it never earned locally, which reads as separate usage unless you can show the lineage. Keep dated refresh tickets so one instance of usage is not counted twice.
Oracle's opening ask usually backdates support to the FIRST_USAGE_DATE recorded in DBA_FEATURE_USAGE_STATISTICS. No published Oracle policy sets that rule. In the pack settlements we have run, backdated support was most often removed or capped at a single year once the customer committed to a forward purchase. That is engagement experience, not a contractual entitlement.
Reinstatement is published policy, in the Oracle Technical Support Policies under the heading Reinstatement of Oracle Technical Support. Your ordering document incorporates one specific dated version, so check which. That version prices reinstatement at 150 percent of the last annual support fee plus the lapsed period fees, so 39,600 dollars a year opens at 59,400 dollars.
Setup, then Management Packs, then Management Pack Access. Untick every pack that is not on an ordering document and record the date. Enterprise Manager keeps its own copy of that state in the MGMT$LICENSE_DETAIL view under the SYSMAN schema. Disabling access stops new usage; it does not clear FIRST_USAGE_DATE for usage already recorded.
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.