Oracle License Self-Audit: An Eight-Step Guide

The safest Oracle audit is the one you run on yourself, months before Oracle asks. A self-audit uses the same data Oracle would collect, but the findings stay inside your organisation: you decide what to fix, what to remove and what to license, at your own pace and price. This guide sets out how to run one, step by step.

In short

• Collect every contract first, including those of acquired companies, and list what each one entitles you to.
• Find every installation, on premises, in virtual clusters and in the cloud, including standby and test servers.
• Check options, packs and Java, which cause most findings and are the easiest to miss.
• Count with Oracle’s rules, then compare with your contracts to get a licence position for each product.
• Fix before you buy: Remove and reconfigure first, and license only what remains. Keep the results inside the organisation.

Step 1: Collect your entitlements

Gather every Oracle Master Agreement or licence agreement, every ordering document and amendment, and the current support renewal. Include the contracts of any company you have acquired. For each licence, note the product, the metric (processor or Named User Plus), the quantity, any restrictions such as use limited to one application, and whether support is current. This list is your side of the comparison, and it is often larger than Oracle’s records.

Step 2: Find every installation

List every server, virtual machine and cloud instance where Oracle software is installed or running: databases, middleware such as WebLogic, applications such as E-Business Suite, and Java. Include development, test, standby and disaster recovery servers. Oracle counts installed and running software, not only production.

Step 3: Record the hardware and virtualisation

For each server, record the processor model, the number of physical cores and sockets, and how it is virtualised. On VMware, note the cluster and every host in it. In the cloud, note the instance type and its vCPUs. These details decide the licence count, and they are the details most often missing when an audit starts.

Step 4: Check options, packs and features

On every Enterprise Edition database, query DBA_FEATURE_USAGE_STATISTICS for options such as Partitioning, Advanced Compression and Active Data Guard, and for the Diagnostics and Tuning Packs. Check CONTROL_MANAGEMENT_PACK_ACCESS, which enables the packs by default. On Standard Edition 2, any use of the packs is a finding, because they cannot be licensed for that edition.

Step 5: Find Oracle Java

Scan for Oracle JDK and JRE installations and their versions on servers and desktops. Note which are bundled inside other Oracle or third-party products, which are often licensed through that product, and which are standalone. Oracle’s Java subscription is priced per employee, so even a few unlicensed installations can produce a large claim.

Step 6: Count with Oracle’s rules

Turn deployments into licence requirements. On premises, multiply physical cores by the core factor (0.5 for Intel and AMD) and round up. On AWS, Azure and Google Cloud, count two vCPUs as one processor licence when multi-threading is enabled. Apply the Named User Plus minimums, 25 per processor for Enterprise Edition. Count your own position on VMware separately under Oracle’s partitioning policy, so you know the figure an audit would start from.

Step 7: Compare and fix

For each product, compare the requirement with your entitlements. Then fix before you buy: switch off packs and options that are not licensed, uninstall unused software, move Oracle virtual machines into dedicated clusters, and remove Java where a free OpenJDK build will do. License only the gap that remains, and negotiate it as a purchase, not as an audit settlement.

Step 8: Keep it inside the organisation

Self-audit findings are internal working papers. Do not share them with Oracle, and do not run Oracle’s own scripts as part of a self-audit unless you are in a formal audit with an agreed scope. Keep a record of each fix and the date it was made, then repeat the exercise every year and before every renewal.

Where a self-audit runs out

Most internal teams can do steps 1 to 5. Steps 6 and 7 need knowledge of Oracle’s policies and of how they apply to your contracts, and that is where the money is. An independent Oracle licence review takes the same data and reads it against your contracts, and our audit defense team steps in if Oracle has already written to you.

Questions we are asked about Oracle self-audits

What is an Oracle licence self-audit?

An internal check, run by you, of whether your Oracle deployments are covered by your licences, using the same rules Oracle would use in an audit.

Should I use Oracle’s audit scripts for a self-audit?

No. Use your own discovery and database queries. Oracle’s scripts are designed for its audits, and running them outside one can create records you would rather not have.

How often should I run an Oracle self-audit?

At least once a year, and before every renewal, ULA end date, hardware refresh or cloud migration.

What does an Oracle self-audit usually find?

Management packs in use without a licence, VMware clusters larger than the licences cover, unlicensed standby servers, cloud instances counted the on-premises way, and Oracle Java installations.

If you want a second pair of eyes on your count, book an hour with our Advisor on Call.