Oracle Database Licensing on GCP: BYOL Rules, Dedicated Nodes & the Compliance Traps Oracle Doesn't Advertise

Oracle's Official Position on GCP Licensing

Oracle's licensing policy for cloud environments is governed by two core documents: the Oracle Technology Global Price List (which includes the cloud licensing policy appendix) and the Oracle Partitioning Policy. For Google Cloud Platform specifically, Oracle's published position as of 2026 is that GCP is an "authorised cloud environment" — meaning Oracle licences can be deployed on GCP under BYOL terms — but Oracle does not recognise GCP's virtual machine infrastructure for the purposes of limiting licence counts.

This matters enormously. When you run Oracle Database EE on a GCP Compute Engine VM, Oracle's position is that you must licence all physical cores on the underlying host server — not just the vCPUs assigned to your VM. Oracle does not permit you to cap your licence count based on GCP's virtualisation layer unless you use GCP's Bare Metal Solution or you purchase Oracle Database through the Oracle Universal Credits programme on OCI. For every other GCP deployment scenario, you are in BYOL territory and Oracle's core counting rules apply at the physical host level.

The specific GCP deployment scenarios and their Oracle licensing treatment are:

BYOL on GCP Compute Engine: The Core Factor Problem

The Compute Engine BYOL scenario is where most Oracle compliance problems on GCP originate. Enterprises migrate Oracle workloads to GCP, allocate modest VM sizes (say, 8 vCPUs), and assume their licence requirement is 8 vCPUs × 0.5 Core Factor = 4 processor licences. Oracle's auditors take a fundamentally different view.

Under Oracle's partitioning policy, a technology called "hard partitioning" is required to limit the processor count for licensing purposes. GCP's Compute Engine virtualisation uses software-based virtualisation (KVM-based) which Oracle categorically does not recognise as hard partitioning. The only technologies Oracle accepts as hard partitioning on x86 infrastructure are Oracle VM Server for x86 (OVM) and specific bare metal configurations. GCP Compute Engine is neither.

The practical consequence: if your 8-vCPU Oracle Database EE VM runs on a GCP host with 128 physical cores (typical for GCP's n2-standard or c3 series high-core-count machines), Oracle's LMS audit will assert you need to licence all 128 cores × 0.5 Core Factor = 64 processor licences. At $47,500 per Oracle Database EE processor licence (perpetual list), that is a $3,040,000 licensing requirement — for what you thought was a modest cloud deployment.

Oracle's LMS audit scripts (specifically the USMM — Oracle Universal Script for Measuring and Monitoring) collect physical CPU data from the Oracle Database data dictionary and from operating system commands. On GCP Compute Engine, the scripts can identify the underlying physical processor architecture and in many cases determine the host processor count. Oracle uses this data to build its audit claim.

GCP Bare Metal Solution: The Compliant Path for Oracle BYOL

Google Cloud's Bare Metal Solution (BMS) is a dedicated physical infrastructure offering within GCP that provides single-tenant bare metal servers. For Oracle licensing purposes, Bare Metal Solution is Oracle's recommended BYOL path on GCP — and Oracle explicitly acknowledges BMS in its cloud licensing documentation as an environment where customer-owned physical processor counts can be used for licence calculations.

On a Bare Metal Solution node, you know exactly how many physical processors are present in the server you are using. Oracle's Core Factor Table then applies to those processors in the normal way. A BMS node running two Intel Xeon processors with 32 cores each = 64 physical cores × 0.5 Core Factor = 32 Oracle processor licences required. This is straightforward, predictable, and fully defensible in an Oracle LMS audit.

The trade-off is cost. GCP Bare Metal Solution is significantly more expensive than standard Compute Engine VMs on a per-compute-unit basis. However, for enterprise Oracle Database EE workloads where the alternative is unlimited BYOL exposure on shared Compute Engine hosts, the BMS premium is almost always justified by the risk reduction. Organisations with our Oracle licence optimisation advisory have compared the BMS premium against audit exposure and found BMS to be cost-effective in nearly every scenario involving Oracle EE.

Oracle Marketplace on GCP: What UCLS Actually Covers

Google Cloud Marketplace offers Oracle Database published directly by Oracle, available on an hourly PAYG (pay-as-you-go) basis. When you launch Oracle Database from the GCP Marketplace using Oracle's own published images, the Oracle software licence is included in the hourly rate — this is Oracle's Universal Cloud Licensing Service (UCLS) model. There is no separate BYOL requirement, no LMS audit exposure for under-licensing, and Oracle's core counting rules do not apply to the compute you allocate.

UCLS pricing on GCP Marketplace is typically structured per OCPU-hour (Oracle CPU equivalent) and includes Oracle Database Enterprise Edition, Standard Edition 2, and a selection of database options. The included options vary by the specific Marketplace listing — Oracle Database EE listings may include Diagnostic Pack and Tuning Pack; Oracle Database EE Extreme Performance may include In-Memory, Partitioning, and Advanced Analytics.

The critical point: UCLS through GCP Marketplace is not the same as BYOL on GCP. They are distinct licensing models with different contractual obligations, audit exposure profiles, and cost structures. Enterprises that mix BYOL deployments with Marketplace deployments on the same GCP project introduce complexity that Oracle's LMS team will probe. Maintain clear separation between BYOL environments (exclusively on BMS) and Marketplace PAYG environments (on standard Compute Engine).

Core Factor Table and GCP Processor Types

Oracle's Core Factor Table assigns a multiplier to each processor architecture that determines how many Oracle processor licences are required per physical core. The Core Factor Table is essential to understanding your Oracle licence requirement on GCP Bare Metal Solution nodes, where you can identify the specific processor type in use.

As of 2026, the Core Factor Table values relevant to GCP Bare Metal Solution configurations are:

For BYOL on GCP Bare Metal Solution with a dual-socket Intel Xeon Platinum 8380 (40 cores per socket), the calculation is: 2 sockets × 40 cores = 80 physical cores × 0.5 Core Factor = 40 Oracle processor licences required per BMS node. This is the precise calculation Oracle's auditors will perform.

On Compute Engine VMs (where you are exposed to host-level licensing), Oracle does not publish the physical host configurations used by GCP's hypervisor fleet. This is one of the reasons BYOL on Compute Engine is auditorially dangerous — you cannot reliably determine the physical core count of the host your VM is running on, and therefore cannot accurately calculate your licence requirement. Oracle's LMS scripts may return physical core data that reveals configurations with 96, 128, or even 256 physical cores on a single host.

How Oracle LMS Scripts Audit GCP Deployments

Oracle's LMS (Licence Management Services) team uses the USMM (Universal Script for Measuring and Monitoring) as its primary data collection tool. When Oracle initiates an audit that includes GCP workloads, it will ask you to run USMM on each Oracle Database instance — including those running on GCP. The script collects:

• Processor type, number of physical CPUs, and physical core counts reported by the operating system
• All Oracle Database features and options that have ever been enabled or accessed (Oracle's 60-day lookback via v$session and dba_feature_usage_statistics)
• Oracle Database version, edition, and patch level
• Virtual machine and container configuration data (where detectable)
• Oracle Cloud Infrastructure metadata (if present, indicating the compute environment)

On a GCP Compute Engine VM, the operating system may report physical CPU topology that reflects the underlying GCP hypervisor host rather than the virtualised resource allocation. This is Oracle's basis for claiming full host-level licensing. The USMM output will show the physical processor count Oracle detected — and that number will be used in Oracle's audit claim.

Enterprises with our Oracle audit defence advisory have successfully challenged GCP-based LMS findings where Oracle's physical core detection was inaccurate or where the specific GCP infrastructure used qualifying configurations. These challenges require forensic analysis of GCP infrastructure data — not just Oracle's script output.

Database Options and Packs on GCP: Additional Compliance Exposure

Beyond the base Oracle Database EE licence count, Oracle's audit scripts look for database options and management packs that may have been enabled on your GCP instances. Database options (Partitioning, In-Memory, Advanced Security, Diagnostics Pack, Tuning Pack, etc.) are separately licensed at additional costs per processor — and Oracle's audit scripts detect usage historically, not just at the point of measurement.

The most common GCP-specific options traps are:

Each of these options compounds the base licence exposure. In a scenario where Oracle asserts host-level licensing for a GCP Compute Engine VM, the options claims are calculated on top of the inflated processor count. A 128-core host with Diagnostics Pack usage and ASO exposure creates a combined audit claim that can reach $10M–$20M for a single database instance.

How to Defend Your GCP Oracle Compliance Position

The most effective defence against Oracle GCP compliance exposure is preventive — establishing a defensible configuration and documented evidence base before an LMS audit notification arrives. Once Oracle's audit letter arrives, your options narrow and your negotiating leverage diminishes. Enterprises that have proactively engaged our compliance review before audit typically resolve Oracle's findings 60–70% below the initial audit claim. Those who engage only after receiving Oracle's demand typically resolve at 30–40% below the claim — meaning they pay significantly more for the same defensive work.

The Logistics: Database Consolidation case study on our case studies page illustrates how an enterprise with significant GCP BYOL exposure reduced its audit settlement from $9.2M to $2.7M through a combination of BMS migration evidence, options disablement documentation, and contract term analysis. The engagement took four months from audit notification to final resolution.