Oracle bundles a restricted-use database with OBIEE to hold the RCU repository schemas, and the grant is narrower than almost any deployment team believes. This page maps exactly what the license covers, what voids it, and how a shared or expanded warehouse converts a free repository into a seven-figure full-use bill.
Oracle bundles a restricted-use database with OBIEE to hold the RCU repository schemas, and the grant is narrower than almost any deployment team believes. This page maps exactly what the license covers, what voids it, and how a shared or expanded warehouse converts a free repository into a seven-figure full-use bill.
Oracle's OBIEE Licensing Information document is explicit and narrow. The bundled Oracle Database is provided solely for use with the Oracle Repository Creation Utility (RCU) schemas that store OBIEE metadata. Oracle's own wording: the database is provided "for use with the Oracle Repository Creation Utility database schema for storing metadata, and storing any other data in the RCU database schema requires a full use license of the Oracle Database." There is no ambiguity in that sentence. The grant exists to run the product, nothing more.
In practice the RCU provisions a defined set of schemas. In OBIEE 11g the RCU created two, Metadata Services (MDS) and BIPLATFORM. In Oracle BI 12c that expanded to as many as nine repository schemas holding installation metadata, report scheduling, Usage Tracking, and auditing tables. The repository is mandatory across every version. Oracle BI 12c cannot run without a relational database repository created by the RCU against a selected database server. So the restricted-use database is not optional infrastructure you can decline; it is the plumbing that makes the product start, and Oracle prices its misuse accordingly.
The correct mental model: the restricted grant licenses the container for OBIEE's own metadata and nothing else. Every byte of business data, every reporting table, every ETL landing zone, every warehouse feed sits outside the grant. If you understand the metric decision that governs the BI application itself, review our analysis of OBIEE Named User Plus versus Processor licensing, but be clear that those metrics cover the BI software, not the database underneath the repository.
Oracle's restricted-use language across the entire application portfolio hangs on one word: "only." The universal trigger phrase in Oracle's Application Licensing Table (March 10, 2026) reads: "storing any other data in the database requires a full use license of the Oracle Database Enterprise Edition." The parallel grant in other Oracle products confirms the pattern, licensing the database "solely to host the schema or objects created by the installer."
Here is the mechanical reality that catches enterprises. A restricted grant does not throw an error when you exceed it. It does not stop working if you point Power BI at it, build a custom integration, or load its data into a separate warehouse. The deployment keeps running exactly as before. But every one of those uses falls outside the license grant, and Oracle treats out-of-scope use as unlicensed and prices remediation at full-use rates. The compliance gap opens silently and compounds until an Oracle LMS audit measures it.
A restricted grant does not stop working when you exceed it. No error appears. The exposure compounds silently until Oracle audits it, then prices the remediation at full-use rates.
Oracle has, in some bundles, spelled out how ordinary administrative actions trip full-use. In the Primavera repository language, "only licensed application users can access the repository, for example, creating a new departmental workspace or folder would trigger a full-use license." That is how tightly Oracle reads its own "only." A folder. Assume the OBIEE grant is read the same way.
This is the exposure that puts real money at risk. OBIEE and Oracle Analytics Server almost always connect to data warehouses or transactional databases to fetch data for reports. Those data sources are never covered by the OBIEE license. Oracle Licensing Experts state it plainly: "if your data warehouse is an Oracle Database, you need to license it according to its usage." The OBIEE license covers the BI application itself, not a single row of the data it reports on.
The false assumption we see in the field is that an Oracle database "used only for OBIEE data" is somehow covered by OBIEE. It is not. All data sources require proper licensing outside of OBIEE. The most dangerous variant of this is when a team decides to save money by using the bundled restricted-use repository database for a bit more than metadata: a reporting schema, a small warehouse feed, a materialized view of business data. The moment business data lands in that database, the restricted grant is void and the entire database instance requires full-use licensing.
In Redress Compliance reviews of the analogous Oracle E-Business Suite estate, a reporting schema or warehouse feed converting a restricted grant into a full-use requirement appeared in roughly half the estates reviewed. In our experience the OBIEE pattern is at least as common, because analytics teams naturally gravitate toward co-locating the data with the tool. Connecting a reporting tool, ETL job, or second application to a restricted database is the single most common way enterprises drift out of compliance.
In half the estates reviewed, a single reporting schema or warehouse feed converted a free restricted-use grant into a full-use liability. The OBIEE pattern is at least as common.
The reason this matters is the price gap between zero and full-use. On the Technology Global Price List effective April 16, 2026, Oracle Database Enterprise Edition lists at $47,500 per Processor and $950 per Named User Plus, with a 25 NUP per Processor floor. Annual support at 22 percent adds $10,450 per processor per year, and that support compounds for the life of the estate. The table below shows how fast the number escalates once a restricted grant is voided.
| Item | List figure | Note |
|---|---|---|
| EE per Processor | $47,500 | cores times Oracle core factor |
| EE per Named User Plus | $950 | 25 NUP per processor minimum |
| EE annual support (22%) | $10,450 / processor / yr | compounds every year |
| Standard Edition 2 | $17,500 / occupied socket | cores ignored, 2-socket cap |
| Partitioning option | $11,500 / processor | stacks if enabled |
| RAC option | $23,000 / processor | stacks if enabled |
| 32 Intel cores at 0.5 factor | ~$760,000 EE | before options |
That last row is not hypothetical. Thirty-two Intel cores at the 0.5 core factor equal sixteen processors, which is $760,000 of Enterprise Edition at list. Add the options a production estate typically runs (Partitioning, RAC, and often more) and the figure pushes past $1.3 million before anyone opens a single OBIEE module. A restricted grant that cost nothing becomes a seven-figure exposure the day someone loads business data into it.
The Named User Plus floor is its own overbuy trap on a lightly used repository. Enterprise Edition requires 25 NUP per processor. A four-processor EE database serving twelve real analysts still licenses one hundred NUP, because below the floor you pay the floor. For full pricing mechanics see Oracle Database license cost 2026, and for the edition trade-off note that Standard Edition 2 at $17,500 per occupied socket (cores ignored, capped at two sockets) is often the cheaper repository home if the workload fits.
The safe path is to host the RCU schemas on a database you already license at full use rather than spinning up a new restricted-use instance. Oracle guidance supports this: "try to use an already-licensed Oracle DB environment instead of spinning up a new one, usually, as long as it's a full-use licensed DB, it's fine to add schemas." The RCU supports multiple repositories within a single physical database, so co-location is technically clean.
But two caveats carry real risk, both stated in Oracle's own OBIEE Licensing Information document. First, the restricted grant is not portable. If you choose to install metadata into an existing licensed database, "the restricted use license does not apply to the use of the existing database as a metadata repository." You do not gain a free grant on top of your existing license; you simply use what you already paid for.
Second, and more dangerous, Oracle warns that the schema can inflate the obligation on that existing database: "installing the metadata repository into your existing database may increase the number of users accessing that database and may thus affect your database license needs." If the target database is licensed by Named User Plus, adding OBIEE service accounts and analysts as new users can push you over your NUP count. Count the users before you co-locate, not after LMS does. Our note on counting external and anonymous users in OBIEE portals is directly relevant here because those portal users can flow through to the underlying database as measurable access.
Oracle LMS does not audit the repository database in isolation. The connections from OBIEE fan out into scope. The most punishing example is database options. If your OBIEE or OAS deployment connects to an Oracle Database that has the Diagnostics Pack or Tuning Pack enabled, even incidentally, the audit scope expands to include those database options. Always audit your database options status before disclosing analytics environment details to LMS. For how partitioning specifically drives license count, see Oracle's partitioning policy.
For the broader picture of how these bundled option packs surface in an audit, read the bundled option packs that surface in an audit and the pillar overview at Oracle BI and analytics on-premise licensing.
Treat the restricted-use database as a live compliance liability, not a free perk. Buyer-side actions, in priority order:
If OBIEE itself is near end of support, the repository question changes shape entirely. Weigh it alongside the migration cost to Oracle Analytics Server or off Oracle, and consider a footprint optimization pass before renewal so the repository database is right-sized before the seller ever opens the file. The independent position is straightforward: a restricted-use grant is worth exactly zero dollars until someone breaches it, at which point it can be worth over a million. Keep it at zero.
No. The OBIEE license covers the BI application only. The restricted-use database it bundles is licensed solely to host the RCU metadata schemas. Any database holding actual report data or warehouse tables must be licensed separately at full use according to its own usage.
Storing any data other than the RCU metadata schemas. Oracle's wording is that 'storing any other data in the database requires a full use license.' That includes reporting schemas, warehouse feeds, ETL landing tables, and even non-BI application data. The grant hangs on the word 'only,' and Oracle reads it literally.
Yes, and it is usually the safest path if the database is already full-use licensed. But the restricted grant is not portable to it, so you gain no free license, and Oracle warns the added OBIEE users may increase your Named User Plus count on that database. Count users before you co-locate.
At list, Enterprise Edition is $47,500 per processor plus $10,450 annual support, with a 25 NUP per processor floor. A 32-core Intel server at the 0.5 core factor is roughly $760,000 of EE before options. Add Partitioning ($11,500/proc) and RAC ($23,000/proc) and a production estate can exceed $1.3 million.
Pointing a third-party tool at the restricted database to read business data is out-of-scope use. It will not throw an error and the deployment keeps running, which is precisely why it goes undetected. Oracle treats the use as unlicensed and prices remediation at full-use rates once an audit measures it.
Yes. If OBIEE or OAS connects to a database with Diagnostics Pack or Tuning Pack enabled, even incidentally, LMS audit scope expands to those options. Audit your option status and disable anything unlicensed before disclosing analytics environment details to Oracle.
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.
