Oracle workloads using Intel Optane DC PMM in Memory Mode on VMware vSphere platform – An Investigation

Techopedia – “While scaling out involves adding more discrete units to a system in order to add capacity, scaling up involves building existing units by integrating resources into them”

Business-critical production Oracle workload are very resource intensive and large memory sizes are characteristics of production databases to ensure that the working set of the database fits into DRAM for fast access to data.

Let us look at the different options we have currently with the demand for memory increase for Oracle workloads –

• Increased Cost with buying more DRAM ($$$) – cost to adding additional DRAM to beef up the system for large memory allocations
• Memory Latency with sizing workloads across multiple NUMA nodes to take advantage of remote memory to fulfill memory needs – With NUMA servers, one has an option of accessing memory from remote NUMA nodes across QPI/UPI interconnects but …. there is memory latency that one would encounter with remote memory accesses.

Ok, let’s look at our choices – Increased cost ($$$) OR Memory Latency for critical workloads ?

Enter VMware vSphere platform with Intel DC Optane PMM in Memory Mode.

VMware vSphere usage of Intel Optane PMem in Memory Mode can offer increased memory capacity and TCO improvements for large memory bound workloads without having to buy expensive DRAM’s or size workloads across NUMA modes for added memory needs.

This blog demonstrates how one can achieve similar performance running Oracle workloads on VMware vSphere with Intel Optane PMEM in Memory Mode as compared to running the same workloads on VMware platform by spreading memory across NUMA nodes (or adding expensive DRAM – this blog focused on comparing Memory Mode v/s NUMA access) to satisfy the memory demand – with the advantage of not needing to buy expensive DRAM or going across NUMA nodes for added memory increase.

Accelerate Oracle Smart Flash Cache performance using Intel Optane DC PMM backed Oracle 21c Persistent Memory Filestore on VMware vSphere

Wikipedia – Nicknamed the “Scarlet Speedster”, all incarnations of the Flash possess “super speed“, which includes the ability to run, move, and think extremely fast, use superhuman reflexes, and seemingly violate certain laws of physics.

This blog demonstrates how performance of Oracle Smart Flash Cache can be accelerated using Persistent Memory (PMEM) technology by using Intel Optane DC PMM in App Direct mode backed Oracle 21c Persistent Memory Filestore on VMware vSphere platform.

This blog is the 2^nd blog in this series of accelerating Oracle workloads using Intel Optane DC PMM in App Direct mode backed Oracle 21c Persistent Memory Filestore on VMware vSphere platform.

The 1^st blog of the series was Accelerate Oracle Redo performance using Intel Optane DC PMM backed Oracle 21c Persistent Memory Filestore on VMware vSphere

Yes, your Oracle workload is now truly a “Speed King”.

Accelerate Oracle Redo performance using Intel Optane DC PMM backed Oracle 21c Persistent Memory Filestore on VMware vSphere

Pulling a rabbit out from a hat when you thought the magician had magically whisked him away forever to a far far away land – all of us have seen that.

What if we tell you data in memory persists across server reboots – that’s our rabbit magically reappearing every time the magician waves his magic wand and says ‘abracadabra’.

Enter Persistent Memory Technology where Persistent Memory (PMEM) resides between DRAM and disk storage in the data storage hierarchy. This  technology enables byte-addressable updates and does not lose data if power is lost.

PMEM is a byte-addressable form of computer memory that has the following characteristics:

• DRAM-like latency and bandwidth
• Regular load/store CPU instructions
• Paged/mapped by operating system just like DRAM
• Data is persistent across reboots

Business Critical Oracle databases would benefit from using  Persistent Memory technology to provide the resilience and SLA guarantee for critical workloads along with DRAM like latency and bandwidth.

This blog demonstrates how performance of Oracle Redo Logs can be accelerated using  Persistent Memory technology by using Intel Optane DC PMM in App Direct mode backed Oracle 21c Persistent Memory Filestore on VMware vSphere platform.

Yes, you can have your cake and eat it too !!

Oracle Workloads and Redo Log Blocksize – 512 bytes or 4k blocksize for redo log

What if Obelix of the Asterix & Obelix fame had to throw ‘512-byte size’ menhirs at the Romans? That would take him a long time , yes, even with the magic portion , to get all the Romans. hmmm..

‘4k size’ giant  menhir ? Yes, that’s effective.

Business Critical Oracle databases would benefit from using 4k redo blocksize to drive IO intensive workloads as opposed to using 512byte redo blocksize for all the obvious reasons , yes , it comes at the cost of redo wastage but there are pros and cons to every thing.

This blog addresses the advantages of using Oracle Redo Log with 4k blocksize (default is 512 bytes with blocksize choices  512bytes, 1k and 4k) on VMware platforms and current challenges associated with that with roadmap guidance.

Architecting General Business Critical Applications (BCA) and Oracle on VMware vSphere Platform – Revamped Best Practices Guide

VMware has created separate best practice documents for compute, storage, networking, and performance. The latest guide can be found at Performance Best Practices for VMware vSphere.

The BCA team (Sudhir Balasubramanian , Oleg Ulyanov and Deji Akomolafe) has undertaken a major overhaul of the Common BCA Best Practices in 2021.

The General BCA Best Practices guide released Nov , 2021 Architecting Business Critical Applications on VMware Hybrid Multi-Clouds provides best practice general guidelines for designing and implementing business-critical application (BCA) workloads on VMware vSphere platforms. The recommendations are not specific to a particular hardware set, nor to the size and scope of a particular BCA workload implementation.

The examples and considerations in this document provide guidance only and do not represent strict design requirements, as varying application requirements can result in many valid configuration possibilities.

The General BCA Best Practices guide Architecting Business Critical Applications on VMware Hybrid Multi-Clouds holds good for all General Best Practices for deploying any Applications on VMware vSphere platform.

In addition to the above General BCA Best Practices guide , the Oracle on VMware Best Practices guide has been revamped and released on November, 2021 by Sudhir Balasubramanian. It holds good for all versions of Oracle starting 11gR2 and all versions of VMware vSphere starting 5.x.

The Oracle on VMware Best Practices guide can be found at Architecting Oracle Workloads on VMware Hybrid Multi-Clouds BEST PRACTICES GUIDE

Oracle Real Application Cluster (RAC) Support on Non-Oracle Clouds

On December 15th , 2020 , there was recent changes made to the Oracle document  – “Oracle Real Application Clusters (RAC) Support on Third-Party Clouds – An Overview and Clarification – Revision 2020.06.14”.

“Oracle Real Application Clusters (RAC) Support on Third-Party Clouds – An Overview and Clarification – Revision 2020.06.14”.

The document My Oracle Support Note 2688277.1 “Oracle Database Support for Non-Oracle Public Cloud Environments”. is as below

As per the above Note  – “Oracle does not support Oracle RAC or Oracle RAC One Node running on Non-Oracle Public Cloud Environments”

Please reach out to your Oracle Representative for further clarification in this regard.

Oracle Business Continuity and Disaster Recovery on VMware Hybrid Multi-Clouds

Customers have successfully run their business-critical Oracle workloads with high-performance demands on VMware vSphere for many years.

Common concerns that often delay virtualization of business-critical database workloads include:

• Rapid database growth and the need to reduce backup windows to meet performance and business SLAs
• The size of modern databases makes it harder to regularly clone and refresh data from production to QA and other environments
• Choosing the optimum business continuity plan to ensure rapid recovery from significant disruption to the operations
• Making the Correct choice of disaster recovery technology to ensure business needs of RTO and RPO are met

Solution

This paper describes the configuration and implementation of various business continuity and disaster recovery options (Native Oracle , SRM, vSphere Replication, Array based using VMFS/vVOLS, VSR , VCDR) across the application, VMware platform, and storage levels of Oracle single instance and Real Application Cluster (RAC) workloads on the VMware vSphere hybrid multi-cloud platform. This includes on-premises and VMware clouds, with an emphasis on VMware Cloud™ on AWS.

Moving away from DBA-as-a-Service to Database as a Service (DBaaS) for Oracle Workloads on VMware Hybrid Platform

Deploying and managing an Oracle DB environment is not a trivial undertaking. Oracle infrastructure tends to have stringent performance, business continuity, and backup and recovery requirements. To support these requirements, IT departments often are tasked with maintaining sprawling infrastructure for production, disaster recovery, backup, quality assurance, test, training, development, and sandbox.

Enterprise customers have identified Database-as-a-Service (DBaaS) as a key initiative that will enable higher levels of agility via rapid application development. The idea is to allow database consumers such as application developers, testers, and architects to provision databases easily using an on-demand, self-service platform.

DBaaS will greatly simplify the deployment and management of a robust Oracle environment, while delivering higher levels of efficiency and flexibility for IT departments throughout the application lifecycle—implementation, migrations, consolidations, upgrades, and ongoing maintenance , thus allowing DBA’s to focus on more important pressing issues – Moving away from DBA-as-a-Service to Database as a Service (DBaaS) model.

This blog focuses on VMware Virtual Volumes (vVols) using Pure Storage and how vVols can greatly enhance DBaaS to provide higher levels of agility via rapid application development for both on-premises and the cloud for Oracle workloads on VMware Hybrid Platform.

Storage vMotion for Oracle Non-RAC Workloads within same vSphere Cluster

In the world of Business-Critical Applications, especially IO intensive Oracle workloads, there is always a need for storage migration, based on the ever-demanding workload profile. For example,

• Migrate storage from one Tier to another Tier within a storage array
• Migrate storage from one array to another array (within a datacenter and even between datacenters as part of DC relocation)

This approach is independent of whether those workloads are virtualized or not. The end goal is to ensure that the underlying storage architecture can provide and sustain the demanding needs of the Application.

This article describes how storage migration can be performed for Oracle database running on VMware vSphere, for any types of underlying storage.  The migration is done using a combination of two key technologies depending on the database deployment model

• VMware Storage vMotion
• Oracle Automatic Storage Management (ASM).

Before describing this technique, we first review some key ideas, including the deployment model of Oracle on vSphere and the fundamentals of Storage vMotion.

This blog focuses on Storage vMotion of Oracle Non-RAC workloads within the same vSphere Cluster.

Hot Remove CPU and Memory for Oracle production workloads

The previous blog On Demand Scaling up resources for Oracle production workloads – Hot Add CPU and Hot Add Memory focused on how to stop hoarding much needed infrastructure resources and live wisely ever after by scaling up as needed effectively.

This blog focuses on the Hot Remove CPU and Memory aspect of Oracle Workloads and the current limitations associated with these technologies.