Oracle Database@Azure: The Complete Beginner's Guide
Oracle Database@Azure: The Complete Beginner's Guide
Article Overview
Oracle Database@Azure puts Oracle-managed Exadata infrastructure physically inside Microsoft Azure datacenters, provisioned from the Azure portal, governed by Microsoft Entra ID, and billed on your Azure agreement. This guide explains what the service actually is, how the control plane and network are wired together, how to choose between Base Database, Exadata Dedicated, Exadata Exascale, and Autonomous AI Database, and where the service fits in a real enterprise estate. It finishes with a complete deployment walkthrough — Azure CLI, Bicep, Terraform, and connection code — plus the sizing rules and naming traps that catch first-time deployments.
1.Why This Service Exists
Walk into almost any large enterprise and you will find the same pattern: a modern application estate that wants to live in a hyperscale cloud, sitting on top of an Oracle database estate that has been running — reliably, expensively, and with a lot of institutional knowledge attached — for fifteen or twenty years.
Historically, teams in that position had three unattractive options.
Option 1 - Rewrite the database
Convert schemas, PL/SQL packages, and application logic to PostgreSQL or SQL Server. Technically feasible, occasionally the right answer, and almost always a multi-year project with real risk attached to code nobody fully understands anymore.
Option 2 - Lift Oracle onto cloud virtual machines
Perfectly valid, but you inherit every piece of operational work you had on-premises — patching, backups, Data Guard configuration, Real Application Clusters setup — while losing the tuned storage stack that made your on-premises Exadata fast in the first place.
Option 3 - Split the estate across two clouds
Keep the databases in Oracle Cloud Infrastructure (OCI), keep the apps in Azure, and stitch them together with a cross-cloud interconnect. This works, but it means two networks, two identity systems, two bills, two support relationships, and a latency budget you have to defend in every architecture review.
Oracle Database@Azure was designed to remove that trilemma. The premise is simple: rather than making the customer bridge two clouds, put the Oracle hardware physically inside the Azure datacenter and expose it through Azure's own control plane.
2.What Oracle Database@Azure Actually Is
Oracle Database@Azure is Oracle database software running on Oracle-managed Exadata infrastructure that is physically installed in Microsoft Azure datacenters, provisioned and governed through the Azure portal, APIs, and identity system, and billed through your Azure agreement.
Unpacking that sentence gives you most of what you need to know.
| Phrase | What it means in practice |
|---|---|
| Oracle database software | The real thing — Oracle Database 19c or 23ai, with Real Application Clusters, Data Guard, partitioning, Advanced Security, and the rest of the feature set. Nothing is emulated or reimplemented. |
| Oracle-managed Exadata infrastructure | Oracle owns and operates the database servers, storage servers, and RDMA fabric. You do not rack it, patch the firmware, or replace failed disks. |
| Physically installed in Azure datacenters | The hardware sits in the same facility as your Azure VMs and AKS nodes. Traffic between your application tier and your database does not traverse the public internet or a cross-region link. |
| Through the Azure portal, APIs, and identity | You create databases from the Azure portal, az CLI, ARM/Bicep, or Terraform. Access is controlled with Microsoft Entra ID and Azure RBAC. |
| Billed through your Azure agreement | Consumption appears on your Azure invoice and draws down an Azure commitment rather than a separate Oracle cloud contract. |
The distinction that trips up newcomers
This is not "Oracle software on Azure VMs," and it is not "OCI in another region." It is a genuine co-location arrangement in which Oracle's control plane and Azure's control plane have been wired together so that one experience is presented to the user.
3.A Note on the Name
If you search for this service you will encounter two names, and both are correct.
- Oracle Database@Azure — the original name, used from the September 2023 announcement through general availability in December 2023 and most of the material published since.
- Oracle AI Database@Azure — the current branding, adopted after Oracle renamed its database line to emphasise built-in AI capabilities such as vector search. Autonomous Database was similarly rebranded to Autonomous AI Database.
Same service, same resource provider, same APIs. Documentation, blog posts, and Terraform resource names still use the older form in many places, so expect to see both for a while. This guide uses the original name for readability and notes the newer one where it matters.
4.How It Compares to the Alternatives
Before committing, it is worth knowing exactly which problem each option solves.
| Approach | Who runs the database | App-to-DB network path | Best when |
|---|---|---|---|
| Oracle on Azure VMs (IaaS) | You | Inside Azure | You need full OS control, run a small database, or have licensing arrangements that favour it |
| Oracle Interconnect for Azure | Oracle, in an OCI region | Cross-cloud private link, typically a few milliseconds | The database must stay in OCI for contractual or regional reasons |
| Oracle Database@Azure | Oracle, inside the Azure datacenter | Inside the Azure datacenter, over your own virtual network | You want Exadata-class performance with an Azure-native operating model |
| Migrate to Azure SQL / PostgreSQL | Microsoft | Inside Azure | The workload is portable and you are willing to fund a conversion project |
There is no universally right answer. A common enterprise pattern ends up mixed: tier-one ERP and core banking stays on Oracle Database@Azure, small departmental databases get converted to Azure Database for PostgreSQL, and a handful of legacy systems ride out their remaining life on VMs.
5.Architecture, Layer by Layer
The architecture becomes intuitive once you separate three concerns that are easy to conflate: where the hardware lives, how provisioning requests travel, and how packets travel.
5.1 The physical layer
Oracle deploys racks of Exadata infrastructure into Azure datacenters. In supported regions these deployments typically span two Azure availability zones, so you can build zone-redundant configurations. From your perspective, this hardware appears in Azure as a resource with a familiar Azure resource ID — but Oracle's automation is what actually manages the metal.
5.2 The control plane
When you click Create in the Azure portal, or run terraform apply, the request follows this path:
Three things follow from this design and are worth internalising early:
- Azure governance applies. Because requests pass through Azure Resource Manager, your existing RBAC assignments, Azure Policy definitions, resource locks, tags, and activity logs work on Oracle resources the same way they work on storage accounts.
- Every Azure resource has an OCI twin. Each Azure resource is backed by an OCI resource with its own OCID. You will see these OCIDs in outputs and occasionally need them.
- The OCI console has not disappeared. Day-to-day work happens in Azure, but certain database-level operations — creating pluggable databases, configuring Data Guard associations, some patching workflows — are performed in the OCI console or through OCI APIs. This is why identity federation matters.
5.3 The identity layer
During onboarding, an OCI tenancy is associated with your Azure subscription. You can optionally federate that tenancy with Microsoft Entra ID so that engineers sign into the OCI console with their corporate Azure credentials rather than a second set of usernames and passwords. Federation is not mandatory, but skipping it means managing a parallel identity store — rarely a good trade in a regulated environment.
5.4 The network layer — the part that matters most
This is where most beginner mistakes happen, so it deserves detail.
You create a subnet in your own Azure virtual network and delegate it to the service using the delegation name Oracle.Database/networkAttachments. Delegation is the mechanism that allows the Oracle service to inject network interfaces for the Exadata VM cluster directly into your VNet address space. The result is that database nodes hold private IP addresses from your CIDR block, and your application subnets reach them by ordinary VNet routing.
On the OCI side, a virtual cloud network (VCN) is created for you. Its client subnet maps to the delegated subnet in Azure; a separate backup subnet exists purely for Oracle-managed backup traffic and is not something you route to.
Planning constraints you need to know before you draw your first diagram:
| Constraint | Value |
|---|---|
| Delegation name | Oracle.Database/networkAttachments |
| Client subnet CIDR size | Between /27 (minimum) and /22 (maximum) |
| Backup subnet CIDR size | Between /27 (minimum) and /22 (maximum) |
| Default backup CIDR if unspecified | 192.168.252.0/22 |
| Reserved range you must not overlap | 192.168.128.0/20 — used by Oracle Clusterware's private interconnect |
| Default limit on delegated subnets per region | 5, raisable via an OCI service-limit request |
| VM clusters per delegated subnet | Multiple allowed, including clusters from different Exadata infrastructure resources |
| Not allowed | Two Exadata infrastructure resources in different availability zones sharing one delegated subnet |
| DNS uniqueness rule | The first 10 characters of your VNet name and subnet name must be unique across Exadata environments, because the generated private DNS zone name is derived from them |
| Default listener ports | 1521 for TCP, 2484 for TCPS |
The diagram below shows how the pieces fit together.
6.Deployment Models: Choosing a Service Tier
"Oracle Database@Azure" is an umbrella. Underneath it sit several distinct services with very different cost profiles and operating models. Choosing correctly is the single highest-leverage decision you will make.
6.1 The options
Base Database Service
Oracle Database on virtual machines, managed by Oracle automation, pay-as-you-go, no Exadata underneath. The entry point for dev environments and small production databases. Reached general availability on the platform in 2025.
Exadata — Dedicated Infrastructure
The classic model. Provision Exadata infrastructure — database and storage servers on generations up to X11M — then create VM clusters on it. Full storage stack: Smart Scan, storage indexes, columnar flash cache, RDMA.
Exadata — Exascale Infrastructure
Exadata capability from a shared, elastic pool with no dedicated servers to provision. Oracle positions the minimum infrastructure cost reduction at up to roughly 95 percent versus dedicated.
Autonomous AI Database (Serverless)
Provisioning, patching, tuning, scaling, and backup all automated. Pick a workload type — transaction processing, data warehousing, JSON, or APEX — set CPU and storage, and start writing SQL.
Autonomous AI Database — Dedicated
Autonomous behaviour on infrastructure reserved for you, for organizations that need isolation guarantees alongside automation.
Supporting services
Oracle GoldenGate for replication and Zero Data Loss Autonomous Recovery Service for backup and recovery are both available on the platform.
6.2 Choosing between them
6.3 Side-by-side summary
| Base Database | Exadata Exascale | Exadata Dedicated | Autonomous Serverless | |
|---|---|---|---|---|
| Underlying platform | Virtual machines | Elastic Exadata pool | Reserved Exadata racks | Shared Exadata |
| Smart Scan / offload | No | Yes | Yes | Yes |
| Real Application Clusters | Optional | Yes | Yes | Managed for you |
| You patch the database | Yes | Yes | Yes | No |
| Entry cost | Lowest | Low | Highest | Low |
| Typical fit | Dev/test, small production | Mid-size production, consolidation | Tier-one mission critical | Analytics, new development, APEX |
| Time to first database | Minutes | Tens of minutes | Hours, including infrastructure | Minutes |
💡 Beginner tip
Start with Base Database Service or Autonomous Serverless for your proof of concept. Exadata infrastructure provisioning is measured in hours, not minutes, and Terraform destroy operations on it are correspondingly slow — not what you want in a first experiment.
7.The Shared Responsibility Model
Misunderstanding this table is a reliable source of production incidents.
| Layer | Owned by |
|---|---|
| Datacenter facility, power, cooling, physical security | Microsoft |
| Exadata hardware, firmware, storage servers, RDMA fabric | Oracle |
| Hypervisor, Grid Infrastructure, database software patching | Oracle (patch windows chosen by you) |
| Azure virtual network, NSGs, route tables, DNS | You |
| Delegated subnet sizing and IP planning | You |
| Database schemas, users, roles, PL/SQL, tuning | You |
| Backup policy and retention configuration | You (Oracle executes) |
| Data Guard / disaster recovery topology | You design, Oracle automates |
| Entra ID users, groups, RBAC, Conditional Access | You |
| Encryption key lifecycle with customer-managed keys | You |
The mental model that works: Oracle keeps the engine running; you decide what it runs, who can reach it, and how the data is protected.
8.Commercial Model: How You Pay
The commercial design is arguably as important as the technical one, because it is what lets a migration clear a finance review.
- Purchased through Microsoft Marketplace. The service is transacted in the Azure Marketplace, typically via a private offer negotiated with Oracle. Since 2025, Microsoft AI Cloud Partners and Oracle Partner Network members have also been able to resell it, so you can buy through an existing partner if you prefer.
- Counts toward your Azure commitment. Spend draws down a Microsoft Azure Consumption Commitment (MACC). For organisations with a large committed spend, this is often the deciding factor.
- Pricing parity with OCI. The stated intent has been feature and price parity with equivalent Oracle Cloud Infrastructure services rather than an Azure markup.
- Bring Your Own License. Existing licences, including unlimited licence agreements, can be applied, and the licence model is a first-class API parameter:
BringYourOwnLicenseorLicenseIncluded. - Oracle Support Rewards. Customers with on-premises Oracle licences remain eligible for support-cost rewards.
- Support. Oracle and Microsoft operate a collaborative support arrangement, so you are not expected to arbitrate between vendors when a problem spans both.
💰 Budget planning note
The largest line item is usually reserved infrastructure, not per-database consumption. Model Exadata infrastructure cost first, then layer database consumption on top — and check whether Exascale changes the arithmetic for your workload size.
9.Where It Fits: Real-World Use Cases
Oracle applications, unmodified
Oracle has published support policies for running E-Business Suite, PeopleSoft, JD Edwards EnterpriseOne, Enterprise Performance Management, and Retail applications on Azure with this service as the database tier. The application stack can move to Azure without the database becoming an unsupported configuration.
Consolidating a sprawling Oracle estate
Dozens of small databases scattered across ageing on-premises servers can be consolidated onto a small number of VM clusters, with pluggable databases providing isolation. Consolidation ratios are usually where the business case is won.
Mission-critical workloads with strict availability targets
Real Application Clusters for node-level resilience, Data Guard for site-level resilience, availability-zone separation for datacenter-level resilience, and Oracle Maximum Availability Architecture tiers up to platinum for the most demanding systems.
Feeding an AI and analytics estate
This is the fastest-moving area. Oracle data can be mirrored into Microsoft Fabric's OneLake with continuous, zero-ETL synchronisation (public preview as of late 2025), and native GoldenGate integration provides managed low-latency replication. Once the data is in Fabric, Power BI, Copilot Studio, and Azure AI Foundry can all work against it. Combined with vector search inside the database itself, retrieval-augmented generation over enterprise data becomes an incremental project rather than a re-platforming exercise.
Latency-sensitive application modernisation
Rewriting a monolith as microservices on AKS is far easier when the new services can query the existing Oracle database over a private IP inside the same datacenter, rather than across a cross-cloud link.
Data residency and regulated industries
Because the service runs in specific Azure regions, data residency commitments can be met while the workload still benefits from Azure's compliance posture and security tooling.
10.Hands-On: Deploying With Code
⚠️ Before you copy anything
Everything below is illustrative and simplified for teaching purposes. Names, CIDRs, and sizes should be replaced with values from your own design, and you should validate resource arguments against current provider documentation before running anything in production — this API surface changes frequently.
10.0 Prerequisites
- An Azure subscription with an active private offer for the service accepted in Marketplace.
- Permissions to create resource groups, virtual networks, and
Oracle.Databaseresources. - An OCI tenancy linked during onboarding (one can be created during the first deployment).
- Azure CLI 2.75 or later — the
oracle-databaseextension installs automatically on first use. - Terraform 1.9 or later if you are using the infrastructure-as-code path.
- An SSH key pair for node access.
10.1 Foundation: resource group and delegated subnet
#!/usr/bin/env bash
set -euo pipefail
LOCATION="eastus"
RG="rg-oracle-demo"
VNET="vnet-oracle-demo"
APP_SUBNET="snet-app"
DB_SUBNET="snet-oracle-delegated"
# Register the resource provider once per subscription
az provider register --namespace Oracle.Database
az provider show --namespace Oracle.Database --query registrationState -o tsv
az group create --name "$RG" --location "$LOCATION"
# Address plan:
# 10.20.0.0/16 VNet
# 10.20.1.0/24 application tier
# 10.20.10.0/24 delegated subnet for the database (must be /27 to /22)
# Avoid overlapping 192.168.128.0/20 anywhere in this VNet.
az network vnet create \
--resource-group "$RG" \
--name "$VNET" \
--address-prefixes 10.20.0.0/16 \
--subnet-name "$APP_SUBNET" \
--subnet-prefixes 10.20.1.0/24
az network vnet subnet create \
--resource-group "$RG" \
--vnet-name "$VNET" \
--name "$DB_SUBNET" \
--address-prefixes 10.20.10.0/24 \
--delegations Oracle.Database/networkAttachments
# Confirm the delegation took effect before going further
az network vnet subnet show \
--resource-group "$RG" \
--vnet-name "$VNET" \
--name "$DB_SUBNET" \
--query "delegations[].serviceName" -o tsv10.2 The same foundation in Bicep
@description('Deployment region')
param location string = resourceGroup().location
param vnetName string = 'vnet-oracle-demo'
param vnetAddressPrefix string = '10.20.0.0/16'
param appSubnetPrefix string = '10.20.1.0/24'
param dbSubnetPrefix string = '10.20.10.0/24'
resource vnet 'Microsoft.Network/virtualNetworks@2023-11-01' = {
name: vnetName
location: location
properties: {
addressSpace: {
addressPrefixes: [ vnetAddressPrefix ]
}
subnets: [
{
name: 'snet-app'
properties: {
addressPrefix: appSubnetPrefix
}
}
{
name: 'snet-oracle-delegated'
properties: {
addressPrefix: dbSubnetPrefix
delegations: [
{
name: 'oracle-database-delegation'
properties: {
serviceName: 'Oracle.Database/networkAttachments'
}
}
]
}
}
]
}
}
output delegatedSubnetId string = vnet.properties.subnets[1].id
output vnetId string = vnet.idaz deployment group create \
--resource-group rg-oracle-demo \
--template-file network.bicep \
--parameters location=eastus10.3 Exadata infrastructure and VM cluster with Terraform
Two resources, created in order. The infrastructure is the rack-level construct; the VM cluster is what actually runs Grid Infrastructure and your databases.
terraform {
required_version = ">= 1.9.0"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 4.0"
}
}
}
provider "azurerm" {
features {}
}
variable "location" { default = "eastus" }
variable "resource_group" { default = "rg-oracle-demo" }
variable "ssh_public_key" { type = string }
data "azurerm_resource_group" "this" {
name = var.resource_group
}
data "azurerm_virtual_network" "this" {
name = "vnet-oracle-demo"
resource_group_name = data.azurerm_resource_group.this.name
}
data "azurerm_subnet" "delegated" {
name = "snet-oracle-delegated"
virtual_network_name = data.azurerm_virtual_network.this.name
resource_group_name = data.azurerm_resource_group.this.name
}
# ---------------------------------------------------------------------------
# 1. Exadata infrastructure (long-running: budget hours, not minutes)
# ---------------------------------------------------------------------------
resource "azurerm_oracle_exadata_infrastructure" "this" {
name = "exa-infra-demo"
resource_group_name = data.azurerm_resource_group.this.name
location = var.location
zones = ["1"]
display_name = "exa-infra-demo"
shape = "Exadata.X11M"
compute_count = 2
storage_count = 3
database_server_type = "X11M"
storage_server_type = "X11M-HC"
customer_contacts = ["dba-team@example.com"]
maintenance_window {
preference = "CustomPreference"
days_of_week = ["Sunday"]
hours_of_day = [2]
lead_time_in_weeks = 2
}
tags = {
environment = "demo"
workload = "oracle"
}
}
# ---------------------------------------------------------------------------
# 2. VM cluster (cluster_name: max 11 chars, no underscores)
# ---------------------------------------------------------------------------
resource "azurerm_oracle_cloud_vm_cluster" "this" {
name = "vmc-oracle-demo"
resource_group_name = data.azurerm_resource_group.this.name
location = var.location
cloud_exadata_infrastructure_id = azurerm_oracle_exadata_infrastructure.this.id
cluster_name = "demoprod01"
display_name = "vmc-oracle-demo"
hostname = "oradb"
gi_version = "19.0.0.0"
cpu_core_count = 4
memory_size_in_gbs = 120
db_node_storage_size_in_gbs = 120
data_storage_size_in_tbs = 2
license_model = "LicenseIncluded"
time_zone = "UTC"
subnet_id = data.azurerm_subnet.delegated.id
virtual_network_id = data.azurerm_virtual_network.this.id
backup_subnet_cidr = "192.168.252.0/22"
ssh_public_keys = [var.ssh_public_key]
tags = {
environment = "demo"
}
}
output "vm_cluster_id" {
value = azurerm_oracle_cloud_vm_cluster.this.id
}
output "vm_cluster_ocid" {
description = "OCID needed when working in the OCI console or OCI APIs"
value = azurerm_oracle_cloud_vm_cluster.this.ocid
}terraform init
terraform plan -var="ssh_public_key=$(cat ~/.ssh/id_rsa.pub)"
terraform apply -var="ssh_public_key=$(cat ~/.ssh/id_rsa.pub)"⚠️ Two practical warnings
Infrastructure is effectively immutable. Exadata infrastructure does not support in-place updates — changing most properties forces a destroy and recreate. Decide on shape and server counts deliberately.
Destroys are slower than the API admits. On terraform destroy the VM cluster often takes longer to delete than reported, which causes the dependent infrastructure delete to fail. Destroy in stages, or re-run after a pause.
If you prefer Microsoft's Azure Verified Modules, equivalent modules wrap these resources with sensible defaults:
module "oracle_vm_cluster" {
source = "Azure/avm-res-oracledatabase-cloudvmcluster/azurerm"
version = "0.3.2"
cloud_exadata_infrastructure_id = azurerm_oracle_exadata_infrastructure.this.id
cluster_name = "demoprod01"
location = var.location
hostname = "oradb"
resource_group_id = data.azurerm_resource_group.this.id
ssh_public_keys = [var.ssh_public_key]
vnet_id = data.azurerm_virtual_network.this.id
subnet_id = data.azurerm_subnet.delegated.id
}10.4 The same deployment with Azure CLI
Useful for scripted environments or when you want to see the API surface directly.
RG="rg-oracle-demo"
LOCATION="eastus"
SUBNET_ID=$(az network vnet subnet show -g "$RG" --vnet-name vnet-oracle-demo \
-n snet-oracle-delegated --query id -o tsv)
VNET_ID=$(az network vnet show -g "$RG" -n vnet-oracle-demo --query id -o tsv)
SSH_KEY=$(cat ~/.ssh/id_rsa.pub)
# Exadata infrastructure
az oracle-database cloud-exadata-infrastructure create \
--name exa-infra-demo \
--resource-group "$RG" \
--location "$LOCATION" \
--zones 1 \
--shape Exadata.X11M \
--compute-count 2 \
--storage-count 3 \
--display-name exa-infra-demo
EXA_ID=$(az oracle-database cloud-exadata-infrastructure show \
--name exa-infra-demo --resource-group "$RG" --query id -o tsv)
# VM cluster
az oracle-database cloud-vm-cluster create \
--name vmc-oracle-demo \
--resource-group "$RG" \
--location "$LOCATION" \
--cloud-exadata-infrastructure-id "$EXA_ID" \
--cluster-name demoprod01 \
--display-name vmc-oracle-demo \
--hostname oradb \
--gi-version 19.0.0.0 \
--cpu-core-count 4 \
--memory-size-in-gbs 120 \
--db-node-storage-size-in-gbs 120 \
--data-storage-size-in-tbs 2 \
--data-storage-percentage 80 \
--license-model LicenseIncluded \
--time-zone UTC \
--is-local-backup-enabled false \
--is-sparse-diskgroup-enabled false \
--ssh-public-keys "$SSH_KEY" \
--subnet-id "$SUBNET_ID" \
--vnet-id "$VNET_ID"
# Wait for provisioning to complete
az oracle-database cloud-vm-cluster wait \
--name vmc-oracle-demo --resource-group "$RG" --created --timeout 1440010.5 The fast path: Autonomous AI Database
If you simply want a database to develop against, skip the infrastructure entirely.
resource "azurerm_oracle_autonomous_database" "demo" {
name = "adb-demo-01"
resource_group_name = data.azurerm_resource_group.this.name
location = var.location
display_name = "adb-demo-01"
db_workload = "OLTP" # OLTP, DW, AJD, or APEX
db_version = "19c"
compute_model = "ECPU"
compute_count = 2
data_storage_size_in_gbs = 32
auto_scaling_enabled = true
auto_scaling_for_storage_enabled = false
admin_password = var.adb_admin_password # keep this in Key Vault, not in tfvars
character_set = "AL32UTF8"
national_character_set = "AL16UTF16"
license_model = "LicenseIncluded"
mtls_connection_required = false
subnet_id = data.azurerm_subnet.delegated.id
virtual_network_id = data.azurerm_virtual_network.this.id
tags = {
environment = "demo"
}
}az oracle-database autonomous-database create \
--name adb-demo-01 \
--resource-group "$RG" \
--location "$LOCATION" \
--display-name adb-demo-01 \
--db-workload OLTP \
--db-version 19c \
--compute-model ECPU \
--compute-count 2 \
--data-storage-size-in-gbs 32 \
--admin-password "$ADB_ADMIN_PASSWORD" \
--character-set AL32UTF8 \
--ncharacter-set AL16UTF16 \
--license-model LicenseIncluded \
--subnet-id "$SUBNET_ID" \
--vnet-id "$VNET_ID"10.6 Creating databases on the VM cluster
A VM cluster is not a database. On the Exadata services you still create a database home and one or more databases, which today is done through the OCI provider or the OCI console using the OCIDs surfaced by the Azure resources.
# Illustrative: requires the OCI provider configured against the tenancy
# associated with your Oracle Database@Azure subscription.
resource "oci_database_db_home" "demo" {
vm_cluster_id = var.vm_cluster_ocid # from the Azure resource output
db_version = "19.24.0.0"
display_name = "dbhome-demo"
database {
db_name = "ORCLDEMO"
pdb_name = "PDB1"
admin_password = var.db_admin_password
character_set = "AL32UTF8"
ncharacter_set = "AL16UTF16"
db_workload = "OLTP"
db_backup_config {
auto_backup_enabled = true
recovery_window_in_days = 30
}
}
}10.7 Post-deployment verification
# List the private IPs assigned to the cluster inside your VNet
az oracle-database cloud-vm-cluster list-private-ip-address \
--cloudvmclustername vmc-oracle-demo \
--resource-group "$RG" \
--subnet-id "<oci-subnet-ocid>" \
--vnic-id "<oci-vcn-ocid>"
# Inspect the full resource, including SCAN and domain details
az oracle-database cloud-vm-cluster show \
--name vmc-oracle-demo --resource-group "$RG" -o jsonc
# From a VM in the application subnet, verify DNS and reachability
nslookup demoprod01-scan.<generated-domain>
nc -zv demoprod01-scan.<generated-domain> 152110.8 Cleaning up
# Terraform: delete the cluster first, then the infrastructure
terraform destroy -target=azurerm_oracle_cloud_vm_cluster.this
terraform destroy
# CLI equivalent
az oracle-database cloud-vm-cluster delete --name vmc-oracle-demo -g "$RG" --yes
az oracle-database cloud-exadata-infrastructure delete --name exa-infra-demo -g "$RG" --yesDo not leave Exadata infrastructure running after a proof of concept. It is the most expensive object in this entire guide.
11.Connecting to the Database
From the application's point of view this is ordinary Oracle connectivity — which is exactly the point of the architecture.
Easy Connect string
oradb-scan.oci<vnetname><subnetname>.oraclevcn.com:1521/PDB1.<domain>tnsnames.ora entry
PDB1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = oradb-scan.example.oraclevcn.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = PDB1.example.oraclevcn.com)
)
)Python, using the thin driver (no Oracle client installation required)
import os
import oracledb
# Credentials belong in Key Vault or a managed identity flow, never in source.
connection = oracledb.connect(
user=os.environ["ORACLE_USER"],
password=os.environ["ORACLE_PASSWORD"],
dsn="oradb-scan.example.oraclevcn.com:1521/PDB1.example.oraclevcn.com",
)
with connection.cursor() as cursor:
cursor.execute("select sys_context('userenv','db_name') as db, banner from v$version")
for db_name, banner in cursor:
print(db_name, banner)
connection.close()A quick smoke test with SQL*Plus
sqlplus app_user@'oradb-scan.example.oraclevcn.com:1521/PDB1.example.oraclevcn.com'SQL> select instance_name, host_name, status from gv$instance;
SQL> select name, open_mode from v$pdbs;✅ What good looks like
If gv$instance returns more than one row, RAC is working and your connection is cluster-aware.
12.Migration Paths
Getting an existing database onto the platform generally uses one of four approaches.
| Method | Downtime | Best for |
|---|---|---|
| Zero Downtime Migration (ZDM) | Minimal | Oracle's purpose-built orchestration tool for moving databases to cloud targets — the default recommendation for most migrations |
| Data Guard physical standby | Minutes (switchover) | Same-version, same-platform moves where you want a rehearsed, reversible cutover |
| GoldenGate replication | Near zero | Cross-version or cross-platform moves, and phased migrations where both systems must run in parallel |
| RMAN restore / Data Pump | Hours | Smaller databases, dev/test environments, or when a maintenance window is available |
Whichever you pick, the sequence that works is: assess (versions, character sets, features in use, database sizes) → size the target → build and validate networking → migrate a non-production copy end to end → performance test with production-like load → then schedule the production cutover. The networking step is the one teams most often underestimate.
13.Operations: Monitoring, Security, and Governance
Metrics, logs, and events in Azure
Database service logs, metrics, and events surface in Azure, so you can build alerts and workbooks in Azure Monitor alongside the rest of your estate rather than maintaining a separate observability stack.
Threat protection
Microsoft Defender extends cloud-native threat detection, vulnerability management, and compliance reporting to these workloads, and Microsoft Sentinel can consume the signal for SIEM correlation across your whole environment.
Identity
Microsoft Entra ID governs who can create and manage the Azure resources; database-level authentication is configured separately, and Entra federation with the OCI tenancy keeps console access on one credential set.
Encryption keys
Transparent Data Encryption keys can be managed in Azure Key Vault. This integration requires private endpoint connectivity plus additional DNS configuration, and depends on the advanced networking option being enabled — plan for it during network design rather than retrofitting it.
Azure Arc
Arc extends Azure's management, policy, and governance plane across these databases, so lifecycle operations and policy enforcement stay consistent with the rest of the estate.
Cost governance
Because consumption lands on the Azure invoice, standard Cost Management tooling — budgets, tags, cost allocation by resource group — applies without a separate process.
14.Common Pitfalls and How to Avoid Them
Undersizing the delegated subnet
The subnet must fall between /27 and /22, and infrastructure components consume addresses beyond the obvious node count. A /27 leaves very little headroom. Model address consumption before you commit — resizing later is disruptive.
Overlapping the interconnect range
Do not use or overlap 192.168.128.0/20 in the client or backup subnet. Clusterware relies on that range for the private interconnect, and an overlap causes malfunctions that are painful to diagnose.
Non-unique names causing DNS collisions
The private DNS zone name derives from the first ten characters of the VNet and subnet names. Naming two environments vnet-production-eastus-01 and ...-02 produces identical prefixes. Put the distinguishing token early in the name.
Illegal cluster names
The cluster name must start with a letter, may include hyphens, must not include underscores, and cannot exceed 11 characters. Terraform fails late on this, after a long wait.
Assuming everything is in Azure
Some operations still route through the OCI console or OCI APIs. Set up federation during onboarding and make sure your DBAs have OCI access before their first incident, not during it.
Skipping region and tier checks
Availability expands continuously — the service passed 28 live regions in late 2025 — but not every service tier is available in every region. Confirm both before designing around it.
15.Frequently Asked Questions
Is this Oracle software running on Azure virtual machines?
No. It runs on Oracle-managed Exadata infrastructure physically located in Azure datacenters. Azure VMs are a different, self-managed option.
Do I need an OCI account?
Yes, a tenancy is associated with the service. It can be created during onboarding if you do not already have one. Most daily work happens in Azure.
Which database versions are supported?
Oracle Database 19c and 23ai are both available, with the exact combinations depending on the service tier you choose.
Does Real Application Clusters work?
Yes, on the Exadata services. This is one of the main reasons organisations choose the platform over converting to another engine.
How is it billed?
Through your Azure agreement. Consumption appears on the Azure invoice and counts toward a Microsoft Azure Consumption Commitment.
Can I use my existing Oracle licences?
Yes, via Bring Your Own License, including unlimited licence agreements. Support Rewards eligibility continues for customers with on-premises licences.
Who do I call when something breaks?
Oracle and Microsoft run a joint support model, so you should not be caught between two vendors on a cross-boundary issue.
Can I get to the data from Microsoft Fabric or Power BI?
Yes. Mirroring into OneLake provides continuous synchronisation without building ETL pipelines, and native GoldenGate integration covers lower-latency replication scenarios.
Is it available in my region?
Availability has been expanding steadily and passed 28 live regions in late 2025. Check the current region list in the documentation, and verify the specific service tier as well as the region.
What is the smallest sensible starting point?
Autonomous AI Database Serverless or Base Database Service. Both avoid a dedicated infrastructure commitment.
16.Glossary
| Term | Meaning |
|---|---|
| ARM | Azure Resource Manager, the control plane through which all Azure resource operations flow |
| Delegated subnet | An Azure subnet handed to a service so it can inject its own network interfaces; here, delegated to Oracle.Database/networkAttachments |
| Exadata | Oracle's engineered database platform combining database servers, intelligent storage servers, and an RDMA network fabric |
| Exascale | A consumption model delivering Exadata capabilities from an elastic shared pool rather than dedicated servers |
| GI (Grid Infrastructure) | The Oracle software layer providing clusterware and storage management for RAC |
| MACC | Microsoft Azure Consumption Commitment, a negotiated committed spend on Azure |
| OCID | Oracle Cloud Identifier, the unique ID of a resource on the OCI side |
| PDB | Pluggable database, a tenant database inside a container database |
| RAC | Real Application Clusters, Oracle's active-active clustering technology |
| SCAN | Single Client Access Name, the cluster-level DNS name clients connect to |
| Smart Scan | Exadata's capability to push query filtering down into the storage tier |
| TDE | Transparent Data Encryption, Oracle's at-rest encryption feature |
| VCN | Virtual Cloud Network, the OCI equivalent of an Azure virtual network |
| ZDM | Zero Downtime Migration, Oracle's migration orchestration tool |
17.Where to Go Next
✅ Key Takeaways
• Oracle Database@Azure is Oracle-managed Exadata inside Azure datacenters, driven by Azure Resource Manager and billed on your Azure agreement — not Oracle on VMs, and not OCI in another region.
• The delegated subnet is the architectural seam. Get the CIDR sizing, the 192.168.128.0/20 exclusion, and the DNS naming right before anything else.
• Tier choice drives cost far more than anything else: Base and Autonomous start small, Exascale removes the dedicated-hardware floor, Dedicated Exadata buys the highest ceiling.
• Governance, security, and cost tooling you already run in Azure — Policy, Defender, Sentinel, Arc, Cost Management — extend to these databases.
A sensible learning path
- Read the network planning documentation twice. Almost every difficult problem on this platform is a networking problem in disguise.
- Deploy an Autonomous AI Database in a sandbox subscription. It takes minutes and teaches you the resource model without a large bill.
- Model the cost of your actual target tier before committing to a design. The gap between Base, Exascale, and Dedicated is substantial.
- Do a full migration rehearsal on a non-production copy, including performance testing under production-like load.
- Wire up governance from day one — Azure Policy, tags, Defender, and cost budgets are much easier to apply at the start than to retrofit across a live estate.
The broader significance of this service is worth a closing thought. For two decades, the enterprise database was the anchor that kept workloads on-premises. An arrangement in which one vendor's engineered systems sit inside another vendor's datacenter, addressable from your own virtual network and billed on your existing commitment, is a genuinely different answer to that problem — and it means "we cannot move because of Oracle" is no longer the conversation-ending objection it once was.
Comments