The Oracle ASFU license explained. Full use, but only inside one application.

An Oracle ASFU license gives full use of the program at a discount, but only in support of the one application named on your ordering document. When that boundary is crossed, Oracle audits you, not the ISV.

What is an Oracle ASFU license?

An Oracle ASFU (Application Specific Full Use) license gives you the full functionality of an Oracle program, but only in support of one named third party application. You buy it from the independent software vendor (ISV) that sells the application, below Oracle's Full Use list price.

The restriction sits on one or two lines of the ordering document, which license the program for use solely with the named ISV product. The order still carries your company name and your processor count, which is why Oracle audits you and not the ISV.

Support runs under a Customer Support Identifier (CSI). Whether that CSI is in your name or the ISV's decides what happens to your patches later.

How does ASFU differ from Full Use and Embedded licenses?

Oracle sells the same software under several grants, and the price falls as the permitted use narrows. Our license types guide covers Full Use, ASFU, Embedded and hosting grants, priced against the technology price list.

How do you tell which grant you actually run?

Ask whether your own DBAs log into the database. If they do, you are not on an Embedded license, whatever the ISV told procurement. An Embedded Software License permits no direct access, which is why it is the cheapest grant Oracle writes and never carries your name.

How much does an ASFU license cost compared with Full Use?

Oracle publishes no ASFU rate card, so the price depends on what the ISV agreed with Oracle. On the ISV quotes we review, ASFU lands 30 to 50 percent below the Full Use list line. Oracle Database Enterprise Edition lists at $47,500 per Processor under Full Use.

The worked case below uses one ordinary x86 server, counted with the same core factor arithmetic that applies to Full Use. We use the midpoint of the observed band for the conversion example later on.

What does the ASFU discount not cover?

Only the programs printed on the order are licensed, one row per program. If your DBAs use the Diagnostics and Tuning Packs on the ISV's Enterprise Edition database, those packs need their own rows. At list they add $12,500 per Processor ($7,500 for Diagnostics, $5,000 for Tuning), which comes to $200,000 on the 16 licenses in the worked case.

Which fields on the ordering document decide your ASFU exposure?

Six fields decide it. Read all six before the application goes live, and again before any integration project touches the database. The last three are the ones you can still change at purchase and almost never afterward.

Where does the ASFU boundary break in practice?

It breaks at the first connection that serves something other than the named application. In the audits we defended, the break almost always arrived as ordinary project work that no one checked against the order.

• A BI or analytics tool. Someone points a reporting tool at the database because the data is already there. This was the most common break we saw.
• An ETL or integration layer. A nightly extract feeds a data warehouse, or another system reads tables directly, and the ticket closes without anyone reading the order.
• A second application. A schema for a different product lands on the same instance to save a server.
• A replica. A copy built to serve reports or another team sits outside the grant, and it needs its own licenses as well.

Why do the management packs create a second finding?

Enterprise Edition ships with CONTROL_MANAGEMENT_PACK_ACCESS set to DIAGNOSTIC+TUNING, so both packs are switched on from first boot. Any use of them after that, by a DBA, a monitoring script or the Enterprise Manager performance pages, is recorded against a license the ASFU order does not include.

Setting the parameter to NONE stops new pack usage, but it does not erase the history in DBA_FEATURE_USAGE_STATISTICS, so set it at installation. See our guides to turning off pack access and to first and last sample dates.

Why we do not tell clients to skip ASFU and pay Full Use

A common piece of advice is to avoid ASFU and pay Full Use list, so the boundary never matters. For a self contained packaged application with no wider plans for the database, we think that wastes money. The discount is real, and it lasts exactly as long as the boundary does.

Buy ASFU with the two protections described below, then make the boundary part of your architecture review, so any new tool, feed or schema is checked against the order before approval. Pay for Full Use only where reporting, integration or consolidation is already on the roadmap.

How do you check whether your ASFU database is still inside the boundary?

Build a connection inventory: every tool, account, feed and link that touches the database, with the business reason for each and the date it started. Build it before the audit letter arrives, because the dates are what limit a claim later.

• Current sessions. Query V$SESSION and group by the PROGRAM, MACHINE and MODULE columns to see which clients connect and from where.
• Connection history. Read the listener log, or the unified audit trail where logon auditing is enabled, to catch jobs that run only at night or at month end.
• Accounts and links. Match every account in DBA_USERS to the application, a DBA or a known tool, and check DBA_DB_LINKS on every database that might point here.
• Packs. Run SHOW PARAMETER control_management_pack_access and query DBA_FEATURE_USAGE_STATISTICS for pack features with recorded usage.
• Oracle's view. Run the collection scripts Oracle's auditors use and read the output first, as set out in our audit script analysis.

Avoid AWR reports and the DBA_HIST views for this work unless the Diagnostics Pack is licensed. Oracle's licensing documentation places the AWR report scripts and all but a handful of DBA_HIST views inside that pack, so using them adds to the problem you are trying to measure.

What happens when Oracle finds an ASFU breach?

Oracle prices any use outside the named application at Full Use list rather than your ASFU rate. The finding usually arrives as a demand to convert the ASFU licenses to Full Use, with support recalculated on the new fee.

The split into license and backdated support is our reading of the figure, and it matches the opening demand to the dollar. Whatever the one off amount settles at, the support increase lasts. Settlements came in well under the openings only where the customer had the connection inventory ready early.

What will the Oracle account team say, and how should you answer?

• "The grant is void, so every Processor converts at list." Ask Oracle to name the connections outside the named application and when each began. One reporting tool supports a claim limited to that use and that period.
• "Conversion means list price plus backdated support." Ask for the ASFU fees already paid to be credited against the Full Use price, and for any backdated support to start from the date your inventory shows.
• "The feature usage data shows the packs in use." Ask for the first and last sample dates by feature. Usage that stopped when you set the parameter to NONE supports a smaller claim than usage still recorded today.
• "Your cloud migration took the database outside the license." Produce the ISV's written confirmation of hosting rights and the count you made under Oracle's cloud policy beforehand.

Our note on what to do when the audit letter arrives covers the first days of the response.

Which business changes break an ASFU license?

Three business events can take the database outside the grant with no new reporting tool involved: the ISV disappears, an acquisition consolidates the database, or the application migrates to AWS or Azure. The last two are planned months ahead, so the license review belongs in the plan.

What happens if the ISV goes out of business or is acquired?

Your license and your patches depend on the ISV's distribution relationship with Oracle. If the CSI is in the ISV's name, patch access stops when the ISV stops paying Oracle. Putting the CSI in your own name at purchase costs nothing; changing it later is a negotiation you start from a weak position.

What happens when your company acquires or consolidates?

Acquisitions often fold the ASFU database into a larger shared environment, and every other application using it sits outside the grant. Read the ASFU orders during due diligence, and check the assignment clause before any consolidation is planned.

What happens when the application migrates to AWS or Azure?

Hosting and cloud rights live in the ISV's distribution agreement rather than your order, so a migration without written confirmation exits the grant. The cloud counting rules then drop the core factor.

Under Oracle's Authorized Cloud Environment policy, two vCPUs count as one Processor license when hyperthreading is enabled. Run the worked case's 32 cores as 64 vCPUs with hyperthreading on, and you need 32 licenses, double the 16 you bought for the same workload.

What should you get written into an ASFU order?

Two protections matter most: a capped conversion price to Full Use, and the CSI in your own name. Both cost nothing at first purchase and cannot be bought once Oracle has a finding, which is when most buyers first look for them.

• A capped conversion price. A fixed amount or percentage of list for converting to Full Use, so a breach is priced at a number you agreed rather than at Oracle's opening demand.
• The CSI in your name. Patch access then survives any change in the ISV's relationship with Oracle.
• A named application that includes its own modules. The ISV's reporting and integration components should sit inside the name.
• Every program the application needs. Packs and options it depends on belong on the order at the ASFU rate.
• Sizing from your servers. Count the Processors you will run, not the ISV's reference architecture.
• Written cloud rights and continuity. Ask the ISV to confirm whether AWS or Azure hosting is allowed, and how licenses and support continue if it is acquired.

What have we seen in recent ASFU reviews?

Across roughly 20 to 30 ASFU reviews I defended in 2024 and 2025, not one finding began with somebody deciding to break a license. They began with a reporting request that no one checked against the ordering document.

• BI connections. A reporting or analytics tool broke the grant in 30 to 40 percent of reviews; integration and ETL layers accounted for most of the rest.
• Pack defaults. In 50 to 70 percent, the management packs were already recording usage because the Enterprise Edition default had never been changed.
• Opening demands. Oracle's opening conversion demands ran 2 to 3 times the original ASFU fee.
• The two week window. Customers who produced a connection inventory inside the first two weeks of the audit settled well under the opening; the rest faced findings at list price.

The defenses that worked were prepared rather than argued: an inventory on the table early, the pack parameter set on purpose, and the order read before the integration ticket closed.

What to do next

1. This week. Read the program line and the program list on every ASFU ordering document.
2. This month. Set CONTROL_MANAGEMENT_PACK_ACCESS deliberately on every ASFU database, so it records only the packs you own.
3. Within two months. Build the connection inventory for each ASFU database and keep it current.
4. At the next purchase or ISV renewal. Ask for the CSI in your own name and a conversion cap in the order.
5. From now on. Add every ASFU database to your architecture review, so new tools, feeds and schemas are checked against the order.
6. Before any migration or acquisition. Reprice the grant, because the cloud doubles the count and consolidation voids the boundary. Our Oracle practice can run that review with you.

Frequently asked questions