note on Mv3 IOPS with cached disks

Author: msjuergent

articles/sap/workloads/dbms-guide-general.md

@@ -5,7 +5,7 @@ author: msjuergent
 ms.service: sap-on-azure
 ms.subservice: sap-vm-workloads
 ms.topic: article
-ms.date: 09/22/2020
+ms.date: 10/14/2024
 ms.author: juergent
 ms.reviewer: juergent
 
@@ -172,6 +172,9 @@ For Azure premium storage v1, the following caching options exist:
 
 For premium storage v1, we recommend that you use **Read caching for data files** of the SAP database and choose **No caching for the disks of log file(s)**.
 
+> [!NOTE]
+> With some of the new M(b)v3 VM types, the usage of read cached Premium SSD v1 storage could result in lower read and write IOPS rates and throughput than you would get if you don't use read cache. 
+
 For M-Series deployments, we recommend that you use Azure Write Accelerator only for the disks of your log files. For details, restrictions, and deployment of Azure Write Accelerator, see [Enable Write Accelerator](/azure/virtual-machines/how-to-enable-write-accelerator).
 
 For premium storage v2, Ultra disk and Azure NetApp Files, no caching options are offered.

articles/sap/workloads/dbms-guide-oracle.md

@@ -7,7 +7,7 @@ keywords: 'SAP, Azure, Oracle, Data Guard'
 ms.service: sap-on-azure
 ms.subservice: sap-vm-workloads
 ms.topic: article
-ms.date: 04/20/2024
+ms.date: 10/14/2024
 ms.author: juergent
 ms.custom: H1Hack27Feb2017, linux-related-content
 ---
@@ -79,7 +79,9 @@ There are two recommended storage deployment patterns for SAP on Oracle on Azure
 
 Customers currently running Oracle databases on EXT4 or XFS file systems with Logical Volume Manager (LVM) are encouraged to move to ASM. There are considerable performance, administration, and reliability advantages to running on ASM compared to LVM. ASM reduces complexity, improves supportability, and makes administration tasks simpler. This documentation contains links for Oracle Database Administrators (DBAs) to learn how to install and manage ASM.
 
-Azure provides [multiple storage solutions](/azure/virtual-machines/disks-types). The table below details the support status 
+Azure provides [multiple storage solutions](/azure/virtual-machines/disks-types). 
+
+The table below details the support status 
 
 | Storage type  | Oracle support    | Sector Size     | Oracle Linux 8.x or higher | Windows Server 2019 |
 |--------|------------|--------| ------| -----|
@@ -214,7 +216,8 @@ Usually customers are using RMAN, Azure Backup for Oracle and/or disk snap techn
 
 
 > [!NOTE]
-> Azure Host Disk Cache for the DATA ASM Disk Group can be set to either Read Only or None. All other ASM Disk Groups should be set to None. On BW or SCM a separate ASM Disk Group for TEMP can be considered for large or busy systems.
+> Azure Host Disk Cache for the DATA ASM Disk Group can be set to either Read Only or None. Consider that with some of the new M(b)v3 VM types, the usage of read cached Premium SSD v1 storage could result in lower read and write IOPS rates and throughput than you would get if you don't use read cache. All other ASM Disk Groups should be set to None. On BW or SCM a separate ASM Disk Group for TEMP can be considered for large or busy systems.
+
 
 ### Adding Space to ASM + Azure Disks
 

articles/sap/workloads/dbms-guide-sapase.md

@@ -6,7 +6,7 @@ manager: patfilot
 ms.service: sap-on-azure
 ms.subservice: sap-vm-workloads
 ms.topic: article
-ms.date: 11/30/2022
+ms.date: 10/34/2024
 ms.author: juergent
 ms.custom: H1Hack27Feb2017, linux-related-content
 ---
@@ -54,6 +54,9 @@ Typical VM types used for medium size SAP ASE database servers include Esv3.  La
 The SAP ASE transaction log disk write performance may be improved by enabling the M-series Write Accelerator. Write Accelerator should be tested carefully with SAP ASE due to the way that SAP ASE performs Log Writes.  Review [SAP support note #2816580](/azure/virtual-machines/how-to-enable-write-accelerator) and consider running a performance test.  
 Write Accelerator is designed for transaction log disk only. The disk level cache should be set to NONE. Don't be surprised if Azure Write Accelerator doesn't show similar improvements as with other DBMS. Based on the way, SAP ASE writes into the transaction log, it could be that there's little to no acceleration by Azure Write Accelerator.
 
+> [!NOTE]
+> With some of the new M(b)v3 VM types, the usage of read cached Premium SSD v1 storage could result in lower read and write IOPS rates and throughput than you would get if you don't use read cache. 
+
 Separate disks are recommended for Data devices and Log Devices.  The system databases sybsecurity and `saptools` don't require dedicated disks and can be placed on the disks containing the SAP database data and log devices 
 
 ![Storage configuration for SAP ASE](./media/dbms-guide-sap-ase/sap-ase-disk-structure.png)

articles/sap/workloads/dbms-guide-sqlserver.md

@@ -47,6 +47,17 @@ There's some SQL Server in IaaS specific information you should know before cont
 *  **Multiple SAP databases in one single SQL Server instance in a single VM**: Configurations like these are supported. Considerations of multiple SAP databases sharing the shared resources of a single SQL Server instance are the same as for on-premises deployments. Keep other limits like number of disks that can be attached to a specific VM type in mind. Or network and storage quota limits of specific VM types as detailed [Sizes for virtual machines in Azure](/azure/virtual-machines/sizes). 
 
 
+## New M-series VMs and SQL Server
+Azure released a few new families of M-series SKUs under the family of Mv3. Some of the VM types in this family should not be used for SQL Server, including SQL Server 2022. Reason is the number of NUMA nodes presented into the guest OS which with larger than 64 vCPUs is too large for SQL Server to accomodate. The specific VM types are:
+- M176(d)s_3_v3 - use M176bds_4_v3 or M176bds_4_v3 as alternative
+- M176(d)s_4_v3 - use M176bds_4_v3 as alternative
+- M624(d)s_12_v3 - use M416ms_v2 as alternative
+- M832(d)s_12_v3 - use M416ms_v2 as alternative
+- M832i(d)s_16_v3 - use M416ms_v2 as alternative
+
+> [!NOTE]
+> With some of the new M(b)v3 VM types, the usage of read cached Premium SSD v1 storage could result in lower read and write IOPS rates and throughput than you would get if you don't use read cache. 
+
 ## Recommendations on VM/VHD structure for SAP-related SQL Server deployments
 In accordance with the general description, Operating system, SQL Server executables, the SAP executables should be located or installed separate Azure disks. Typically, most of the SQL Server system databases aren't utilized at a high level with SAP NetWeaver workload. Nevertheless the system databases of SQL Server should be, together with the other SQL Server directories on a separate Azure disk. SQL Server tempdb should be either located on the nonperisisted D:\ drive or on a separate disk.
 
@@ -73,6 +84,9 @@ SQL Server proportional fill mechanism distributes reads and writes to all dataf
 
 ### Special for M-Series VMs
 For Azure M-Series VM, the latency writing into the transaction log can be reduced, compared to Azure premium storage performance v1, when using Azure Write Accelerator. If the premium storage v1 provided latency is limiting scalability of the SAP workload, the disk that stores the SQL Server transaction log file can be enabled for Write Accelerator. Details can be read in the document [Write Accelerator](/azure/virtual-machines/how-to-enable-write-accelerator). Azure Write Accelerator doesn't work with Azure premium storage v2 and Ultra disk. In both cases, the latency is better than what Azure premium storage v1 delivers. Write Accelerator is not supporting Premium SSD v2.
+
+> [!NOTE]
+> With some of the new M(b)v3 VM types, the usage of read cached Premium SSD v1 storage could result in lower read and write IOPS rates and throughput than you would get if you don't use read cache. 
   
 
 ### Formatting the disks

articles/sap/workloads/hana-vm-premium-ssd-v1.md

@@ -7,7 +7,7 @@ keywords: 'SAP, Azure HANA, Storage Ultra disk, Premium storage'
 ms.service: sap-on-azure
 ms.subservice: sap-vm-workloads
 ms.topic: article
-ms.date: 09/03/2024
+ms.date: 10/14/2024
 ms.author: juergent
 ms.custom: H1Hack27Feb2017
 ---
@@ -43,6 +43,8 @@ The caching recommendations for Azure premium disks below are assuming the I/O c
 - **/hana/shared** - read caching
 - **OS disk** - don't change default caching that is set by Azure at creation time of the VM
 
+> [!NOTE]
+> With some of the new M(b)v3 VM types, the usage of read cached Premium SSD v1 storage could result in lower read and write IOPS rates and throughput than you would get if you don't use read cache. 
 
 ### Azure burst functionality for premium storage
 For Azure premium storage disks smaller or equal to 512 GiB in capacity, burst functionality is offered. The exact way how disk bursting works is described in the article [Disk bursting](/azure/virtual-machines/disk-bursting). When you read the article, you understand the concept of accruing I/O Operations per second (IOPS) and throughput in the times when your I/O workload is below the nominal IOPS and throughput of the disks (for details on the nominal throughput see [Managed Disk pricing](https://azure.microsoft.com/pricing/details/managed-disks/)). You're going to accrue the delta of IOPS and throughput between your current usage and the nominal values of the disk. The bursts  are limited to a maximum of 30 minutes.