Oracle Cloud Management Pack and Database Lifecycle Management Pack licensing. What they cost and how usage gets recorded.

The Cloud Management Pack is a paid Enterprise Manager pack at $7,500 per managed database processor, and it requires the Database Lifecycle Management Pack. Enterprise Manager enables both by default, and each database keeps the usage record an audit reads.

What does the Oracle Cloud Management Pack license?

It licenses the private cloud functions of Oracle Enterprise Manager Cloud Control for Oracle Database: the Self Service Portal, database and schema provisioning on request, quotas and retirement policies, Snap Clone, and chargeback and metering. It is a paid pack. The console's base functions come with your database licenses, but this pack does not.

The list price is $7,500 per processor or $150 per Named User Plus, with support at 22 percent a year on top. The count is per managed database processor, so the size of the Enterprise Manager server is irrelevant. A small console host looking after a large fleet produces a large pack requirement.

• Self Service Portal and service catalog. Users request, create and retire databases, schemas and pluggable databases from templates without a ticket to the DBA team.
• Quotas and policies. Role based limits on what each group can provision, and retirement dates for what they create.
• Snap Clone and data refresh. Space efficient database clones, and refresh of existing full clones from newer production backups.
• Chargeback and metering. Rates per target, internal bills, and the Charge Trend, Charge Summary, Usage Trend and Usage Summary reports.

Is it a license to manage Oracle Cloud Infrastructure?

No, and this misreading costs money in both directions. The pack runs a private database service inside your own data centers. Teams moving workloads to OCI sometimes assume it covers them there, or assume it is already included in their cloud contract, and a seller has little reason to correct either belief.

Read the pack name in full on the ordering document before anyone relies on it. The line you want to see is Cloud Management Pack for Oracle Database, with a metric and a quantity that match the databases in question.

Why does the Cloud Management Pack require the Database Lifecycle Management Pack?

Oracle's Enterprise Manager Licensing Information User Manual states that the Database Lifecycle Management Pack is a prerequisite for the Cloud Management Pack. The self service portal provisions and patches databases, and provisioning, patching, configuration and compliance management belong to Database Lifecycle Management. That pack lists at $12,000 per processor or $240 per Named User Plus.

A legitimate Cloud Management Pack purchase therefore costs $19,500 per processor at list once both packs are counted. Expect an audit finding on the cloud pack to bring a second line for Database Lifecycle Management on the same processors, unless you already own it there.

What does the Database Lifecycle Management Pack cover on its own?

It covers the day to day administration work that most DBA teams run from Enterprise Manager, which is why it often turns up in usage output even where no one has touched the cloud portal. The 13.5 licensing manual groups it into these areas:

• Provisioning. Single instance, RAC and multitenant databases, plus the full lifecycle of pluggable databases.
• Patching, upgrade and Fleet Maintenance. Automated patch plans and database software upgrades across many targets.
• Configuration and compliance management. Configuration drift checks and compliance standards such as CIS, STIG, PCI DSS and HIPAA.
• Change and schema management. Schema comparison, synchronization and change plans.
• Cloning. Creation of new full clones.

How does the Cloud Management Pack get switched on without a purchase?

Enterprise Manager grants the packs for you. Auto Licensing is enabled by default, so every newly discovered database target receives all its associated packs, and the pack boxes under Management Pack Access are ticked on a fresh install. An administrator who then opens the self service or chargeback pages registers priced usage with nothing signed and no warning on screen.

Setting Management Pack Access to deny by default is the single change that stops the most common cause of unintended pack usage. When a pack is disabled, Enterprise Manager greys out its links or shows a message that the pack is not licensed.

Database administrators are rarely shown this table, yet each row is a normal looking click that writes a priced feature row into the database. Menu labels move between Enterprise Manager 13.4, 13.5 and the 24ai release, while the pack boundaries stay put, so check the licensing chapter for the exact release you run.

Why should you review all five database packs together?

The Cloud Management Pack is one of five priced database packs that self enable the same way. Reviewing it alone is how a second finding arrives six months after the first. Confirm current figures on the Oracle Technology Price List before you build a business case.

Diagnostics is usually the gateway, because the performance pages depend on it, and Tuning arrives with it since Tuning cannot be licensed on its own. The mechanics of that pair are in our Diagnostics and Tuning pack guide, and the CONTROL_MANAGEMENT_PACK_ACCESS parameter in this guide to suppressing them. Masking has its own Data Masking pack guide.

How do you check whether Cloud Management Pack usage is recorded?

Pull two records and compare them. The database keeps its own count in DBA_FEATURE_USAGE_STATISTICS, and Enterprise Manager keeps a separate one in its repository, including which packs are granted on each target. When they disagree, the database version wins, because that is what Oracle reads.

The database view records feature names, never product names. Its rows read Automatic Workload Repository or SQL Tuning Advisor, and the view does not tell you which priced pack a row belongs to. An internal review that reads the raw view therefore goes wrong.

What does Oracle's usage script show?

Oracle publishes the mapping from feature rows to priced products in options_packs_usage_statistics.sql, attached to My Oracle Support Doc ID 1317265.1. It prints a PRODUCT USAGE summary, including a line for the Cloud Management Pack, above a FEATURE USAGE DETAILS section. Read the detail as well as the verdict.

A homemade spreadsheet of the mapping is worse than none, because row names change between releases.

• Force a sample first. The sampling job runs weekly under MMON, so a database restarted or patched this week can read empty. Run DBMS_FEATURE_USAGE_INTERNAL.EXEC_DB_USAGE_SAMPLING before you trust the output.
• Query every container. On a container database the standard view shows only the container you are connected to. Query CDB_FEATURE_USAGE_STATISTICS joined to V$CONTAINERS, or you will miss a pluggable database that ran the feature and arrived with its own history.
• Read FIRST_USAGE_DATE carefully. It sets how far back a claim for backdated support reaches, which makes it the most expensive value in the row.
• Quote DETECTED_USAGES with its denominator. The ratio of DETECTED_USAGES to TOTAL_SAMPLES separates a three click demo from production use. CURRENTLY_USED reflects only the most recent weekly sample.
• Check ENABLE_DDL_LOGGING. Oracle licenses this initialization parameter as part of Database Lifecycle Management when it is set to TRUE, so a database with it set to TRUE needs that pack licensed.

What does the Enterprise Manager repository hold?

Enterprise Manager records the pack grants per target, which you can review at Setup, Management Packs, Management Pack Access. Oracle's manual also lists the chargeback tables starting EMCT_CBA and the views starting EMCT$CBA as part of the Cloud Management Pack. If those hold rate plans and charge history, the portal was used for more than a demo.

Export the pack access state along with the name of whoever changed it last. That export and the database output together are your dated internal record. The wider family of scripts is covered in our compliance scripts guide, and the way packs appear in the view in this explainer on feature usage rows.

How do you switch off packs you do not own?

1. Go to Setup, Management Packs, Management Pack Access and turn off Auto Licensing.
2. Untick every pack that does not appear on an ordering document, for every target type. The EMCLI verb revoke_license_with_validation does the same across many targets.
3. Write down the date and the name of the administrator who made the change.
4. Wait one full weekly sampling cycle, force a sample, and confirm CURRENTLY_USED now reads FALSE for every row you expect.

How much does the Cloud Management Pack cost across a server fleet?

Per processor means cores multiplied by the value in the Oracle Processor Core Factor Table, counted across the managed databases. It does not mean per socket or per core. Check the current core factor table before anyone carries a figure into a meeting.

Take a hypothetical fleet of eight two socket servers with twelve cores per socket, and assume only two of the eight ever hosted the self service portal. The other six never ran a provisioning request.

Scoping the pack to 48 cores takes $540,000 off the cloud pack line, a 75 percent cut. It rests entirely on being able to show that the six other servers never registered the feature. On IBM POWER9 the same 192 cores need twice the licenses, so a platform decision made three years ago doubles the pack bill today.

Does Named User Plus make the pack cheaper?

Rarely, and only when the database underneath is licensed by Named User Plus. The pack lists at $150 per Named User Plus, and the 25 user per processor minimum on 96 processors gives 2,400 users, or $360,000. Oracle requires a pack to be licensed on the same metric as its database.

If those servers run Enterprise Edition per processor, the pack is per processor and the user figure is unavailable. Check the metric printed on your ordering document. The matching rule is worked through in our guide to pack and database user counts.

How do database clones and refreshes affect a pack finding?

Clones copy the usage history. Feature usage statistics live inside the database, not on the host, so restoring a production backup into a test environment carries the usage rows with it. The test system then shows a FIRST_USAGE_DATE it never earned, and it looks identical to real usage unless you can show where the copy came from.

Keep the refresh records. A dated ticket showing that server B was seeded from server A is the only thing that separates one instance of usage from two. Without it, an auditor counts both servers.

Is the refresh process itself pack usage?

It is when the refresh runs through Enterprise Manager. Oracle's manual places both Snap Clone and the refresh of full clones under the Cloud Management Pack, so refreshing test copies from the clone management pages uses it.

A refresh built with RMAN scripts outside the console does not touch those pages. Find out which method your DBAs run before Oracle asks.

What have we seen in recent Enterprise Manager pack reviews?

In the 30 to 40 Oracle reviews Fredrik Filipsson led in 2024 and 2025 where Enterprise Manager was part of the question, the pack was almost never a decision anyone had made. It was a checkbox left ticked, found years later by a script.

• 7 in 10 ran an unlicensed pack. That share of customers ran at least one priced pack with nothing on the ordering document to cover it, and every finding came from feature usage output.
• Usage predated the audit letter by 4 years. In one review, FIRST_USAGE_DATE ran that far back, traced to a proof of concept self service portal that was demonstrated and never torn down.
• Install defaults were still in place. Management Pack Access sat at its default in most of them, so opening the wrong console page was enough.
• No internal record existed. Not one had a dated report of its own pack position, so Oracle's script was the first measurement anyone had run.

An Oracle audit of Enterprise Manager packs does not discover anything. It reads back a record your own databases kept.

Why switching off pack access does not close the exposure

The usual advice after a scare is to untick the packs and consider the problem solved. We disagree with stopping there, because unticking only stops future usage. The rows already written stay in the database with their FIRST_USAGE_DATE, and you should never try to purge them.

The better course is to untick, record the date, and keep the output from before and after. Then build the scoping evidence for the servers that never ran the feature.

How do you reduce a Cloud Management Pack audit finding?

Scope it to the databases that actually ran the feature, then separate what the contract requires from what Oracle asks for. Oracle's opening position usually has three parts, and only the first is contractual.

• A license fee for the shortfall. The audit paragraph of your Master Agreement obliges you to pay fees applicable to use in excess of your license rights. It does not define those fees as list price.
• Backdated support. Negotiable. FIRST_USAGE_DATE sets how far back the claim reaches, so pull it and reconcile it against your clone records before Oracle does.
• Pricing at list. Also negotiable, since the contract names no price for the shortfall.

What will Oracle's team say, and how should you answer?

• "Feature usage shows the pack on all eight servers." Answer with the DETECTED_USAGES to TOTAL_SAMPLES ratio per server and the refresh tickets showing which servers inherited rows from a restore.
• "Enterprise Manager manages the whole fleet, so the whole fleet needs the pack." The pack is counted on the managed databases where it was used. Show the pack access export and the usage output by target.
• "The pack requires Database Lifecycle Management, so both lines apply." The prerequisite is real. Check whether you already own that pack, and hold both lines to the same scoped servers.
• "Settle at list now and we will discount a new purchase." Ask for the shortfall to be priced at the discount on your existing ordering documents, since the contract does not specify list.
• "Backdated support is standard policy." Ask where it appears in your agreement. Treat it as a negotiated item, and test the start date against the clone records.

What contract wording should you ask for?

• A defined fee basis. Settlement pricing tied to the net discount on your current ordering documents, so the shortfall is not priced at list by default.
• A named scope. The servers and databases the purchase covers, written into the settlement, so the remaining six cannot be reopened in the next review.
• A release of claims. A statement that the settlement closes all use of the reviewed packs up to its effective date.
• A price hold on the prerequisite. Database Lifecycle Management at the same discount if you later extend the portal to more servers, because you cannot add the cloud pack without it.

For the full response sequence after a letter arrives, see our Oracle audit guide. The three way reconciliation of ordering documents, deployments and usage output is covered in the license information guide.

Which mistakes make a pack finding larger than it should be?

Each of these errors adds cost that the usage itself did not require, and each is cheap to avoid.

• Letting Oracle run the first measurement. Without your own dated output, you cannot challenge theirs.
• Reading only the PRODUCT USAGE line. The verdict hides whether usage was one demo or two years of production.
• Checking one container. A pluggable database moved in from elsewhere brings its own history.
• Discarding refresh tickets. Without them, every clone counts as a separate instance of usage.
• Forgetting the prerequisite. Budgeting for the cloud pack alone, then receiving a claim for the lifecycle pack on the same processors.
• Treating one pack at a time. The Diagnostics or Lifecycle finding follows a few months later.

A regular review cadence prevents most of these, and our Oracle SAM guide sets one out.

What to do next

1. This week. Turn off Auto Licensing, set Management Pack Access to deny by default, untick every pack not on an ordering document, and record the date.
2. This month. Force a sample and run options_packs_usage_statistics.sql on every managed database, keeping both PRODUCT USAGE and FEATURE USAGE DETAILS in a dated file.
3. Same day as the script. Export the Management Pack Access state and note who changed it last.
4. Next. Match each flagged database to an ordering document line by metric and quantity, and file unmatched rows with their DETECTED_USAGES ratio and a named owner.
5. Ongoing. Keep clone and refresh lineage records, so an inherited FIRST_USAGE_DATE on a test copy is never counted as separate usage.
6. Before any negotiation. Scope the exposure to the servers that ran the feature, include the Database Lifecycle Management prerequisite, and read the actual audit clause on your agreement. Our Oracle practice can run the review and the response with you.

Frequently asked questions