Azure Virtual Machines DBMS deployment for SAP workload

This document covers several different areas to consider when you're deploying Oracle Database for SAP workload in Azure IaaS. Before you read this document, we recommend you read Considerations for Azure Virtual Machines DBMS deployment for SAP workload. We also recommend that you read other guides in the SAP workload on Azure documentation.

You can find information about Oracle versions and corresponding OS versions that are supported for running SAP on Oracle on Azure in SAP Note 2039619.

General information about running SAP Business Suite on Oracle can be found at SAP on Oracle. Oracle software is supported by Oracle to run on Microsoft Azure. For more information about general support for Windows Hyper-V and Azure, check the Oracle and Microsoft Azure FAQ.

SAP Notes relevant for Oracle, SAP, and Azure

The following SAP Notes are related to SAP on Azure.

Note number Title
1928533 SAP Applications on Azure: Supported products and Azure VM types
2015553 SAP on Microsoft Azure: Support prerequisites
1999351 Troubleshooting enhanced Azure monitoring for SAP
2178632 Key monitoring metrics for SAP on Microsoft Azure
2191498 SAP on Linux with Azure: Enhanced monitoring
2039619 SAP applications on Microsoft Azure using the Oracle database: Supported products and versions
2243692 Linux on Microsoft Azure (IaaS) VM: SAP license issues
2069760 Oracle Linux 7.x SAP installation and upgrade
1597355 Swap-space recommendation for Linux
2171857 Oracle Database 12c - file system support on Linux
1114181 Oracle Database 11g - file system support on Linux

The exact configurations and functionality that are supported by Oracle and SAP on Azure are documented in SAP Note #2039619.

Windows and Oracle Linux are the only operating systems that are supported by Oracle and SAP on Azure. The widely used SLES and RHEL Linux distributions aren't supported for deploying Oracle components in Azure. Oracle components include the Oracle Database client, which is used by SAP applications to connect against the Oracle DBMS.

Exceptions, according to SAP Note #2039619, are SAP components that don't use the Oracle Database client. Such SAP components are SAP's stand-alone enqueue, message server, Enqueue replication services, WebDispatcher, and SAP Gateway.

Even if you're running your Oracle DBMS and SAP application instances on Oracle Linux, you can run your SAP Central Services on SLES or RHEL and protect it with a Pacemaker-based cluster. Pacemaker as a high-availability framework isn't supported on Oracle Linux.

Specifics for Oracle Database on Windows

Oracle Configuration guidelines for SAP installations in Azure VMs on Windows

In accordance with the SAP installation manual, Oracle-related files shouldn't be installed or located in the system driver for a VM's OS disk (drive c:). Virtual machines of varying sizes can support a varying number of attached disks. Smaller virtual machine types can support a smaller number of attached disks.

If you have smaller VMs, we recommend installing/locating Oracle home, stage, "saptrace", "saparch", "sapbackup", "sapcheck", or "sapreorg" into the OS disk. These parts of Oracle DBMS components aren't intense on I/O and I/O throughput. This means that the OS disk can handle the I/O requirements. The default size of the OS disk is 127 GB.

If there isn't enough free space available, the disk can be resized to 2048 GB. Oracle Database and redo log files need to be stored on separate data disks. There's an exception for the Oracle temporary tablespace. Tempfiles can be created on D:/ (non-persistent drive). The non-persistent D:\ drive also offers better I/O latency and throughput (with the exception of A-Series VMs).

To determine the right amount of space for the tempfiles, you can check the sizes of the tempfiles on existing systems.

Storage configuration

Only single-instance Oracle using NTFS formatted disks is supported. All database files must be stored on the NTFS file system on Managed Disks (recommended) or on VHDs. These disks are mounted to the Azure VM and are based on Azure page blob storage or Azure Managed Disks.

We strongly recommend using Azure Managed Disks. We also strongly recommend using premium SSDs for your Oracle Database deployments.

Network drives or remote shares like Azure file services aren't supported for Oracle Database files. For more information, see:

If you're using disks that are based on Azure page blob storage or Managed Disks, the statements in Considerations for Azure Virtual Machines DBMS deployment for SAP workload apply to deployments with Oracle Database as well.

Quotas on IOPS throughput for Azure disks exist. This concept is explained in Considerations for Azure Virtual Machines DBMS deployment for SAP workload. The exact quotas depend on the VM type that you use. A list of VM types with their quotas can be found at Sizes for Windows virtual machines in Azure.

To identify the supported Azure VM types, see SAP Note 1928533.

The minimum configuration is as follows:

Component Disk Caching Storage pool
\oracle<SID>\origlogaA & mirrlogB Premium None Not needed
\oracle<SID>\origlogaB & mirrlogA Premium None Not needed
\oracle<SID>\sapdata1...n Premium Read-only Can be used
\oracle<SID>\oraarch Standard None Not needed
Oracle Home, saptrace, ... OS disk Not needed

Disks selection for hosting online redo logs should be driven by IOPs requirements. It's possible to store all sapdata1...n (tablespaces) on one single mounted disk as long as the size, IOPS, and throughput satisfy the requirements.

The performance configuration is as follows:

Component Disk Caching Storage pool
\oracle<SID>\origlogaA Premium None Can be used
\oracle<SID>\origlogaB Premium None Can be used
\oracle<SID>\mirrlogAB Premium None Can be used
\oracle<SID>\mirrlogBA Premium None Can be used
\oracle<SID>\sapdata1...n Premium Read-only Recommended
\oracle\SID\sapdata(n+1)* Premium None Can be used
\oracle<SID>\oraarch* Premium None Not needed
Oracle Home, saptrace, ... OS disk Not needed

*(n+1): hosting SYSTEM, TEMP, and UNDO tablespaces. The I/O pattern of System and Undo tablespaces are different from other tablespaces hosting application data. No caching is the best option for performance of the System and Undo tablespaces.

*oraarch: storage pool isn't necessary from a performance point of view. It can be used to get more space.

If more IOPS are required, we recommend using Windows Storage Pools (only available in Windows Server 2012 and later) to create one large logical device over multiple mounted disks. This approach simplifies the administration overhead for managing the disk space, and helps you avoid the effort of manually distributing files across multiple mounted disks.

Write Accelerator

For Azure M-Series VMs, the latency writing into the online redo logs can be reduced by factors when compared to Azure Premium Storage. Enable Azure Write Accelerator for the disks (VHDs) based on Azure Premium Storage that are used for online redo log files. For more information, see Write Accelerator.

Backup/restore

For backup/restore functionality, the SAP BR*Tools for Oracle are supported in the same way as they are on standard Windows Server operating systems. Oracle Recovery Manager (RMAN) is also supported for backups to disk and restores from disk.

You can also use Azure Backup to run an application-consistent VM backup. The article Plan your VM backup infrastructure in Azure explains how Azure Backup uses the Windows VSS functionality for executing application-consistent backups. The Oracle DBMS releases that are supported on Azure by SAP can leverage the VSS functionality for backups. For more information, see the Oracle documentation Basic concepts of database backup and recovery with VSS.

High availability

Oracle Data Guard is supported for high availability and disaster recovery purposes. To achieve automatic failover in Data Guard, your need to use Fast-Start Failover (FSFA). The Observer (FSFA) triggers the failover. If you don't use FSFA, you can only use a manual failover configuration.

For more information about disaster recovery for Oracle databases in Azure, see Disaster recovery for an Oracle Database 12c database in an Azure environment.

Accelerated networking

For Oracle deployments on Windows, we strongly recommend accelerated networking as described in Azure accelerated networking. Also consider the recommendations that are made in Considerations for Azure Virtual Machines DBMS deployment for SAP workload.

Other

Considerations for Azure Virtual Machines DBMS deployment for SAP workload describes other important concepts related to deployments of VMs with Oracle Database, including Azure availability sets and SAP monitoring.

Specifics for Oracle Database on Oracle Linux

Oracle software is supported by Oracle to run on Microsoft Azure with Oracle Linux as the guest OS. For more information about general support for Windows Hyper-V and Azure, see the Azure and Oracle FAQ.

The specific scenario of SAP applications leveraging Oracle Databases is supported as well. Details are discussed in the next part of the document.

Oracle version support

For information about which Oracle versions and corresponding OS versions are supported for running SAP on Oracle on Azure Virtual Machines, see SAP Note 2039619.

General information about running SAP Business Suite on Oracle can be found in the SAP on Oracle community page.

Oracle configuration guidelines for SAP installations in Azure VMs on Linux

In accordance with SAP installation manuals, Oracle-related files shouldn't be installed or located into system drivers for a VM's boot disk. Varying sizes of virtual machines support a varying number of attached disks. Smaller virtual machine types can support a smaller number of attached disks.

In this case, we recommend installing/locating Oracle home, stage, saptrace, saparch, sapbackup, sapcheck, or sapreorg to boot disk. These parts of Oracle DBMS components aren't intense on I/O and I/O throughput. This means that the OS disk can handle the I/O requirements. The default size of the OS disk is 30 GB. You can expand the boot disk by using the Azure portal, PowerShell, or CLI. After the boot disk has been expanded, you can add an additional partition for Oracle binaries.

Storage configuration

The filesystems of ext4, xfs, or Oracle ASM are supported for Oracle Database files on Azure. All database files must be stored on these file systems based on VHDs or Managed Disks. These disks are mounted to the Azure VM and are based on Azure page blob storage or Azure Managed Disks.

For Oracle Linux UEK kernels, a minimum of UEK version 4 is required to support Azure premium SSDs.

It is highly recommended to use Azure managed disks. It also is highly recommended using Azure premium SSDs for your Oracle Database deployments.

Network drives or remote shares like Azure file services aren't supported for Oracle Database files. For more information, see the following:

If you're using disks based on Azure page blob storage or Managed Disks, the statements made in Considerations for Azure Virtual Machines DBMS deployment for SAP workload apply to deployments with Oracle Database as well.

Quotas on IOPS throughput for Azure disks exist. This concept is explained in Considerations for Azure Virtual Machines DBMS deployment for SAP workload.The exact quotas depend on the VM type that's used. For a list of VM types with their quotas, see Sizes for Linux virtual machines in Azure.

To identify the supported Azure VM types, see SAP Note 1928533.

Minimum configuration:

Component Disk Caching Stripping*
/oracle/<SID>/origlogaA & mirrlogB Premium None Not needed
/oracle/<SID>/origlogaB & mirrlogA Premium None Not needed
/oracle/<SID>/sapdata1...n Premium Read-only Can be used
/oracle/<SID>/oraarch Standard None Not needed
Oracle Home, saptrace, ... OS disk Not needed

*Stripping: LVM stripe or MDADM using RAID0

The disk selection for hosting Oracle's online redo logs should be driven by IOPS requirements. It's possible to store all sapdata1...n (tablespaces) on a single mounted disk as long as the volume, IOPS, and throughput satisfy the requirements.

Performance configuration:

Component Disk Caching Stripping*
/oracle/<SID>/origlogaA Premium None Can be used
/oracle/<SID>/origlogaB Premium None Can be used
/oracle/<SID>/mirrlogAB Premium None Can be used
/oracle/<SID>/mirrlogBA Premium None Can be used
/oracle/<SID>/sapdata1...n Premium Read-only Recommended
/oracle/<SID>/sapdata(n+1)* Premium None Can be used
/oracle/<SID>/oraarch* Premium None Not needed
Oracle Home, saptrace, ... OS disk Not needed

*Stripping: LVM stripe or MDADM using RAID0

*(n+1):hosting SYSTEM, TEMP, and UNDO tablespaces: The I/O pattern of System and Undo tablespaces are different from other tablespaces hosting application data. No caching is the best option for performance of the System and Undo tablespaces.

*oraarch: storage pool isn't necessary from a performance point of view.

If more IOPS are required, we recommend using LVM (Logical Volume Manager) or MDADM to create one large logical volume over multiple mounted disks. For more information, see Considerations for Azure Virtual Machines DBMS deployment for SAP workload regarding guidelines and pointers on how to leverage LVM or MDADM. This approach simplifies the administration overhead of managing the disk space and helps you avoid the effort of manually distributing files across multiple mounted disks.

Write Accelerator

For Azure M-Series VMs, when you use Azure Write Accelerator, the latency writing into the online redo logs can be reduced by factors when compared to Azure Premium Storage performance. Enable Azure Write Accelerator for the disks (VHDs) based on Azure Premium Storage that are used for online redo log files. For more information, see Write Accelerator.

Backup/restore

For backup/restore functionality, the SAP BR*Tools for Oracle are supported in the same way as they are on bare metal and Hyper-V. Oracle Recovery Manager (RMAN) is also supported for backups to disk and restores from disk.

For more information about how you can use Azure Backup and Recovery services for backing up and recovering Oracle databases, see Back up and recover an Oracle Database 12c database on an Azure Linux virtual machine.

High availability

Oracle Data Guard is supported for high availability and disaster recovery purposes. To achieve automatic failover in Data Guard, you need to use Fast-Start Failover (FSFA). The Observer functionality (FSFA) triggers the failover. If you don't use FSFA, you can only use a manual failover configuration. For more information, see Implement Oracle Data Guard on an Azure Linux virtual machine.

Disaster Recovery aspects for Oracle databases in Azure are presented in the article Disaster recovery for an Oracle Database 12c database in an Azure environment.

Accelerated networking

Support for Azure Accelerated Networking in Oracle Linux is provided with Oracle Linux 7 Update 5 (Oracle Linux 7.5). If you can't upgrade to the latest Oracle Linux 7.5 release, there might be a workaround by using the RedHat Compatible Kernel (RHCK) instead of the Oracle UEK kernel.

Using the RHEL kernel within Oracle Linux is supported according to SAP Note #1565179. For Azure Accelerated Networking, the minimum RHCKL kernel release needs to be 3.10.0-862.13.1.el7. If you're using the UEK kernel in Oracle Linux in conjunction with Azure Accelerated Networking, you need to use Oracle UEK kernel version 5.

If you're deploying VMs from an image that's not based on Azure Marketplace, then you need to copy additional configuration files to the VM by running the following code:

# Copy settings from GitHub to the correct place in the VM
sudo curl -so /etc/udev/rules.d/68-azure-sriov-nm-unmanaged.rules https://raw.githubusercontent.com/LIS/lis-next/master/hv-rhel7.x/hv/tools/68-azure-sriov-nm-unmanaged.rules 

Other

Considerations for Azure Virtual Machines DBMS deployment for SAP workload describes other important concepts related to deployments of VMs with Oracle Database, including Azure availability sets and SAP monitoring.