E-Business Suite is an application, but it runs on an Oracle database, and that database tier is licensed and charged separately from the application modules. Buyers who think of EBS as a single licensed product often overlook the database tier and discover its cost only when an audit examines the processors the database runs on or the options the EBS schema invokes. The database tier beneath EBS is where some of the largest and most surprising exposure sits. This note sets out how EBS database licensing works, where the hidden exposure arises, and how the buyer should manage it in a negotiation.
Two licences, one system.
An EBS deployment combines two distinct Oracle licence positions. The application tier is the EBS modules themselves, licensed on the application metrics discussed in the Apps Unlimited pricing note. The database tier is the Oracle Database that stores and processes the EBS data, licensed on the database metrics of Named User Plus or Processor. The two are bought, charged, and audited separately, and a buyer who manages only the application tier leaves the database tier unmanaged.
The separation matters because the database tier can be the larger cost. A substantial EBS deployment runs on a substantial database, and the processor licensing of that database, together with any options it uses, can exceed the application licence cost. The buyer who maps only the application estate underestimates the total EBS cost and the total audit exposure.
The licensing metric.
The Oracle Database beneath EBS is licensed on the same metrics as any other Oracle database, the Named User Plus metric for smaller or countable user populations and the Processor metric for larger or uncountable ones. For an EBS deployment serving a large user base or accessed by external parties, the Processor metric usually applies, and the cost is then driven by the processor count of the database servers and the Oracle core factor that applies to them.
The buyer must understand which metric applies and how the processor count is calculated, because the calculation is where audits find shortfalls. For the detail of how Oracle counts users under Named User Plus see the Named User Plus counting note, and for the database product context see the Oracle Database product page.
The options trap.
The largest hidden exposure in the EBS database tier is the use of database options that are licensed separately from the base database. Options such as partitioning, advanced compression, advanced security, and diagnostics and tuning packs are charged on top of the base database licence, and the EBS schema or the database administrators may invoke them without the buyer realising that each invocation creates a licence requirement. An audit that finds an option in use without a licence produces a claim that can dwarf the base database cost.
The partitioning option is a particular trap because EBS itself can use partitioning in its standard schema, and the diagnostics and tuning packs are a trap because they are enabled by default in many database installations. The buyer should audit the options in use against the options licensed before any negotiation. For the compression option in particular see the advanced compression pricing note.
The virtualisation question.
Where the EBS database runs on a virtualised platform, the licensing question becomes the soft partitioning question that Oracle uses to claim licences for the entire physical cluster rather than the virtual machines the database runs on. An EBS database on VMware can attract a licence claim covering every host in the cluster, which transforms a modest database footprint into a large licence requirement. The buyer who virtualises the EBS database without understanding the Oracle position on soft partitioning creates a substantial latent exposure.
The defence is to understand the Oracle position and to architect the deployment so the exposure is contained, through dedicated clusters or other measures that limit the hosts on which the database can run. For the full treatment of this risk see the VMware soft partitioning note.
The disaster recovery exposure.
EBS deployments typically include a disaster recovery database, and that standby database raises its own licensing question. Oracle policy permits a limited use of a standby for failover testing without a separate licence, but a standby that is actively used, that runs reporting, or that exceeds the permitted testing days requires its own full licence. The buyer who maintains a warm or active standby without licensing it creates an exposure that an audit will find.
The disaster recovery exposure is easy to overlook because the standby does no productive work in normal operation, but the Oracle policy turns on how the standby is used rather than whether it is normally idle. The buyer should review the disaster recovery configuration against the Oracle policy before any negotiation. For the broader compliance posture this sits within see the compliance posture note.
The audit exposure.
The EBS database tier is a frequent target of Oracle audits because it combines several of the exposures that audits seek, the processor counting, the options usage, the virtualisation question, and the disaster recovery configuration. An audit of an EBS estate that examines only the application tier is incomplete from the Oracle perspective; the database tier is where the larger claim usually lies. The buyer should prepare the database tier for audit with the same care as the application tier.
The preparation is to map the database deployment, the processor counts, the options in use, the virtualisation architecture, and the disaster recovery configuration, and to reconcile each against the licence entitlement. The buyer who has done this work defends the audit from evidence. For the audit posture see our audit defense service and the EBS Negotiation pillar.
Managing the tier in a negotiation.
In a negotiation the database tier should be addressed alongside the application tier rather than as an afterthought. The buyer who negotiates the EBS renewal without addressing the database tier leaves the database cost and exposure unresolved. The buyer who addresses both can structure a position that controls the total EBS cost and resolves the latent database exposure on favourable terms.
The negotiation can also resolve an options exposure by including the options in the deal rather than leaving them to be discovered in an audit, or by removing the options from use where they are not needed. The buyer who manages the database tier proactively turns a latent exposure into a managed cost. For the deal structures relevant to the database see the database licensing deal page, and for the complete framework read the Oracle Negotiation Playbook.
Engaging an independent advisor.
An independent advisor maps the EBS database tier as part of any EBS engagement. The advisor counts the processors, identifies the options in use, examines the virtualisation and disaster recovery configurations, and reconciles each against the entitlement so the buyer enters the negotiation knowing the true database cost and exposure. The advisor sits on the buyer side and structures the deal to control the database cost rather than to expand it.
A European industrial buyer engaged an advisor ahead of an EBS audit in 2024. The advisor discovered that the diagnostics and tuning packs were enabled by default across the EBS database estate without a licence, quantified the exposure, and structured a remediation that disabled the packs where they were not needed and licensed them where they were, resolving the exposure on terms far below the claim the audit would have produced.