Oracle SAM. Read what the auditor reads.

Generic SAM tooling reads Oracle wrong, because the licensable events live in feature usage tables and virtualization topology, not in installation counts. Oracle SAM is its own discipline.

Why does generic SAM fail on Oracle?

Standard SAM matches installations to entitlements. Oracle licensability is decided by activated cores, the core factor, named users, option feature usage, and virtualization boundaries, none of which an install scan sees.

Oracle's own License Management Services function audits from database internals: feature usage tables, parameter settings, and topology evidence. Your SAM program has to read the same sources.

What makes option usage the silent liability?

Features install with the database and record their own usage. A DBA opening a performance view can trigger Diagnostics Pack usage; a partitioned table licenses Partitioning. Intent is irrelevant; the usage table is the record.

How do you build a defensible Oracle baseline?

A defensible baseline reads the same evidence an auditor would: collection scripts against every instance, a hardware and hypervisor inventory with the core factor applied per Oracle's published pricing structures, and the entitlement stack reconciled line by line.

1. Inventory every database instance, including DR, test, and the ones nobody owns.
2. Run collection scripts per instance and capture feature usage history, not just current state.
3. Map every host to its hypervisor cluster and apply the core factor to the licensable boundary.
4. Reconcile against entitlements: metric, edition, options, and contractual restrictions.
5. Document remediation decisions with dates; the paper trail is the audit defense.

Which scripts should the self check use?

Script based collection consistent with what Oracle LMS gathers, so your internal view and the audit view cannot diverge on the facts. Interpretation is where the negotiation lives, and you want the raw data to match.

How should SAM handle virtualization and cloud?

Oracle's partitioning policy treats most software virtualization as soft partitioning, which does not limit licensing scope. The licensable boundary becomes the cluster or every host a VM could reach, which is why topology is a SAM artifact, not an infrastructure detail.

• Contain by design: dedicated Oracle clusters with documented migration boundaries cap the scope.
• Record the history: where VMs could run last year matters in an audit covering last year.
• Cloud counts differently: authorized cloud environments price per vCPU rules; map them separately from the data center.

What does a clean topology file look like?

Cluster diagrams, host inventories with core counts and factors, VM placement rules, and change records. If the audit asks where this database could run, the file answers in one document.

What does a working Oracle SAM operating rhythm look like?

The estates that stay clean run a quarterly rhythm owned by one accountable function, with licensing review wired into change management rather than bolted on at audit time.

• Quarterly: script run, feature usage diff, and a remediation queue with owners.
• On change: any new cluster, host, or database build passes a licensing gate before go live.
• Annually: entitlement stack review against the roadmap, before the renewal and budget cycle.

Who should own Oracle SAM?

A named owner with access to both the DBA estate and the contracts, typically in ITAM with a direct line to procurement. Split ownership is how usage drifts unwatched between the cracks.

Where the common advice on Oracle SAM tooling is wrong

The standard advice says buy a verified SAM tool and the Oracle problem is handled. We disagree. In roughly 25 to 35 baselines Morten Andersen built in 2024 to 2025, tool output alone missed the exposure that mattered, option usage history and virtualization scope, in most estates, and no tool output binds Oracle in an audit. The tools are useful telemetry. The defense is script level evidence, a topology file, and a quarterly remediation rhythm with named owners. The buyer side move is to budget for the discipline, not just the dashboard, because the dashboard does not negotiate.

What the engagement data shows

Three cuts of our advisory engagement file frame the size of the opportunity.

What to do next

Five moves turn this analysis into a lower invoice on the next renewal.

A sequence you can run this quarter

1. Name one owner for Oracle SAM with access to DBAs and contracts.
2. Run collection scripts across every instance, including DR and test.
3. Build the topology file: clusters, cores, factors, and placement rules.
4. Diff feature usage quarterly and work the remediation queue.
5. Gate new builds and cluster changes through a licensing check.

Frequently asked questions

What is Oracle software asset management?

The discipline of measuring Oracle deployment, core counts, option usage, and virtualization scope against entitlements, using the same evidence sources an Oracle audit would: collection scripts, feature usage tables, and topology records.

Why do generic SAM tools struggle with Oracle?

Because Oracle exposure lives in feature usage history, core factors, named user minimums, and where VMs can run. Install based discovery misses most of it, and no third party tool output is binding in an Oracle audit.

What Oracle options trigger accidental usage most often?

Diagnostics Pack, Tuning Pack, and Partitioning. They ship installed, record their own usage, and appeared unpurchased in 60 to 80 percent of the first baselines in our 2024 to 2025 file.

How often should an Oracle self assessment run?

Quarterly. Feature usage and topology drift in weeks, and estates on a quarterly script rhythm carried roughly half the audit settlement exposure of annual checkers in our file.

Does Oracle accept third party SAM tool reports in audits?

Oracle audits from its own collection scripts and data. Tool reports are useful internally but do not replace script evidence, which is why your baseline should be built from the same sources.