Skip to main content

SQL Server on Azure VM — Configuration Best Practices

When you deploy SQL Server on Azure VMs, you are responsible for configuring the operating system, storage, SQL Server settings, and performance tuning. This is where your Oracle DBA skills translate directly — but Azure has specific best practices that differ from on-premises.

VM Size Selection

VM SeriesBest ForKey FeaturevCPUsMemory
Ebdsv5OLTP workloadsBest price/perf, Premium SSD + Ultra2-10416-672 GB
Edsv5General purposeBalanced compute/memory2-10416-672 GB
M-seriesVery large databasesUp to 4 TB RAM8-416218 GB-12 TB
Lsv3Data warehousingHigh local NVMe storage8-8064-640 GB
🎯 Exam Focus

DP-300 key rule: Always choose memory-optimized VMs (E-series or M-series) for SQL Server. Compute-optimized (F-series) or general-purpose (D-series) are NOT recommended for production SQL.

🏢 Real-World DBA Note

Oracle DBA parallel: This is like choosing your Exadata configuration — but instead of fixed hardware, you pick a VM size. The key difference: you can resize Azure VMs (with a brief restart), so start smaller and scale up based on workload.

Storage Architecture — The Most Critical Decision

Storage configuration is the #1 performance factor for SQL Server on Azure VMs. Getting this wrong causes 80% of performance issues.

Disk Types

Disk TypeMax IOPSMax ThroughputLatencyBest For
Ultra Disk160,0004,000 MB/s< 1msMission-critical OLTP
Premium SSD v280,0001,200 MB/s< 1msHigh-performance, flexible
Premium SSD20,000900 MB/s~1-2msMost production workloads
Standard SSD6,000750 MB/s~5msDev/test only
Standard HDD2,000500 MB/s~10msNever for SQL Server

The Golden Rules of SQL VM Storage

SQL VM Storage Best Practices
📁
Separate Data + Log
NEVER put data and log files on the same disk. Use separate Premium SSD or Ultra Disk for each.
tempdb on Local SSD
Put tempdb on the D:\ drive (temporary local SSD). Free, fast, but non-persistent across VM deallocations.
🚫
Never Use C: or OS Disk
OS disk has limited IOPS and caching. Never place SQL data/log/tempdb on C:\
DrivePurposeDisk TypeCachingSize Guidance
C:\OS onlyPremium SSDRead-only128 GB
D:\tempdbLocal SSD (ephemeral)N/AVM-provided
F:\Data files (.mdf, .ndf)Premium SSD or UltraRead-onlyBased on DB size
G:\Log files (.ldf)Premium SSD or UltraNoneBased on log throughput
H:\BackupsStandard SSDNone2-3x DB size
⚠️ Watch Out

Critical: Log file disks must have caching set to None. Read-only or read-write caching on transaction log disks can cause data corruption during a crash because cached writes may not be flushed. This is one of the most common Azure SQL VM misconfigurations.

🏢 Real-World DBA Note

Oracle DBA parallel: This is like your ASM disk group layout — you wouldn't put DATA and FRA on the same disk group. Same principle: separate data, log, and temp I/O paths. The D:\ drive for tempdb is like using local flash for temp tablespace.

Storage Caching Rules

File TypeCaching SettingWhy
Data files (.mdf/.ndf)Read-onlySpeeds up read operations, data pages cached in host memory
Log files (.ldf)NoneWrite-ahead logging requires guaranteed sequential writes — caching risks corruption
tempdbN/A (local SSD)D:\ drive has no caching option — it's direct local storage
BackupsNoneSequential write workload, caching adds no benefit

Disk Striping for IOPS

When a single Premium SSD doesn't provide enough IOPS, use Storage Spaces to stripe multiple disks:

ConfigIOPSThroughputUse Case
1x P30 (1 TB)5,000200 MB/sSmall databases
4x P30 striped20,000800 MB/sMedium OLTP
8x P30 striped40,0001,600 MB/sLarge OLTP
Ultra DiskUp to 160,0004,000 MB/sMission-critical (no striping needed)
🎯 Exam Focus

Storage Spaces stripe size: Use 64 KB interleave/stripe size for SQL Server data files (matches SQL Server extent size). This is a commonly tested detail on DP-300.

SQL Server Configuration Settings

tempdb Configuration

SettingRecommendationWhy
Number of files1 per vCPU (up to 8)Reduces allocation contention (PFS/GAM/SGAM)
File locationD:\ (local SSD)Fastest I/O, no persistence needed
Initial sizeEqual across all filesAvoids proportional-fill skew
Auto-growthEqual increment (64 MB or 128 MB)Keeps files balanced
Trace Flag 1118Not needed in SQL 2016+Mixed extents disabled by default
🏢 Real-World DBA Note

Oracle DBA parallel: tempdb files = Oracle temp tablespace datafiles. The "1 per CPU up to 8" rule solves the same contention problem as Oracle's locally managed temp tablespace with multiple temp files. The PFS/GAM contention is similar to Oracle's free space management bitmap contention.

MAXDOP (Max Degree of Parallelism)

ScenarioRecommended MAXDOP
OLTP (high concurrency)1 (or 2-4)
Data warehouse / reporting0 (unlimited) or 8
Mixed workload4-8 (never exceed logical CPU count)
General starting pointMin(8, logical CPUs)

Cost Threshold for Parallelism: Increase from the default of 5 to 50 for OLTP workloads. This prevents small queries from going parallel unnecessarily, reducing CXPACKET waits.

Memory Configuration

SettingRecommendationWhy
Max Server MemoryTotal RAM - 4 GB (for OS)Leave headroom for OS and other processes
Min Server Memory0 or fixed based on workloadUsually leave at 0
Lock Pages in MemoryEnable for productionPrevents Windows from paging SQL buffer pool to disk
Instant File InitializationEnable via SQL service accountSkips zeroing new data files — massive speed improvement
🎯 Exam Focus

Instant File Initialization (IFI) only works for data files, NOT log files. Log files are always zero-initialized for recovery safety. Grant the SQL Server service account the SE_MANAGE_VOLUME_NAME privilege (Perform Volume Maintenance Tasks in Local Security Policy).

Important Trace Flags

FlagPurposeStill Needed?
1118Disable mixed extent allocations❌ Default in SQL 2016+
3226Suppress successful backup messages in error log✅ Recommended
1117Auto-grow all files in filegroup equally❌ Default in SQL 2016+
2371Lower threshold for auto-update statistics❌ Default in SQL 2016+
460Show actual truncation length in truncation warnings✅ Helpful for debugging

Database Settings

SettingRecommendationWhy
Compatibility LevelLatest (160 for SQL 2022)Enables IQP, CE improvements
Recovery ModelFULL (for production)Required for AG, point-in-time restore
Auto-Create StatisticsONQuery optimizer needs statistics
Auto-Update StatisticsONKeep statistics fresh
Auto-Update Stats AsyncON (for OLTP)Prevents query compilation blocking
Page VerifyCHECKSUMDetects I/O corruption
Query StoreONFlight recorder for query perf

Networking Best Practices

SettingRecommendation
Accelerated NetworkingEnable on all SQL VMs (reduces latency 2-5x)
Proximity Placement GroupsPlace AG replicas in same placement group
Network bandwidthChoose VM size with sufficient bandwidth for AG sync

Maintenance Tasks

TaskFrequencyMethod
Index maintenanceWeeklyOla Hallengren scripts or custom
Statistics updateDaily or after large loadssp_updatestats or per-table UPDATE STATISTICS
Integrity checkWeeklyDBCC CHECKDB (schedule during low activity)
Backup verificationWeeklyRESTORE VERIFYONLY
Error log reviewDailyCheck for I/O errors, login failures
🏢 Real-World DBA Note

Oracle DBA parallel: Index maintenance = ALTER INDEX REBUILD/COALESCE. Statistics update = DBMS_STATS.GATHER_TABLE_STATS. Integrity check = DBMS_REPAIR + ANALYZE TABLE VALIDATE STRUCTURE. Same disciplines, different syntax.

SQL VM Resource Provider

When you register your SQL VM with the SQL IaaS Agent Extension, you get:

FeatureWhat It Does
Automated BackupConfigurable backups to Azure Storage (schedule, retention, encryption)
Automated PatchingAuto-apply Windows + SQL patches in a maintenance window
Azure Key Vault IntegrationTDE with customer-managed keys from Key Vault
Disk UtilizationPortal shows storage IOPS/throughput metrics
Flexible LicensingSwitch between PAYG and BYOL (Azure Hybrid Benefit)
Storage ConfigurationExtend drives and configure best practices from portal
⚠️ Watch Out

SQL IaaS Agent has 3 modes: Lightweight, Full, and NoAgent. Always use Full mode for production — it provides all features including automated backup and patching. Lightweight mode has limited features and is meant for minimal overhead scenarios.

Checklist: Production SQL VM Configuration

CategoryItem
VMMemory-optimized series (E or M)
VMAccelerated Networking enabled
StorageData files on separate Premium SSD/Ultra (caching: Read-only)
StorageLog files on separate Premium SSD/Ultra (caching: None)
Storagetempdb on D:\ (local SSD)
Storage64 KB stripe size for Storage Spaces
SQLMax Server Memory set (Total - 4 GB)
SQLMAXDOP configured per workload type
SQLCost Threshold for Parallelism = 50
SQLLock Pages in Memory enabled
SQLInstant File Initialization enabled
SQLtempdb: 1 file per vCPU (up to 8)
SQLQuery Store enabled
SQLRecovery Model = FULL
SQLPage Verify = CHECKSUM
MaintenanceOla Hallengren scripts installed
RegistrationSQL IaaS Agent Extension (Full mode)

Flashcards

What caching should be set on SQL Server log file disks?
Click to reveal answer
NONE. Read-only or read-write caching on log files can cause data corruption during crashes because cached writes may not be flushed to disk.
1 / 10

Quiz

Q1/5
0 correct
You're configuring storage for a SQL Server VM in Azure. Where should you place transaction log files?