The Oracle database bundled with Agile PLM is a restricted-use (ASFU) grant, not a full-use license, and the boundary is contractual, not technical. This page shows exactly what the license covers, where reporting and integration drift creates full Enterprise Edition exposure, and what to fix before an audit finds it.
The Oracle database bundled with Agile PLM is a restricted-use (ASFU) grant, not a full-use license, and the boundary is contractual, not technical. This page shows exactly what the license covers, where reporting and integration drift creates full Enterprise Edition exposure, and what to fix before an audit finds it.
When you licensed Agile PLM you almost certainly received an Oracle database under an Application Specific Full Use (ASFU) grant, sometimes labeled a restricted-use license on the Order Form. In 25 years of reading these order documents, I have found that most buyers never internalize what the label means: the Oracle software is complete Enterprise Edition or Standard Edition 2, identical in features and performance to a full-use install, but the right to use it is contractually confined to running Agile PLM and nothing else. You did not buy a general-purpose database. You bought a database that may only serve one named application.
The pricing tells you why the restriction exists. ASFU grants are sold at a deep discount, market sources report anywhere from 30 percent to as much as 80 to 90 percent below full-use list, precisely because the use is so tightly fenced. Oracle sells the same software cheaply on the understanding that you will never repoint it at anything else. The moment you do, the discount reverses into a full-use back-license claim at list price. For the broader picture on how Agile PLM licensing hangs together, our Agile PLM licensing buyer guide maps the metrics, modules, and audit exposure across the whole footprint.
You did not buy a database. You bought the right to run one application on Oracle software you may never repurpose.
This is the single most misunderstood mechanic in ASFU licensing. The license type is set on the Order Form at purchase and does not change because the technology changes. Move the database to a larger server, upgrade to Oracle 19c to run Agile 9.3.6, add cores, point a new tool at it: none of that alters the contractual boundary. It is a legal fence, not a software setting. That is exactly why so many compliance gaps sit undetected for years. Nothing in the database stops a DBA from connecting a BI tool or an integration; the software behaves identically. The breach is invisible until Oracle's scripts surface it.
Two practical consequences follow. First, an ASFU database does not quietly become a full-use database because you started using it more broadly. Oracle does not offer a tidy trade-up when it finds out. Second, because the restriction is contractual and the software is unrestricted, the burden falls entirely on you to police the boundary. No technical guardrail does it for you.
The permitted scope is narrow and specific. Under the ASFU grant tied to Agile PLM you may:
What the license explicitly forbids is where the exposure lives:
That last point deserves emphasis. Buyers routinely assume a read-only replica or a nightly extract sits outside the license because it does not touch the production instance. Oracle does not read it that way. Every reporting path is counted as use of the program, and a standby or replica of an ASFU database inherits the same restriction. If an external tool reads from it, that is out-of-scope use.
This is the core risk and it is worth stating plainly: the most frequent and least visible ASFU finding is a reporting layer or integration that simply reads the Agile PLM data. The pattern is predictable. The PLM data is valuable, it lives in the Oracle database, and so corporate BI tools, data-warehouse extracts, and custom dashboards get pointed at it because that is where the data is. Unless that reporting is delivered as part of the licensed Agile PLM application, it is a breach. These connections almost never show up on anyone's license radar until an audit detects them.
When Oracle's License Management Services (LMS) and GLAS teams audit an ASFU environment, they do not look at the whole estate the way they would with a full-use database. They target the boundary. Every tool, user, schema, and application touching the database is examined against the question: does this fall inside the named Agile PLM application? The classic finding is a reporting or integration layer that "just reads the data." Oracle classifies that as direct Oracle database use outside the grant and revalues it at full-use list.
The most expensive words in an Agile PLM audit are: it just reads the data.
The financial mechanics are punitive by design. When Oracle finds an ASFU database serving more than its named application, it does not offer a proportional true-up. It quotes the full-use back-license value at list price, plus back-support, often with limited or no credit for the ASFU spend you already made. Because you originally paid a deeply discounted ASFU price, the back-license claim can be several times the ASFU cost. This is one of the most expensive findings in any Oracle audit, and it lands on databases the buyer thought were fully paid for. Module and add-on exposure compounds it; our note on Agile PLM module sprawl in audits covers the application-side of the same problem.
To size the risk you have to price each at-risk database at full-use list arithmetic, including the permanent support step-up. These are Oracle's 2026 published list figures. Do the math on your own core counts before Oracle does it for you.
| Item | 2026 list price | Notes |
|---|---|---|
| Database Enterprise Edition | $47,500 per Processor | Or $950 per Named User Plus |
| EE Named User Plus minimum | 25 NUP per Processor | 10 NUP per server for SE2 |
| Partitioning option | $11,500 per Processor | Frequently enabled in PLM configs |
| Real Application Clusters (RAC) | $23,000 per Processor | If clustered for availability |
| Diagnostics Pack | $7,500 per Processor | Enabled by default in many configs |
| Tuning Pack | $5,000 per Processor | Separately licensable, DBA-reachable |
| Premier Support | 22% of net license fee | Annual, compounding, and back-billed in a claim |
Work a concrete example. A 16-core Intel server carries a 0.5 core factor, giving 8 processors. Under the Processor metric that is 8 x $47,500 = $380,000 for Enterprise Edition alone. Under Named User Plus the EE minimum of 25 NUP per processor forces 8 x 25 = 200 NUP at $950, which is $190,000 as a floor regardless of your actual user count. Add Partitioning at 8 x $11,500 = $92,000 and the Diagnostics Pack at 8 x $7,500 = $60,000, and a single mid-sized server clears half a million dollars in license before support. Layer 22 percent annual Premier Support on the net fee and the recurring cost compounds every year. For the full worked pricing model, see the 2026 Oracle Database license cost breakdown.
There is a second, independent trap that Oracle's scripts detect separately from the application restriction, and it stacks directly on top of an ASFU finding. The Diagnostics Pack ($7,500 per processor) and Tuning Pack ($5,000 per processor) are not included with Enterprise Edition, yet they are enabled by default in a large share of configurations. Market data indicates the Diagnostics Pack is accidentally active in more than 40 percent of enterprise Oracle Database environments. The features it gates, AWR, Active Session History, and ADDM, are exactly the tools a DBA reaches for when troubleshooting a slow PLM query.
The mechanism that makes this so dangerous is permanence. A single AWR report run by a DBA writes to DBA_FEATURE_USAGE_STATISTICS, a cumulative and permanent record. Usage cannot be deleted, reset, or reversed. Even if you disable the packs today, the historical usage remains visible to Oracle's audit scripts indefinitely. The only real defense is to set CONTROL_MANAGEMENT_PACK_ACCESS = NONE on every database that is not licensed for the packs, and to do it before any pack feature is ever accessed.
On an Agile PLM ASFU database this creates a two-part claim. Oracle asserts the application-boundary breach and revalues the database at full-use list, then it separately asserts pack licensing across the entire server based on the feature-usage evidence. You end up paying full-use EE plus separately-priced option back-licensing on the same box, plus back-support on both. Set the pack access parameter now; it is the cheapest control in this entire discussion.
Agile PLM 9.3.6, first released in January 2017, is the final release. Oracle confirmed in October 2023 that there will be no further version. Premier Support ends December 31, 2027, after which the product moves to Sustaining Support with no patches, no security fixes, and no meaningful technical support. Agile 9.3.6 runs on Oracle Database 19c, so the standard upgrade path installs 19c and rebuilds the Agile schema on it.
This deadline matters for the license conversation because it forces a decision window. Buyers evaluating the move to Fusion Cloud PLM, third-party support, or a controlled stay on 19c should resolve the ASFU boundary before they make any structural change. The worst outcome is walking into an audit or a migration negotiation with unmanaged reporting connections still live. If you are weighing the exit routes, our analyses of the Agile PLM to Fusion Cloud PLM migration and the third-party support decision both assume you have first sized and contained the database exposure described here.
Treat the ASFU boundary as an active compliance project, not a footnote. In practical order of priority:
The leverage in this situation is entirely about timing and evidence. Oracle's advantage is the permanent, machine-readable record its scripts read. Your advantage is that you can close the boundary and document the fix before an audit starts. Once a reporting connection or a pack usage entry exists, you are negotiating a claim; before it exists, you are managing a risk. The gap between those two positions on a single 16-core server is measured in hundreds of thousands of dollars.
No. It is an Application Specific Full Use (ASFU), or restricted-use, license. The software is complete Enterprise Edition or Standard Edition 2, but you may only use it to run Agile PLM. It is sold at a deep discount precisely because the use is confined to that one named application.
Only reporting that ships inside Agile PLM itself is permitted. Pointing an external BI tool, dashboard, or data-warehouse extract directly at the ASFU database is a breach. Oracle counts every reporting path, including read-only replicas and scheduled extracts, as use of the program.
Oracle does not offer a proportional true-up. It quotes the full-use back-license value at list price, plus back-support, often with little or no credit for your original ASFU spend. Because ASFU was deeply discounted, the claim can be several times what you paid, one of the most expensive findings in an Oracle audit.
They are not included with Enterprise Edition but are enabled by default in many configurations, and their features (AWR, ASH, ADDM) are what DBAs reach for. Usage is written permanently to DBA_FEATURE_USAGE_STATISTICS and cannot be deleted. Oracle can assert full pack licensing across the whole server on top of any ASFU claim.
Set CONTROL_MANAGEMENT_PACK_ACCESS = NONE on every database not licensed for the packs, and do it before any pack feature is accessed. Historical usage already in DBA_FEATURE_USAGE_STATISTICS cannot be reversed, so this control only prevents future exposure.
It sharpens the timing. Premier Support for Agile 9.3.6 ends December 31, 2027, forcing a decision on Fusion Cloud PLM, third-party support, or staying on 19c. Resolve and document the ASFU database boundary before any migration or audit, since the fix is far cheaper as a proactive control than as a negotiated claim.
Oracle Database 23ai bundles options you may never deploy. The buyer side guide to edition right sizing, option pruning, and AI Vector Search licensing.
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.
