Franck PachotDatabase Developer Advocate Minibook 28 · Database field guides All minibooks

Database field guide · 28

Oracle Licensing

Editions, options, metrics, and evidence

Build an evidence-based Oracle licensing inventory from contracts, deployed editions, enabled options, infrastructure metrics, and actual feature use.

Franck Pachot7 chaptersOracle · licensing · options · compliance evidence

Build the mental model before choosing the mechanism.

This minibook was AI-generated from Franck Pachot's archived blog posts. Links to the original articles are included for source context and verification.

01

The contract is the authority

Technical views reveal deployment and use, but licenses are legal rights defined by orders, agreements, metric definitions, and support history. Product behavior cannot interpret a contract by itself.

  • Keep entitlement documents with the technical inventory.
  • Distinguish installed, enabled, used, and licensed.
  • Escalate ambiguous contractual interpretation to qualified specialists.

02

Edition and option are separate dimensions

Enterprise Edition is a prerequisite for many separately licensed options, while Standard Edition has a different included feature set and infrastructure metric. A database version string alone does not establish entitlement.

  • Inventory edition for every Oracle home.
  • Map options and packs independently.
  • Track changes across upgrades and migrations.

03

Metrics depend on infrastructure

Processor, named-user, socket, OCPU, and cloud-provider policies count different things. Virtualization and host mobility can expand the infrastructure considered licensable beyond one virtual machine.

  • Record physical hosts and placement policy.
  • Preserve core factors and cloud conversion rules used.
  • Treat autoscaling and disaster recovery as explicit scenarios.

04

Feature evidence needs context

Feature-usage views, option banners, installed components, parameters, and workload evidence answer different questions. False positives and historical use require version-aware interpretation.

  • Snapshot evidence before remediation.
  • Correlate feature use with SQL and configuration.
  • Absence from one view is not proof of entitlement.

05

Compression and multitenant cross boundaries

Operations that look like ordinary DDL may invoke separately licensed capabilities depending on edition, release, and syntax. Compression and multitenant limits illustrate why deployment review must reach object definitions and operations.

  • Review actual DDL, not feature labels alone.
  • Check release-specific included capabilities.
  • Retest after moving to cloud packaging.

06

Operate licensing as change control

A defensible process inventories entitlements and deployment, detects drift, reviews planned changes, records decisions, and repeats after patching, scaling, failover, or acquisition.

  • Assign owners for contract and technical evidence.
  • Automate collection without automating legal conclusions.
  • Keep remediation reversible and documented.

07

Field manual

Concrete mechanics, diagnostic evidence, and executable patterns to carry into a real system.

01

Collect edition and option evidence

Record the database banner, installed options, components, and pluggable database topology. This is technical evidence, not a licensing conclusion.

SELECT banner_full FROM v$version;
SELECT parameter, value FROM v$option ORDER BY parameter;
SELECT comp_name, version, status FROM dba_registry ORDER BY comp_name;
02

Snapshot feature-usage records

DBA_FEATURE_USAGE_STATISTICS includes detection counts, dates, and auxiliary details. Interpret each row with release-specific documentation and actual workload evidence.

SELECT name, detected_usages, first_usage_date, last_usage_date,
       currently_used, feature_info
FROM dba_feature_usage_statistics
WHERE detected_usages > 0 ORDER BY name;
03

Map databases to infrastructure

A licensing inventory needs host, cluster, virtualization, cloud shape, mobility, and disaster-recovery context in addition to database facts.

database -> Oracle home -> VM or container -> physical host -> cluster
         -> cloud instance shape -> region/DR role
# Attach source, collection time, and entitlement metric to every edge.
04

Review changes before deployment

Evaluate new options, topology changes, failover targets, scaling, and cloud migration before activation, then retain the approved evidence with the change record.

1. State requested capability and edition.
2. Identify included or separately licensed dependencies.
3. Map affected infrastructure and metrics.
4. Obtain contractual review.
5. Deploy, rescan, and archive evidence.

08

Source articles

Optional deep dives with the complete experiments and product-version context behind this guide.