5 Challenges of Migrating Oracle Workloads to Azure

The Oracle database is widely used around the globe for mission-critical applications and migrating Oracle workloads to the public cloud requires significant planning and testing. This blog examines the 5 challenges of migrating Oracle database workloads to Microsoft Azure and how to solve them.

For more information on how to use the Silk Platform for fast, resilient, and cost-efficient Oracle workloads on Azure, download Silk for Oracle.

Challenge #1: Performance for Data Intensive Workloads

Mission-critical applications on Oracle are data intensive and performance is paramount. The nature of the public cloud as a shared, virtualized environment means that data performance can be unpredictable, with cloud providers setting throttles to place upper limits on speed and volume of data. There is a risk of overpaying for cloud resources to achieve performance. Mission-critical workloads require high throughput and low latency in the cloud to meet user experience and SLA requirements.

Challenge #2: Oracle Database Licensing

Oracle’s database licensing model is complex, requiring customers to tread carefully to avoid unexpected costs. When migrating to the public cloud, an enterprise will likely need additional database licenses because:

The Oracle Processor Core Factor Table is not applicable for Authorized Cloud Environments and the required number of database licenses can increase significantly in comparison to running on-prem.
Cloud vendors set throttles on capacity and performance which results in the need for more (and stronger) VMs and, therefore, more licenses.

Challenge #3: Data Inflation When Migrating from Oracle Exadata

If you are using Oracle Exadata and Hybrid Columnar Compression (HCC) for data compression, there are a couple of items to note when migrating to the public cloud:

Customers migrating from Exadata to Azure face the prospect of “data inflation” as the database expands to its non-HCC-compressed size.
HCC and Exadata are only supported in the Oracle Cloud, so customers migrating to Azure must abandon HCC resulting in a larger database footprint and cloud bill.

One alternative is to use Oracle’s Advanced Compression Option instead, but this incurs further database licensing costs. The additional database server CPU power required to perform these compression operations results in customers deploying larger VMs, with more vCPUs, requiring more database licenses.

Challenge #4: Database Clones

Database clones are used for development, testing, analytics, and production. Oracle customers using Exadata Snap Clones may be surprised to find that creating writeable clones in the public cloud requires the creation of full clones that take up capacity and are time-consuming to manage.

Challenge #5: Resiliency

Data must be secure and resilient. Many Oracle customers use Real Application Clusters (RAC) to run highly available applications across nodes. Oracle RAC is only supported in the Oracle cloud, and a migration to Azure requires different methods to architect for resilience.

How Silk Solves the Challenges of Migrating Oracle Workloads to Azure

10x the Database Performance: Silk is an invisible layer that sits between your application stack and cloud infrastructure to provide low latency and high throughput of data. With performance of more than 1M IOPS, 20 GB/s throughput with consistent sub-millisecond latency, Oracle mission-critical workloads run easily in the Azure cloud. Customers experience 10x the performance and save 30% on cloud costs, and this is without refactoring your application or database.
Reduced Exposure to Oracle Database Licensing Costs: The architecture of Silk overcomes IaaS performance limitations and throttles, allowing the use of less VMs with less vCPUs. Additionally, Silk offloads operations to the data layer, alleviating the requirement for more vCPUs on the database server and the corresponding license requirements.

Silk’s inline data reduction technology uses resources on the data layer to compress and deduplicate your database without exposure to additional licensing costs. This takes place without the need for user intervention and has no effect on performance, offering customers a considerably more cost-efficient solution.

Zero-footprint Clones: With Silk you can create zero-footprint clones that do not impact performance or capacity. Clones can be mounted for read/write purposes, which serve to create additional working environments, at no additional cost of capacity. Read/write clones deliver the same performance of the production copies without any impact on the actual production database.
Rock-Solid Resiliency: The Silk platform provides no-single-point-of- failure architecture, full availability covering zone or region outages, and cross-cloud availability. You can implement effective disaster recovery or business continuity strategies as systems are resilient and self-healing, recovering automatically from hardware failures.