The Oracle EBS Restricted Use Database Licence

What is the EBS restricted use database licence?

Every EBS deployment runs on an Oracle Database, and Oracle includes a licence for that database in the application licence. Crucially, the included licence is restricted, sometimes described as application specific full use. It permits the database to be used in support of the licensed E-Business Suite application and nothing else. You may run, patch, and administer the database for EBS. You may not use it as a general purpose database for other workloads, custom applications, or third party tools.

The restriction matters because the database, if it were licensed for full use, is the most expensive component in the stack. It is licensed on a capacity metric, Processor times core factor, so a single voided restriction on a large server can generate a claim larger than the entire application user shortfall. This asymmetry is why the technology stack, not the application, is where the biggest EBS findings sit, a point made in the EBS licensing pillar and developed here.

What the grant covers

The restricted grant covers the database functionality EBS itself requires to run. That includes the standard database engine and the specific options and features EBS uses as part of its certified configuration. It does not cover database options that happen to be installed but are not part of the EBS requirement, and it does not cover any use of the database by anything other than the application.

The activities that void the restriction

The restriction is voided not by intent but by activity. The four most common voiding patterns are: building custom schemas in the EBS database for functionality that is not part of EBS, which also creates the custom application exposure covered in the custom application article; pointing third party reporting or analytics tools directly at the EBS database rather than through the application; enabling database options not required by EBS, which Oracle's scripts detect regardless of whether they are used; and consolidating other databases onto the same instance to save licences.

Each of these is a routine engineering decision that feels harmless and is, in licensing terms, the most expensive thing the team can do. The reporting tool case is especially common, because connecting business intelligence directly to the transactional database is standard practice everywhere except where the database is restricted use.

Restricted use and virtualisation

If the restriction is voided and a full use database licence is required, the capacity metric brings the partitioning policy into play. On a virtualised platform, Oracle will assert that every physical core the database could run on must be licensed, exactly as for any database. A voided restriction on a database hosted in a large VMware cluster therefore compounds: the conversion to full use is multiplied by the soft partitioning core count. The EBS on VMware article works through that interaction, and the underlying capacity rules are in the database licensing pillar.

This compounding is why the restricted use database is the finding to prevent rather than to argue after the fact. Once the restriction is voided on a large virtualised host, the claim can be enormous, and the argument shifts to the partitioning policy rather than the restriction itself.

How to protect the restriction

Protecting the restriction is a discipline of separation. Keep non EBS workloads off the EBS database. Route reporting and analytics through the application or through a separately licensed database, not directly against the EBS instance. Audit which database options are enabled and disable any not required by EBS. And document the configuration so that, in an audit, you can demonstrate the database is used only in support of the application. Where business needs genuinely require full use, license it deliberately and price it, rather than voiding the restriction by accident.

This review is a core part of every EBS baseline. The applications licensing practice assesses the restriction as standard, and where a database finding has already landed, the audit defence practice argues the scope and the partitioning position.

The buyer side view

The restricted use database is the EBS finding that customers regret most, because the voiding activity felt like good engineering and the cost is the highest in the estate. The buyer side discipline is to treat the EBS database as ring fenced: nothing runs on it but EBS, nothing queries it but EBS, and no option is enabled that EBS does not require. That discipline preserves the single most valuable concession in the application licence, the inclusion of an otherwise very expensive database.

Where the business genuinely needs more, license it on purpose and on your timetable. The mistake is never needing full use; it is acquiring it by accident and discovering it in an audit. To review your restricted use position before Oracle does, request a consultation.

How Oracle detects a voided restriction

Oracle detects misuse of the restricted database through the same measurement scripts it runs for any database audit. Those scripts enumerate the schemas present, the options and features enabled, the sessions and programs connecting, and the objects that do not belong to the EBS data model. A custom schema stands out immediately because it is not part of the certified EBS footprint. A third party tool shows up as sessions from a non application source. An enabled option appears in the feature usage tables whether or not it is actively used.

The implication is that the voiding activity leaves a permanent, discoverable trace. There is no version of this in which the misuse is invisible; the database records it. This is why the only effective control is prevention rather than concealment: keep the database clean, because anything added to it will be found. The detection mechanics are identical to those described in the database licensing pillar, applied to the specific question of whether the EBS database is being used beyond the application.

One nuance frequently catches customers out: options enabled by default or during installation, never used, still appear in the feature usage tables and are read by Oracle as in use. The restricted grant covers only what EBS requires, so an option switched on by a database administrator out of habit, with no EBS need, is a finding waiting to be made. Auditing and disabling unused options is therefore part of protecting the restriction, not an optional housekeeping task.

Remediating a voided restriction

When a restriction has already been voided, the remediation path depends on whether the offending use is needed. If a third party tool was querying the database directly, the cleanest fix is to re route it through the application or a separately licensed reporting database, removing the direct access and the basis for the full use claim going forward. If a custom schema is genuinely required, the choice is to migrate it to a separately licensed database or to license the EBS database for full use deliberately, on terms negotiated rather than imposed.

The commercial difference between finding the problem yourself and having Oracle find it is large. Self discovered, it is a forward looking remediation with no penalty and full control of the timing. Audit discovered, it is a backward looking claim on Oracle's capacity metric, potentially multiplied by the virtualisation boundary covered in the EBS on VMware article, and negotiated under pressure. The entire value of a proactive restricted use review, run by the advisory team, lies in being the party that finds it first.