Things to Know When Migrating Oracle to the Cloud

In an era where digital transformation is paramount, businesses like yours are increasingly transitioning to the public cloud to manage their data. The trend is not just about moving data; it’s about leveraging the cloud’s potential to enhance the most vital and sensitive parts of your IT infrastructure, particularly for handling essential workloads with systems like Oracle. The shift, however, is not without its complexities. Transferring extensive, intricate workloads such as Oracle to a cloud environment is a multifaceted process that presents a myriad of challenges. These challenges differ significantly from those encountered when migration less critical workloads, which are often the pioneers in a company’s cloud journey.

In this blog series, we’ll delve into the specifics of these obstacles and provide a roadmap for navigating through them to achieve a smooth migration of Oracle workloads to the cloud. Beyond just identifying the problems, we’ll present actionable solutions and demonstrate the effectiveness of Silk.

Obstacle: Overprovisioning

When organizations initiate the transition of their Oracle workloads to the cloud, they frequently encounter a critical planning obstacle: the necessity to over provision their cloud resource allocation to meet demands. Overprovisioning is the process of reserving more cloud infrastructure resources – such as computational power, memory allocation, network bandwidth, storage capacity, and processing performance – than may be strictly necessary due to specific demands. This preemptive strategy is rooted in the interconnected nature of cloud resources, where enhancing one aspect often requires scaling up others, even if they are not immediately needed. This intrinsic linkage dictates a package upgrade approach, which can inflate the investment in cloud resources.

For Oracle workloads, which are particularly demanding at the storage tier, the requirement for ultra-fast performance is paramount. Achieving this in the cloud typically means committing to a considerable surplus of resources to ensure peak performance is available when needed. This can lead to provisioning far beyond your actual requirements and the surplus results in inflated operational costs as cloud providers will charge for the total resource provisioned, not just those in active use.

Will will explore the intricacies of this issue, breaking down the mechanisms by which cloud billing can escape due to resource overprovisoning, especially when migrating Oracle workloads.

For those accustomed to on-premises Oracle systems, over provisioning may be a familiar concept. Yet, the cloud environment accentuates this issue due to its inherent flexibility and the ease with which resources can be added on demand. This very flexibility, a significant advantage of cloud computing, can paradoxically lead to a lack of restraint in resource provisioning. Thus, without careful management and strategic planning, the cost-effectiveness of cloud computing can quickly become compromised, with cloud expenses spiraling unexpectedly. We will further discuss strategies to avoid such pitfalls, ensuring that your cloud investment is both efficient and effective.

Performance Data Analysis

Upon meticulous examination of the Automatic Workload Repository (AWR) report, we gain valuable insights into the Input/Output Operations Per Second (IOPS) and bandwidth that are necessitated by this system. The report delineates the demand for 210,000 IOPS for read operations and 37,000 IOPS for write operations. When we aggregate the data throughput, we observe it amounts to 210 megabytes per second for reads and 1.099 megabytes per second for writes. Such figures are crucial in understanding the raw data transfer capabilities required for efficient system performance.

IO Information from an AWR Report

In the above table, an AWR report for a significant high workload has been assessed to identify the needs for IO, vCPU and memory for the database to be migrated to the cloud:

vCPU: 16

Memory:  220G minimum

IO: 100K IOPS/4500MBPs

If we were to size out a VM using native Microsoft Azure IaaS solutions, the VM would need to be scaled, to the point that the Oracle licensing cost would be considerably more than the cloud infrastructure in the cost of the cloud migration project.

The core issue at hand is that most VM configurations provided by cloud vendors, even those supplemented with premium storage options, face challenges in meeting both the IOPS and throughput demands of an Oracle workload without resorting to over-sizing CPU and memory resources. To achieve the requisite, I/O performance natively on Azure, the deployment of a VM with IO limits identified, along with memory and vCPUs, is imperative, as this often comes with significant cost implications. Particularly when considering Oracle licensing fees, which are provisioned by each physical CPU. This consistently results in the majority of budget spent on Oracle licensing vs the cloud migration project. Although the CPU might be adequately sized for the task, the financial impact of paying for unused cores can be substantial due to this fact.

Focusing on one of the few VMs able to handle this kind of high IO workload, the Ebs v5 series, we can quickly view the VMs that meet the needs of the workload:

The table indicates that only a few VM options fulfill the requirements for vCPU, memory, and IO, necessitating an upgrade to at least Standard_E48bs_v5 to meet IO needs, which increases Oracle licensing costs significantly – up to threefold from the base price of $64,500 per processor license. With Silk, IO constraints are network-based, and feature like compression and deduplication lead to better performance. This allows for use of the Standard_E16bs_v5 (16 vCPU, 256GB memory, and much higher limit with network IO), avoiding the need for a larger VM and extra Oracle licensing fees.

Silk’s platform is instrumental in circumventing the dichotomy between vCPU/RAM capacity and I/O performance. It achieves this by leveraging a high-speed network bandwidth, which is significantly faster than the native Azure disk I/O pathways. By allowing for the independent sizing of vCPU/RAM and I/O dimensions, Silk facilitates a more precise and effective configuration of workloads. This targeted approach ensures that CPU resources are not left idle, and RAM is not over provisioned, thus preventing unnecessary drains on IT budgets. By utilizing Silk, organizations can achieve a balance that aligns with their workload demands without succumbing to over provisioning, thereby optimizing both performance and cost.