Merge pull request #92655 from MashaMSFT/patch-61

modified formatting

Author: PRMerger20

articles/virtual-machines/windows/sql/virtual-machines-windows-sql-performance.md

@@ -34,8 +34,8 @@ The following is a quick check list for optimal performance of SQL Server on Azu
 
 | Area | Optimizations |
 | --- | --- |
-| [VM size](#vm-size-guidance) | - Use VM sizes with 4 or more vCPU like [E4S_v3](../sizes-general.md) or higher, or [DS12_v2](../sizes-memory.md#dsv2-series-11-15) or higher.<br/><br/> - [Es, Eas, Ds and Das Series](../sizes-general.md) offers the optimum memory to vCPU ratio required for OLTP workload performance. <br/><br/> - [M Series](../sizes-general.md) offers the highest memory to vCPU ratio required for mission critical performance and is ideal for data warehouse workloads. <br/><br/> - Collect the target workload's [IOPS](../premium-storage-performance.md#iops), [throughput,  and [latency](../premium-storage-performance.md#latency) requirements at peak times by following the [application performance requirements checklist](../premium-storage-performance.md#application-performance-requirements-checklist) and then select the [VM Size](../sizes-general.md) that can scale to your workload's performance requirements.|
-| [Storage](#storage-guidance) | - Use [premium SSDs](https://techcommunity.microsoft.com/t5/SQL-Server/Optimize-OLTP-Performance-with-SQL-Server-on-Azure-VM/ba-p/916794) for the best price/performance advantages. Configure [ReadOnly cache](../premium-storage-performance.md#disk-caching) for data files and no cache for the log file. <br/><br/> - Use [Ultra Disks](../disks-types.md#ultra-disk) if less than 1 ms storage latencies are required by the workload. <br/><br/> - Collect the storage latency requirements for SQL Server data, log, and Temp DB files by [monitoring the application](../premium-storage-performance.md#application-performance-requirements-checklist) before choosing the disk type. If <1ms storage latencies are required, then use Ultra Disks, otherwise use premium SSD. If low latencies are only required for the log file and not for data files, then [provision the Ultra Disk](../disks-enable-ultra-ssd.md) at required IOPS and throughput levels only for the log File. <br/><br/> -  [Premium file shares](/virtual-machines-windows-portal-sql-create-failover-cluster-premium-file-share.md) are recommended as shared storage for a SQL Server failover cluster Instance. Premium file shares do not support caching, and offer limited performance compared to premium SSD disks. Choose premium SSD-managed disks over premium file shares for standalone SQL instances; but leverage premium file shares for failover cluster instance shared storage for ease of maintenance and flexible scalability. <br/><br/> -  Standard storage is only recommended for development and test purposes or for backup files and should not be used for production workloads. <br/><br/> - Keep the [storage account](../../../storage/common/storage-create-storage-account.md) and SQL Server VM in the same region.<br/><br/> - Disable Azure [geo-redundant storage](../../../storage/common/storage-redundancy.md) (geo-replication) on the storage account.  |
+| [VM size](#vm-size-guidance) | - Use VM sizes with 4 or more vCPU like [E4S_v3](../sizes-general.md) or higher, or [DS12_v2](../sizes-memory.md#dsv2-series-11-15) or higher.<br/><br/> - [Es, Eas, Ds and Das Series](../sizes-general.md) offers the optimum memory to vCPU ratio required for OLTP workload performance. <br/><br/> - [M Series](../sizes-general.md) offers the highest memory to vCPU ratio required for mission critical performance and is ideal for data warehouse workloads. <br/><br/> - Collect the target workload's [IOPS](../premium-storage-performance.md#iops), [throughput](../premium-storage-performance.md#throughput)  and [latency](../premium-storage-performance.md#latency) requirements at peak times by following the [application performance requirements checklist](../premium-storage-performance.md#application-performance-requirements-checklist) and then select the [VM Size](../sizes-general.md) that can scale to your workload's performance requirements.|
+| [Storage](#storage-guidance) | - For detailed testing of SQL Server performance on Azure VMs with TPC-E and TPC_C benchmarks, refer to the blog [Optimize OLTP performance](https://techcommunity.microsoft.com/t5/SQL-Server/Optimize-OLTP-Performance-with-SQL-Server-on-Azure-VM/ba-p/916794). <br/><br/> - Use [premium SSDs](https://techcommunity.microsoft.com/t5/SQL-Server/Optimize-OLTP-Performance-with-SQL-Server-on-Azure-VM/ba-p/916794) for the best price/performance advantages. Configure [ReadOnly cache](../premium-storage-performance.md#disk-caching) for data files and no cache for the log file. <br/><br/> - Use [Ultra Disks](../disks-types.md#ultra-disk) if less than 1 ms storage latencies are required by the workload. <br/><br/> - Collect the storage latency requirements for SQL Server data, log, and Temp DB files by [monitoring the application](../premium-storage-performance.md#application-performance-requirements-checklist) before choosing the disk type. If <1ms storage latencies are required, then use Ultra Disks, otherwise use premium SSD. If low latencies are only required for the log file and not for data files, then [provision the Ultra Disk](../disks-enable-ultra-ssd.md) at required IOPS and throughput levels only for the log File. <br/><br/> -  [Premium file shares](/virtual-machines-windows-portal-sql-create-failover-cluster-premium-file-share.md) are recommended as shared storage for a SQL Server failover cluster Instance. Premium file shares do not support caching, and offer limited performance compared to premium SSD disks. Choose premium SSD-managed disks over premium file shares for standalone SQL instances; but leverage premium file shares for failover cluster instance shared storage for ease of maintenance and flexible scalability. <br/><br/> -  Standard storage is only recommended for development and test purposes or for backup files and should not be used for production workloads. <br/><br/> - Keep the [storage account](../../../storage/common/storage-create-storage-account.md) and SQL Server VM in the same region.<br/><br/> - Disable Azure [geo-redundant storage](../../../storage/common/storage-redundancy.md) (geo-replication) on the storage account.  |
 | [Disks](#disks-guidance) | - Use a minimum of 2 [premium SSD disks](../disks-types.md#premium-ssd) (1 for log file and 1 for data files). <br/><br/> - For workloads requiring <1 ms IO latencies, enable write accelerator for M series and consider using Ultra SSD disks for Es and DS series. <br/><br/> - Enable [read only caching](../premium-storage-performance.md#disk-caching) on the disk(s) hosting the data files.<br/><br/> - Add additional 20% premium IOPS/throughput capacity than your workload requires when [configuring storage for SQL Server data, log, and TempDB files](virtual-machines-windows-sql-server-storage-configuration.md) <br/><br/> - Avoid using operating system or temporary disks for database storage or logging.<br/><br/> - Do not enable caching on disk(s) hosting the log file.  **Important**: Stop the SQL Server service when changing the cache settings for an Azure VM disk.<br/><br/> - Stripe multiple Azure data disks to get increased storage throughput.<br/><br/> - Format with documented allocation sizes. <br/><br/> - Place TempDB on the local SSD `D:\` drive for mission critical SQL Server workloads (after choosing correct VM size). If you create the VM from Azure portal or Azure quickstart templates and [place Temp DB on the Local Disk](https://techcommunity.microsoft.com/t5/SQL-Server/Announcing-Performance-Optimized-Storage-Configuration-for-SQL/ba-p/891583) then you do not need any further action; for all other cases follow the steps in the blog for  [Using SSDs to store TempDB](https://cloudblogs.microsoft.com/sqlserver/2014/09/25/using-ssds-in-azure-vms-to-store-sql-server-tempdb-and-buffer-pool-extensions/) to prevent failures after restarts. If the capacity of the local drive is not enough for your Temp DB size, then place Temp DB on a storage pool [stripped](../premium-storage-performance.md) on premium SSD disks with [read-only caching](../premium-storage-performance.md#disk-caching). |
 | [I/O](#io-guidance) |- Enable database page compression.<br/><br/> - Enable instant file initialization for data files.<br/><br/> - Limit autogrowth of the database.<br/><br/> - Disable autoshrink of the database.<br/><br/> - Move all databases to data disks, including system databases.<br/><br/> - Move SQL Server error log and trace file directories to data disks.<br/><br/> - Configure default backup and database file locations.<br/><br/> - [Enable locked pages in memory](/sql/database-engine/configure-windows/enable-the-lock-pages-in-memory-option-windows?view=sql-server-2017).<br/><br/> - Apply SQL Server performance fixes. |
 | [Feature-specific](#feature-specific-guidance) | - Back up directly to blob storage.<br/><br/>- Use [file snapshot backups](/sql/relational-databases/backup-restore/file-snapshot-backups-for-database-files-in-azure) for databases larger than 12 TB. <br/><br/>- Use multiple Temp DB files, 1 file per core, up to 8 files.<br/><br/>- Set max server memory at 90% or up to 50 GB left for the Operating System. <br/><br/>- Enable soft NUMA. |
@@ -44,7 +44,7 @@ For more information on *how* and *why* to make these optimizations, please revi
 
 ## VM size guidance
 
-Start by collecting the cpu, memory, and storage throughput requirements of the workload at peak times. \LogicalDisk\Disk Reads/Sec and \LogicalDisk\Disk Writes/Sec performance counters can be used to collect read and write IOPS requirements and \LogicalDisk\Disk Bytes/Sec counter can be used to collect [storage throughput requirements](../premium-storage-performance.md#disk-caching) for Data, Log, and Temp DB files. After IOPS and throughput requirements at peak are defined then evaluate VM sizes offers that capacity. For example if your workload requires 20 K read IOPS and 10K write IOPS at peak, you can either choose E16s_v3 (with up to 32 K cached and 25600 uncached IOPS) or M16_s (with up to 20 K cached and 10K uncached IOPS) with 2 P30 disks. MAke sure to understand both throughput and IOPS requirements of the workload as VMs has different scale limits for IOPS and throughput.<br/><br/>[DSv_3 and Es_v3-series](../sizes-general.md#dsv2-series) are hosted on general purpose hardware with Intel Haswell or Broadwell processors. [M-series](../sizes-memory.md#m-series) offers the highest vCPU count and memory for the largest SQL Server workloads and hosted on memory optimized hardware with Skylake processor family. These VM series support premium storage, which is recommended for the best performance with host level read cache. Both Es_v3 and M series are also available in [constrained core sizes](../../windows/constrained-vcpu.md), which saves money for workloads with lower compute  and high storage capacity demands. 
+Start by collecting the cpu, memory, and storage throughput requirements of the workload at peak times. \LogicalDisk\Disk Reads/Sec and \LogicalDisk\Disk Writes/Sec performance counters can be used to collect read and write IOPS requirements and \LogicalDisk\Disk Bytes/Sec counter can be used to collect [storage throughput requirements](../premium-storage-performance.md#disk-caching) for Data, Log, and Temp DB files. After IOPS and throughput requirements at peak are defined then evaluate VM sizes offers that capacity. For example if your workload requires 20 K read IOPS and 10K write IOPS at peak, you can either choose E16s_v3 (with up to 32 K cached and 25600 uncached IOPS) or M16_s (with up to 20 K cached and 10K uncached IOPS) with 2 P30 disks. Make sure to understand both throughput and IOPS requirements of the workload as VMs has different scale limits for IOPS and throughput.<br/><br/>[DSv_3 and Es_v3-series](../sizes-general.md#dsv2-series) are hosted on general purpose hardware with Intel Haswell or Broadwell processors. [M-series](../sizes-memory.md#m-series) offers the highest vCPU count and memory for the largest SQL Server workloads and hosted on memory optimized hardware with Skylake processor family. These VM series support premium storage, which is recommended for the best performance with host level read cache. Both Es_v3 and M series are also available in [constrained core sizes](../../windows/constrained-vcpu.md), which saves money for workloads with lower compute  and high storage capacity demands. 
 
 ## Storage guidance