The Oracle Database that ships inside your Siebel deal is not a gift, it is a fenced grant that Oracle can reprice to full list the moment you cross the fence. This guide names the exact triggers, quantifies the exposure at 2026 list prices, and tells you what to lock down before the auditor arrives.
The Oracle Database that ships inside your Siebel deal is not a gift, it is a fenced grant that Oracle can reprice to full list the moment you cross the fence. This guide names the exact triggers, quantifies the exposure at 2026 list prices, and tells you what to lock down before the auditor arrives.
Most on-premises Siebel deployments include a restricted-use Oracle Database and, in some estates, restricted-use middleware licenses. The restricted-use grant is bundled at no separate license cost, which is precisely why buyers underestimate it. The grant is not a discount on a full license. It is a different license entirely, with a scope boundary Oracle enforces through audit. Oracle sometimes labels this construct Application Specific Full Use (ASFU) or restricted use, and the mechanics are the same in either case: the database runs only the named application, and only the workloads that application supports.
Here is the point that catches technical teams off guard. The restricted-use database is the identical binary as the full-use Oracle Database Enterprise Edition. Nothing in the software stops a DBA from creating a custom schema, pointing a BI tool at the instance, or loading non-Siebel data. The restriction lives entirely in the contract, not in the code. That gap between what is technically possible and what is contractually permitted is the single largest source of unbudgeted Oracle exposure in Siebel estates. For the full context of how Siebel itself is metered, read our Siebel CRM licensing buyer guide.
The original Oracle definition of restricted use, going back to the ASFU framework, is blunt: you deploy the underlying products as is and out of the box, with no modification of the underlying database that would extend it beyond serving the named application. In practice, Oracle reads that narrowly. Reporting queries that hit the Siebel schema through a third-party tool, integration jobs that write another application's data into the same instance, and DBA scripts that serve operational reporting all sit outside the fence in Oracle's interpretation.
The restricted-use database is the same binary as full Enterprise Edition. The only thing standing between you and a full-price bill is the contract clause, and Oracle audits it aggressively.
A restricted-use or ASFU database converts to a full-use obligation the moment any workload outside the named Siebel application touches that instance. Based on Oracle's published audit practice and 25 years of watching these claims land, the recurring triggers are consistent and predictable.
Any one of these creates an unlicensed use position. Oracle's remedy is not a warning. It is a demand to purchase a full-use Oracle Database Enterprise Edition license at standard list, calculated across all processors in scope. This is the same mechanic we document in our Oracle ESL audit defense page, where embedded and restricted scope breaks the same way.
Note the edition subtlety. There is no contractual requirement that the underlying Siebel database be Enterprise Edition. You can run Standard Edition 2 where your architecture allows it, which materially changes the conversion math (SE2 lists at roughly $17,500 per processor unit versus $47,500 for Enterprise Edition). If your restricted-use grant is Enterprise Edition and your actual need is smaller, that is a leverage point, not a fact to accept passively.
When restricted use breaks, the bill is built from Oracle's full-use list prices, not from your bundled zero. These are the numbers that convert a schema mistake into a seven-figure claim. All figures below are current 2026 list prices before any negotiated discount.
| Component | List price per processor | List price per NUP | Annual support (22%) |
|---|---|---|---|
| Database Enterprise Edition | $47,500 | $950 | $10,450 / proc |
| Standard Edition 2 | ~$17,500 | ~$350 (min 10 users/server) | ~$3,850 / proc |
| Partitioning option | $11,500 | n/a | $2,530 / proc |
| Real Application Clusters (RAC) | $23,000 | n/a | $5,060 / proc |
| Diagnostics Pack | $7,500 | $150 | $1,650 / proc |
| Tuning Pack (requires Diagnostics) | $5,000 | $100 | $1,100 / proc |
Two multipliers make the processor count larger than your intuition. First, the Intel/AMD core processor licensing factor of 0.5 means a 16-core server counts as 8 processors for licensing. Second, Enterprise Edition carries a Named User Plus minimum, typically 25 NUP per processor. A 16-core Intel server licensed under NUP requires a minimum of 16 x 0.5 x 25 = 200 NUP at list, which is $190,000, even if your real user count is 50. The NUP minimum does not care about your actual population, and that is where conversion costs balloon. Our full breakdown lives in the Oracle Database license cost 2026 reference.
Support is the quiet compounder. Oracle Enterprise Support runs 22 percent of net license value per year under both the restricted and the full-use model. The restricted-use discount does not reduce your ongoing support cost once you convert, and any retroactive purchase carries compounded support from the first-used date.
A 16-core Intel server converted to full Enterprise Edition under the NUP minimum costs $190,000 in license alone, before options, before support, before back-dating.
Even inside a properly scoped restricted-use grant, the database options are a separate trap. Options such as Partitioning, RAC, Diagnostics Pack, and Tuning Pack are not included in the Siebel bundle and are not covered by restricted use. They are licensed separately at full processor rates, and Oracle detects their use automatically.
The detection mechanism is unforgiving. Oracle's automatic feature tracking records every option ever used on every database, and the usage view retains history for the life of the database. A single test query that touched the Tuning Pack two years ago sits in that view permanently, and Oracle LMS auditors examine it as standard practice. Field data indicates the Diagnostics Pack is accidentally enabled in more than 40 percent of enterprise Oracle environments, usually because it is on by default and no one set the guardrail.
When an option is detected, Oracle asks you to license it retroactively from the first detected use, plus 22 percent support compounded across every intervening year. On a large cluster, an accidentally triggered pack routinely produces a seven-figure opening claim on the option alone. The Diagnostics and Tuning packs are the most common offenders in Siebel estates because performance teams reach for AWR reports and the SQL Tuning Advisor without checking the license status.
The remediation is cheap and specific. Either license Diagnostics on every database that needs it, or set the initialization parameter CONTROL_MANAGEMENT_PACK_ACCESS to NONE on every Siebel database that does not require the packs. Do this before your next audit cycle, not after.
If restricted use breaks on a virtualized platform, the conversion cost is not scoped to the VM running Siebel. Oracle's position is that you must license every physical processor in the cluster unless you use an Oracle-approved hard partitioning technology (Oracle VM configured correctly, or Solaris Zones). VMware, Hyper-V, and KVM are all treated as soft partitioning, which means the entire cluster is in scope.
The math is punishing. Oracle running on four hosts inside a 32-host VMware cluster requires licenses on all 32 hosts in Oracle's reading. A restricted-use grant that would have covered the Siebel workload, once broken, converts against the full cluster footprint. This is the same soft-partitioning exposure we detail in our VMware licensing analysis, and it is the reason we push Siebel clients to isolate Oracle workloads onto dedicated, hard-partitioned, or physically separate hosts.
Disaster recovery adds a further layer. Oracle wants full licenses for DR and failover environments that are powered on, even when they are cold standby and used only in a genuine disaster. Powered on but inactive still requires licensing in Oracle's view. A Siebel DR node sitting in a VMware cluster, powered on for readiness, can therefore drag the entire secondary cluster into scope. Audit your DR posture against the same restricted-use fence you apply to production.
When Oracle audits a Siebel estate and finds ASFU misuse, the claim is constructed to maximize pressure. It back-dates the license value to the first-used date from the feature-usage history, adds compounded 22 percent support, and scopes processors against the widest defensible cluster boundary. That is how a modest technical mistake produces a large opening number.
The opening number is not the settlement number. Across engagements, the average Oracle audit claim runs three to five times what the customer actually owes once the license grant is properly reconstructed and challenged. The gap comes from Oracle scoping against cluster-wide processor counts you can narrow, back-dating first-used dates you can dispute, and asserting misuse that a careful review of the actual workloads does not support. Before you concede anything, build the evidence pack described in our Siebel audit defense evidence pack guide.
The average Oracle audit claim runs three to five times what the customer actually owes. The opening demand is a negotiating position, not a bill.
Restricted-use exposure is manageable, but only with proactive controls. Waiting for the audit letter forfeits your leverage. Take these steps in order.
Two adjacent risks deserve the same discipline. Siebel module sprawl and user-metric errors surface in the same audits, so pair this database review with our analyses of Siebel module sprawl audit findings and the Application User versus Employee metric. Restricted-use database exposure rarely arrives alone.
No. It is a restricted-use or ASFU grant limited strictly to the Siebel application and the workloads Siebel supports. The bundle carries no separate license fee, but the moment you run non-Siebel workloads on it (custom schemas, external reporting, other applications), you owe a full-use license at standard list. The zero cost applies only inside the fence.
Oracle Database Enterprise Edition lists at $47,500 per processor or $950 per Named User Plus in 2026, plus 22 percent annual support. The Intel/AMD 0.5 core factor and the 25 NUP-per-processor minimum inflate the count, so a 16-core server can cost $190,000 in license under the NUP minimum alone. Standard Edition 2, at roughly $17,500 per processor, is far cheaper where your architecture permits it.
Through the automatic feature-usage tracking view, which records every database option ever used and retains that history for the life of the database. Oracle LMS auditors examine it as standard practice. They also inspect schemas, connections, and workloads during audit interviews to identify non-Siebel use of the instance.
No. Options and management packs are licensed separately at full processor rates and are never covered by restricted use. The Diagnostics Pack is accidentally enabled in more than 40 percent of Oracle environments, and Oracle bills for it retroactively from first detected use plus compounded support. Set CONTROL_MANAGEMENT_PACK_ACCESS to NONE on databases that do not license the packs.
Potentially the entire cluster. Oracle treats VMware, Hyper-V, and KVM as soft partitioning and requires licensing every physical processor in the cluster, not just the VM running Siebel. Four hosts in a 32-host cluster can pull all 32 into scope. Isolate the Siebel database or use Oracle-approved hard partitioning to contain this.
A great deal. Across engagements, the average Oracle audit claim runs three to five times what the customer actually owes once the license grant is reconstructed and the scope challenged. Oracle back-dates to first-used dates and scopes against the widest cluster boundary as an opening position, not a settlement figure. Never treat the first number as the bill.
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.
