Merge pull request #36041 from MicrosoftDocs/WilliamDAssafMSFT-patch-2

20251209 remove duplicate line, consolidate caching recommendations

Author: prmerger-automator[bot]

azure-sql/includes/virtual-machines-best-practices-storage.md

@@ -1,13 +1,17 @@
 ---
 author: MashaMSFT
 ms.author: mathoma
-ms.date: 03/20/2025
+ms.date: 12/09/2025
 ms.service: virtual-machines
 ms.topic: include
 ---
 - Monitor the application and [determine storage bandwidth and latency requirements](/azure/virtual-machines/premium-storage-performance#counters-to-measure-application-performance-requirements) for SQL Server data, log, and `tempdb` files before choosing the disk type.
 - If available, configure the `tempdb` data and log files on the D: local SSD volume when you deploy a [new virtual machine](../virtual-machines/windows/storage-configuration.md#new-vms), or after you've [installed SQL Server manually](../virtual-machines/windows/tempdb-ephemeral-storage.md). The SQL IaaS Agent extension handles the folder and permissions needed upon re-provisioning.
 - To optimize storage performance, plan for highest uncached IOPS available and use data caching as a performance feature for data reads while avoiding [virtual machine and disks capping](/azure/virtual-machines/premium-storage-performance#throttling).
+  - Set [host caching](/azure/virtual-machines/disks-performance#virtual-machine-uncached-vs-cached-limits) to **read-only** for data file disks.
+  - Set [host caching](/azure/virtual-machines/disks-performance#virtual-machine-uncached-vs-cached-limits) to **none** for log file disks.
+    - Don't enable read/write caching on disks that contain SQL Server data or log files.
+    - Always stop the SQL Server service before changing the cache settings of your disk.
 - When using the [Ebdsv5 or Ebsv5](/azure/virtual-machines/ebdsv5-ebsv5-series) series SQL Server VMs, use [Premium SSD v2](../virtual-machines/windows/storage-configuration-premium-ssd-v2.md) for the best price performance. You can deploy your SQL Server VM with Premium SSD v2 by using the Azure portal (currently in preview). 
 - If your workload requires more than 160,000 IOPS, use [Premium SSD v2](../virtual-machines/windows/performance-guidelines-best-practices-storage.md#premium-ssd-v2) or [Azure Ultra Disks](../virtual-machines/windows/performance-guidelines-best-practices-storage.md#azure-ultra-disk).
 - Place data, log, and `tempdb` files on separate drives.  
@@ -20,14 +24,9 @@ ms.topic: include
   - For failover cluster instances (FCI) place `tempdb` on the shared storage.
     - If the FCI workload is heavily dependent on `tempdb` disk performance, then as an advanced configuration place `tempdb` on the local ephemeral SSD (default `D:\`) drive, which isn't part of FCI storage. This configuration needs custom monitoring and action to ensure the local ephemeral SSD (default `D:\`) drive is available all the time as any failures of this drive won't trigger action from FCI.
 - Stripe multiple Azure data disks using [Storage Spaces](/windows-server/storage/storage-spaces/overview) to increase I/O bandwidth up to the target virtual machine's IOPS and throughput limits.
-- Set [host caching](/azure/virtual-machines/disks-performance#virtual-machine-uncached-vs-cached-limits) to **read-only** for data file disks.
-- Set [host caching](/azure/virtual-machines/disks-performance#virtual-machine-uncached-vs-cached-limits) to **none** for log file disks.
-  - Don't enable read/write caching on disks that contain SQL Server data or log files.
-  - Always stop the SQL Server service before changing the cache settings of your disk.
 - When migrating several different workloads to the cloud, [Azure Elastic SAN](../virtual-machines/windows/storage-configuration-azure-elastic-san.md) can be a cost-effective consolidated storage solution. However, when using Azure Elastic SAN, achieving desired IOPS/throughput for SQL Server workloads often requires overprovisioning capacity. While not typically appropriate for single SQL Server workloads, you can attain a cost-effective solution when combining low-performance workloads with SQL Server.
 - For development and test workloads, and long-term backup archival consider using standard storage. It isn't recommended to use Standard HDD/SSD for production workloads.
 - [Credit-based Disk Bursting](/azure/virtual-machines/disk-bursting#credit-based-bursting) (P1-P20) should only be considered for smaller dev/test workloads and departmental systems.
-- To optimize storage performance, plan for highest uncached IOPS available, and use data caching as a performance feature for data reads while avoiding [virtual machine and disks capping/throttling](/azure/virtual-machines/premium-storage-performance#throttling).
 - Format your data disk to use 64-KB allocation unit size for all data files placed on a drive other than the temporary `D:\` drive (which has a default of 4 KB). SQL Server VMs deployed through Azure Marketplace come with data disks formatted with allocation unit size and interleave for the storage pool set to 64 KB.
 - Configure the storage account in the same region as the SQL Server VM.
 - Disable Azure geo-redundant storage (geo-replication) and use LRS (local redundant storage) on the storage account.