Oracle and Microsoft have expanded their partnership to deliver Oracle database services running on Oracle Cloud Infrastructure (OCI), collocated in Microsoft data centers. Azure customers can now procure, deploy, and use Oracle database services running on OCI within the native Azure portal and APIs, giving them an OCI-in-Azure-like experience. Here are some of the key benefits of Oracle Database@Azure.
Oracle Exadata Database Service on Dedicated Infrastructure, Oracle Exadata Database Service on Exascale Infrastructure, Oracle Autonomous Database Serverless, and Oracle Database Zero Data Loss Autonomous Recovery Service are available. We expect this portfolio to grow rapidly with additional products.
Please refer to the Service Descriptions document (PDF) for the latest.
Migrating to this offering is like migrating to OCI as the database service runs on OCI. Oracle provides proven database migration strategies, including automated migration solutions such as Oracle Zero Downtime Migration and powerful tools such as Oracle Data Guard and Oracle Cloud Infrastructure GoldenGate..
Please refer to the section covering Oracle Database@Azure regions for regional availability and the roadmap. We encourage customers to share any requirements for additional regions with their Oracle or Microsoft account team.
Yes, for consulting services. Please note that Oracle Database@Azure is sold to customers directly via the Azure Marketplace and isn’t available for purchase through any other company or channel.
If you're interested in becoming an Oracle consulting services partner as well as qualifying for a Service Expertise designation, you can find the latest information on the Oracle PartnerNetwork website. Service providers can purchase the offering directly, but not on behalf of customers.
Oracle Exadata Database Service on Dedicated Infrastructure now supports the next-generation Exadata X11M platform.
The provisioning of Oracle Database on Oracle Database@Azure is the same as on OCI, using the same UI flow, API calls, and so on; therefore, any database version currently supported and available on OCI is visible and available on Oracle Database@Azure infrastructure.
As the database is provisioned and managed in OCI, existing database tooling, such as backups and cloning, will be available.
Oracle Database Autonomous Recovery Service is the recommended backup solution for database backup and will draw down on a customer’s MACC when the backup is enabled. Customers can choose to have Oracle Database Autonomous Recovery Service in the Azure region or in the OCI region. Another backup option is Oracle Cloud Infrastructure Object Storage.
Oracle Database@Azure is a standard deployment, available within the Azure VNet. Oracle Database management tools, such as Data Pump, can be used to import data into the database from Azure database clients.
The dynamic routing gateway (DRG) used to provide the link between OCI and Azure network resources is housed within a tightly controlled service virtual cloud network (VCN) and can’t be updated. When provisioned, the Exadata VM cluster resources are attached to this DRG. If you have specific routing requirements, you can use local peering groups to connect to another VCN. This locally peered VCN can then be attached to a DRG you control. This DRG can be used for cross-region replication (see the question about data replication for disaster recovery (DR)).
Oracle Database@Azure is focused on high performance and low-latency workloads running in Azure. If the workload that requires low latency is in OCI, we recommend deploying Oracle Exadata Database Service on Dedicated Infrastructure in OCI. Where available, we recommend using Oracle Interconnect for Microsoft Azure to connect the OCI service and Oracle Database@Azure to meet low-latency needs.
As the database is created via OCI, Oracle Cloud Infrastructure Vault is used to house the system-generated or customer-generated key.
Yes, Oracle Database@Azure supports both dedicated and shared deployments. Oracle Exadata Database Service on Dedicated Infrastructure running inside Azure provides customers with dedicated Exadata compute and storage nodes and gives them full control of their database VMs, just as it does when running on OCI.
Oracle Exadata Database Service on Exascale Infrastructure provides a shared infrastructure service model where Oracle manages all of the physical infrastructure, eliminating the need to provision dedicated database and storage servers. Customer databases run on shared infrastructure with dedicated Exadata Exascale VMs with private storage, and customers retain control over database VMs.
Oracle Autonomous Database Serverless runs on shared Exadata infrastructure. With Autonomous Database Serverless, you don’t need to configure or manage any hardware or install any database software. It handles database provisioning, backups, patching, upgrades, and database scaling.
Yes, Oracle Database@Azure supports both single-tenant and multitenant environments. Oracle Exadata Database Service on Dedicated Infrastructure running inside Azure provides customers with dedicated Exadata compute and storage nodes, just as it does when running on OCI.
No, Oracle Database@Azure is not available in FedRAMP High authorized environments.
Oracle Interconnect for Microsoft Azure now supports Oracle US Government Cloud. Oracle recently announced the general availability of the Oracle US Gov West (Phoenix) and Azure US Gov Arizona (Phoenix) regions for Oracle Interconnect for Microsoft Azure. Joint customers can use Oracle Interconnect for Microsoft Azure to easily migrate their workloads to Oracle Cloud Infrastructure and Azure FedRAMP High authorized environments.
Compliance is a shared responsibility between Oracle and Microsoft. Oracle Database@Azure has been certified for industry standard compliance certifications. For detailed information on the compliance certifications, please visit Oracle Database@Azure Compliance Information
We offer a comprehensive guide for deploying Oracle databases on the SAP NetWeaver Application Server ABAP/Java platform using Oracle Database@Azure, based on Oracle Exadata Cloud Infrastructure X9M with Oracle Linux 8 on the VM cluster nodes. While official SAP certification is required for deployments, you can easily request this certification on demand. In the meantime, you can use the deployment guide provided. If your organization is interested in deploying SAP on Oracle Database@Azure, please reach out to Oracle Sales to complete the SAP certification request.
Oracle Exadata Database Service on Dedicated Infrastructure and Oracle Exadata Database Service on Exascale Infrastructure are both available for purchase via a private offer in the Azure Marketplace, with pricing based on a custom quote. First, you work with Oracle Sales to negotiate the commercial terms, which are formalized in an ordering document that’s shared with you for you to review and accept. Next, Oracle creates a private offer and uploads it to the Azure Marketplace. You must purchase the private offer in the Azure Marketplace to provision the service.
Oracle Exadata Database Service on Exascale Infrastructure is also available as a pay-as-you-go offer, giving organizations of any size a low-cost entry point to bring the power of Exadata to their workloads.
Oracle Autonomous Database is available as a pay-as-you-go offer, giving developers the flexibility to deploy a fully managed database in minutes directly from the Azure Marketplace. The service is also available for purchase via a private offer in the Azure Marketplace, with pricing based on a custom quote. To purchase, contact your Oracle sales representative. They’ll set terms, offer custom pricing, and create an Azure private offer in the Azure Marketplace. You must purchase the private offer in the Azure Marketplace to provision the service.
With the Oracle services on Oracle Database@Azure, you can use your existing Oracle Database licenses, including unlimited license agreements (ULAs) and Oracle Bring Your Own License (BYOL), purchase additional licenses, or use License Included consumption.
Yes. You can use existing Oracle Database licenses, including unlimited license agreements (ULAs) and Oracle Bring Your Own License (BYOL).
Yes, tenancies can either be new or existing. You’ll be given the choice during the onboarding process. As the Oracle Database@Azure service is physically present in Azure, existing Oracle Exadata Database Service on Dedicated Infrastructure environments will not be "moved," either physically or commercially. New Exadata infrastructures built within Azure will be seen in the existing OCI tenancy.
No, pay-as-you-go customers must create a new OCI Account for Oracle Database@Azure. Linking to an existing tenancy is only available through private offer. To learn more, please visit link an existing OCI account to Oracle Database@Azure.
Yes. Using Oracle Database@Azure will accrue the same Oracle Support Rewards as using OCI directly.
Yes. You can use your Microsoft Azure Consumption Commitment (MACC) for Oracle Database@Azure. See Track your Microsoft Azure Consumption Commitment for more information.
For each Exadata Cloud Infrastructure instance you provision, you are billed for an initial 48 hours of consumption, then by the second after that. Each OCPU you provision to run on the infrastructure is billed by the second, with a minimum usage period of one minute. If you terminate the cloud VM cluster and don’t terminate the cloud Exadata infrastructure resource, billing continues for the infrastructure resource.
For each Oracle Exadata Database Service on Exascale Infrastructure resource you provision, you are billed for the VM and storage infrastructure for a minimum of 48 hours, then by the second after that. You can expand the amount of available VM and storage infrastructure at any time. Each ECPU you provision to run on the system is billed by the second, with a minimum usage period of one minute.
Autonomous Database Serverless usage is billed according to the values of two parameters: compute and storage. You select values for these parameters when you provision or scale an Autonomous Database instance. See Autonomous Database Billing Summary for more details.
Oracle consumption maps 1:1 to your Microsoft Azure Consumption Commitment (MACC).
The practical minimum for purchasing Exadata Database Service on Dedicated Infrastructure is as follows:
The smallest configuration for Oracle Exadata Database Service on Exascale Infrastructure on Oracle Database@Azure is two VMs with a total of 16 ECPUs, 560 GB of VM storage, and 300 GB of shared Exascale database storage.
The smallest configuration for Autonomous Database Serverless depends on which service configuration you’re using. For Oracle Autonomous Transaction Processing, it’s two ECPUs with 20 GB of storage, and for Oracle Autonomous Data Warehouse, it’s two ECPUs with 1 TB of storage.
As is standard with Oracle Exadata Database Service on Dedicated Infrastructure, each Oracle Database Exadata infrastructure shape/instance has a minimum service period of 48 hours.
Oracle Exadata Database Service on Exascale Infrastructure requires a minimum commitment of 48 hours.
There is no minimum service period for Oracle Autonomous Database Serverless.
At present, there is no Free Tier option.
Any OCI cross-region traffic that normally incurs network bandwidth costs will draw down on a customer’s MACC (for example, a customer with cross-region disaster recovery using Oracle Database@Azure in region one and region two would incur network traffic costs).
The following Oracle Applications are now supported on Azure when run on Oracle Database@Azure:
Please refer to the following support policies for details:
Oracle and Microsoft have developed a joint support model to ensure rapid response and resolution for mission-critical workloads. Customers will create all technical support requests directly with Oracle. Oracle will engage Microsoft support if needed.
Oracle and Microsoft have partnered to provide you with a well-integrated Azure experience for deploying, managing, and using Oracle Database instances in Azure. For most day-to-day operations, you’ll be able to use native Azure tooling.
Oracle Database@Azure will be made available in multiple availability zones within an Azure region and multiple Azure regions within a geography. Customers can use Oracle Data Guard to deploy DR solutions. Refer to the reference architecture to deploy a DR solution using Data Guard across availability zones within a region that meets the Oracle Maximum Availability Architecture (MAA) Gold standard. To learn more, refer to Oracle Maximum Availability Architecture for Oracle Database@Azure.
Oracle Database@Azure will be made available in multiple availability zones within an Azure region to meet high availability (HA) and disaster recovery requirements.
No. Oracle owns the link, the management, and the traffic flowing between the Azure data center and the OCI parent data center. Azure and OCI management networks don’t intersect. Azure has no visibility past the termination point in the partner transfer equipment within the data center where Oracle connects. And vice versa, Oracle can’t see past this same point. The network link is treated as internal to Oracle.
Operator Access Control is available for Oracle Compute Cloud@Customer, Exadata Cloud@Customer, and Autonomous Exadata VM clusters on client virtual machines deployed on Oracle Autonomous Database on Exadata Cloud@Customer.
Oracle Database@Azure management is the same as Oracle Exadata Database Service on OCI; therefore, Operator Access Control isn’t applicable.
Oracle Database@Azure resources that are provisioned and managed via the Oracle Database resource provider in Azure can be operated and managed from the Azure console, API, SDK, or CLI.
Expansion of the resources and features managed by the Oracle resource provider are on the roadmap.
The Oracle Database@Azure infrastructure is identical to that in OCI; therefore, standard Exadata and Oracle Database sizing tools, such as Oracle Cloud Capacity Analytics, can be used.
The Oracle Database@Azure hardware is deployed in the availability zone of the Azure region equivalent to the availability domain (AD) in OCI. For Azure and OCI regions that have multiple AZs and ADs, the Oracle Database@Azure hardware will be deployed in AZs with a 1:1 mapping to the OCI AD.
The network between the Oracle Database@Azure deployment in Azure and its parent OCI site is dedicated, redundant, Oracle internally managed dark fiber, similar to OCI AD-to-AD network infrastructure. The connection between the Oracle Database@Azure onsite hardware and Azure is achieved via local connectivity through redundant network hardware direct to Azure network infrastructure.
Each Oracle Database@Azure deployment is connected to an OCI parent site. This link is used for the following:
The network between the OCI parent and Oracle Database@Azure infrastructure is considered an internal regional network; therefore, no traffic costs or throttling limits are in place. Any capacity and other limits imposed on Azure virtual networking are still in effect (for example, bandwidth between the delegated subnet and Azure Private Link is limited to 50 Gb/sec, affecting services such as Azure Blob Storage access).
No, Oracle Interconnect for Azure is a standalone Oracle service available for customers to consume when deploying Oracle and Azure cloud services that require interconnectivity. Oracle Database@Azure doesn’t use this network link.
Both the OCI-Azure interconnect and Oracle Database@Azure take advantage of the proximity between clouds; therefore, there may be significant overlap in future region rollouts.
If you wish to use other OCI services with Azure services, Oracle Interconnect for Azure will need to be configured.
All traffic between sites, including Oracle Database@Azure infrastructure, is encrypted.
Oracle Data Guard redo logs are shipped from the primary database to the standby database via the client subnet across customer-managed networks on OCI infrastructure.
* Incurs outbound data transfer costs.
Existing Exadata deployments will still be operational; however, customers won't be able to create, update, or delete resources. Any process or procedure relying on OCI-based services (for example, OCI Vault key lookup, database backups, and so on) will fail.
Metrics and logging shipped from OCI to Azure Monitor will be delayed, even though the Exadata deployment is functional.
It is expected that all control plane functionality will become unavailable.