An Oracle Database Appliance ships with both revenue packs armed and all cores active, so your estate accrues audit evidence from day one. This subpage names exactly what is on, how automation re-enables it, and the strip-and-prove sequence to run before Oracle counts.
An Oracle Database Appliance ships with both revenue packs armed and all cores active, so your estate accrues audit evidence from day one. This subpage names exactly what is on, how automation re-enables it, and the strip-and-prove sequence to run before Oracle counts.
An Oracle Database Appliance does not arrive licensing-neutral. Two independent defaults stack on top of each other, and each one alone is enough to generate a seven-figure audit claim on a mid-sized estate. First, every Enterprise Edition database created on the appliance ships with the Diagnostics Pack and Tuning Pack armed. Second, ODA deployment activates all physical cores on the box unless you (not Oracle, not the automation) apply capacity-on-demand. Multiply the two together and you have the single most common ODA audit finding we defend: packs used casually by a DBA, priced against a core count nobody intended to license.
The controlling database parameter, CONTROL_MANAGEMENT_PACK_ACCESS, defaults to DIAGNOSTIC+TUNING on Enterprise Edition. From the moment the database opens, AWR snapshots are collected automatically every 60 minutes. If you have not bought the packs, the database is writing usage evidence into the exact views an auditor reads, before anyone logs in to do anything. For the full mechanics of how the packs price and detect, read the Diagnostics and Tuning Pack auto-use guide. This subpage focuses on what the ODA platform specifically does to you.
On an ODA, the packs are on and the cores are all lit. You are accruing audit evidence against your maximum possible license count before a single query runs.
Below is the default-enabled inventory that matters at audit. Note that not everything on this list carries a cost, but everything on it either costs money directly or shapes the evidence an auditor uses. Treat it as your post-deployment checklist.
| Item | Default state on ODA | License impact | Action |
|---|---|---|---|
| Diagnostics Pack | Enabled (CONTROL_MANAGEMENT_PACK_ACCESS = DIAGNOSTIC+TUNING) | ~$7,500/proc list; priced on full licensed processor count | Disable unless entitled |
| Tuning Pack | Enabled (same parameter, mandatory pair with Diagnostics) | ~$5,000/proc list; cannot be licensed without Diagnostics | Disable unless entitled |
| All physical cores | Active with hyper-threading on at deployment | Full EE + option cost against every active core | Apply CoD via odacli modify-cpucore |
| Standard Edition High Availability | Enabled by default on SE2 single-instance DBs | Included in SE2 entitlement, but changes clustering posture | Disable if not required |
| Unified auditing | Enabled for new DB homes | No license cost; produces the audit trail | Leave on, use as evidence |
The Diagnostics and Tuning Packs are the money items. Both are on in Enterprise Edition, and the Tuning Pack cannot be licensed without the Diagnostics Pack. They are a mandatory pair, so any strategy that keeps one and drops the other is not available to you. It is both or neither.
The dangerous property of these packs is that there is no separate installation step and no gate. The capability is already present. A DBA running an AWR report, opening an Enterprise Manager performance page, or invoking the SQL Tuning Advisor consumes the pack immediately. The database does exactly what it is asked and writes the usage into DBA_FEATURE_USAGE_STATISTICS. That row is permanent evidence. You cannot un-trigger it by later disabling the parameter; the historical record persists and an auditor will read it.
In our experience across ODA audits, this is where clients lose the argument before it starts. The DBA who ran one AWR report to diagnose a slow batch job had no idea a license question existed. Oracle's own data supports the pattern: independent licensing analysis puts accidental Diagnostics Pack enablement at more than 40 percent of enterprise Oracle environments. On an ODA, where the packs are on by default, that number is effectively the baseline until you intervene.
Here is the mechanic that turns a minor DBA action into a seven-figure claim. Pack findings scale with the licensed processor count, not with how often the feature was used. A single AWR report on a 16-processor cluster implies 16 processor licenses for each pack, plus back support. Frequency is irrelevant. The auditor prices the full footprint of the database, once, permanently.
Now layer the ODA core default on top. An ODA X10-HA has two servers of 64 cores each, and on deployment all 128 cores are active with hyper-threading enabled. The X10-S and X11-S ship 32 cores fully active. Capacity-on-demand exists precisely to turn cores off and cut the Enterprise Edition license cost, but you must apply it. Oracle does not deploy the appliance in a reduced state. If you skipped CoD, or if you did apply it but the number silently reverted (covered below), your entire physical core count becomes the multiplier for every pack finding. The full CoD lever is documented in our capacity-on-demand core activation explainer, and the strategic cost trade-offs sit in the ODA licensing buyer guide.
A single AWR report on 16 processors implies 16 pack licenses plus back support. On a 50-processor estate over three years, that is roughly $4.93M.
The numbers below are from the Oracle Technology Price List, 2026, and from a published worked audit claim. We use them to show the scale, not because your discount will match list. Enterprise Edition itself lists at $47,500 per processor. The Diagnostics Pack lists at approximately $7,500 per processor ($150 per Named User Plus) and the Tuning Pack at approximately $5,000 per processor ($100 per NUP). Combined, the two packs add roughly $12,500 per processor, about a 25 percent surcharge on the EE base. Support runs at 22 percent of net license price per year and Oracle typically increments it annually.
| Item | 2026 list per processor | Support at 22%/yr |
|---|---|---|
| Enterprise Edition base | $47,500 | $10,450 |
| Diagnostics Pack | $7,500 | $1,650 |
| Tuning Pack | $5,000 | $1,100 |
| Both packs combined | $12,500 | $2,750 |
The retroactive claim is where it bites. A published example for a 50-processor deployment: a three-year Diagnostics Pack back-claim represents approximately $2.97M in license fees plus $1.96M in back support, a $4.93M finding for a feature set the DBAs used without any awareness of the license requirement. That is one pack, on one estate, from casual use. The Tuning Pack, being the mandatory partner, typically rides in on the same finding. If you are weighing whether Enterprise Edition even makes sense at your scale, the Standard Edition 2 versus Enterprise Edition comparison is the first decision to settle, because SE2 removes the pack question entirely.
This is the ODA-specific failure mode that catches even disciplined shops. Patching your ODA can re-enable all cores on the server without any warning. Your configuration then no longer complies with your licenses, and you may not notice until an auditor does. This is not theoretical: two independent practitioners documented it, one in 2022 and one in 2025, the latter reporting that a core reset was required after patching unexpectedly re-enabled all available cores. The mechanism is that patch operations can reset the CPU core configuration to the appliance default, which is all cores active.
The consequence compounds with the pack problem. If patching quietly relights all 128 cores on an X10-HA and any database on that box has ever triggered a pack, your finding is now priced against 128 cores, not the 40 or 60 you thought you licensed. The buyer-side rule is simple and non-negotiable: treat every patch as a licensing event.
Disabling is one command, but the detail that costs people money is persistence. On every database not entitled to the packs, run: ALTER SYSTEM SET control_management_pack_access=NONE scope=both; If you omit scope=both, the parameter reverts to its original value on the next restart and you are silently re-armed. Set it on every EE database on the appliance, not just the production ones, because dev and test databases generate feature-usage rows that auditors count identically.
Then close the second door. Restrict pack access inside Enterprise Manager so administrators cannot trigger use by accident through the console. Setting the parameter blocks the database-level path; restricting EM blocks the GUI path. You need both, because a DBA who opens a performance page in Cloud Control can consume the pack even when they never touch SQL*Plus. If your ODA runs virtualized under KVM, confirm the parameter is set inside each guest database, not just at the host, and see the virtualized ODA KVM license count guide for how the VM boundary interacts with these settings.
Disabling forward is necessary but not sufficient. Oracle's claim is retroactive, so you must be able to demonstrate the historical state of usage. The view that decides your finding is DBA_FEATURE_USAGE_STATISTICS. Read it before Oracle does. Query it on every database and record, per pack, whether any usage was ever detected, the first and last usage dates, and the current usage flag. This is your evidence file, and it should be generated on a schedule and archived, not produced reactively when the audit notice lands.
Where the view shows historical usage you cannot deny, that is a negotiation problem, not a technical one, and it is where independent advisory earns its fee. Where the view shows no usage and you have the parameter set with scope=both plus EM restricted, you have a clean, defensible position. The strip-and-prove sequence below is the one we run on every ODA engagement.
One closing point on scope. The packs are the loudest default, but they are not the only option that prices on the full processor count. Partitioning, Multitenant, Advanced Compression, and RAC each carry their own per-processor charge and each can be triggered on an ODA. Before you sign a renewal, inventory every option in use across the appliance against the options and packs audit-trap reference, because the packs are usually just the first line item Oracle finds, not the last.
Yes. Any Enterprise Edition database created on an ODA ships with CONTROL_MANAGEMENT_PACK_ACCESS set to DIAGNOSTIC+TUNING, which arms both packs. AWR snapshots start collecting every 60 minutes automatically. If you have not bought the packs, the database is generating unlicensed-usage evidence from the moment it opens.
Yes. ODA deployment activates all physical cores with hyper-threading enabled by default. An X10-HA lights all 128 cores; an X10-S or X11-S lights all 32. Capacity-on-demand exists to reduce that, but you must apply it yourself using odacli modify-cpucore, which requires a reboot of all nodes.
Yes, and this is a documented, real-world trap. Patching can silently reset the ODA to all cores active with no warning, putting you out of license compliance without any visible change. Add a post-patch check comparing lscpu output against your odacli configuration, and re-apply your capacity-on-demand limit if the count reverted.
Run ALTER SYSTEM SET control_management_pack_access=NONE scope=both on every database that is not entitled to the packs. The scope=both clause is critical; without it the parameter reverts on the next restart. Then restrict pack access inside Enterprise Manager so administrators cannot trigger use through the console.
Query DBA_FEATURE_USAGE_STATISTICS on every database and archive the output with timestamps. That is the exact view Oracle reads to build a finding. Where it shows no usage and you have the parameter set with scope=both plus EM restricted, you have a clean, defensible position. Baseline it now, before an audit notice arrives, not reactively.
Findings scale with licensed processor count, not usage frequency. A single AWR report on a 16-processor cluster implies 16 pack licenses plus back support. A published example for a 50-processor deployment showed a three-year Diagnostics Pack claim of roughly $2.97M in fees plus $1.96M in back support, a $4.93M finding from casual use.
The separately-licensed options and packs that ship enabled by default, get switched on with a single click, and become the single largest line item in most Oracle audit findings.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
