Chandler Gray

How to Deploy a SQL Server Availability Group for High Availability

Sat, 25 Jul 2026 00:00:00 GMT

I've built dozens of SQL Server availability groups at work but had never built one for my homelab. The main reason is that doing it right meant setting up an Active Directory domain, which I'd never done before. That's done now, so I was ready to get started.

This post only covers standard AGs. I'm not covering Contained AGs here, but I plan to write one for that separately.

Some details about my homelab first:

I run a single Proxmox node, managed largely through Terraform.
Storage is just a standard ZFS model.
I reserved the IP addresses for the servers, LB, and so on through my Unifi gateway.
All three servers in the lab (two SQL Servers and one AD) run unlicensed Windows Server 2025.
My two SQL Servers are both running SQL Server 2025 Enterprise Developer Edition.
Since everything is on one host, HA won't help me if the storage or the host dies. It's a homelab and nothing critical will be stored on it, so I'm accepting that risk.

Prerequisites

A Windows Server Active Directory.
Two fresh SQL Server 2025 instances.
Ability to reserve at least five IP addresses on your network.
Some way to configure DNS, I use AdGuard.

Getting Started

There are a few different ways to configure your AG, but what I'm building is two SQL Server 2025 nodes in a synchronous-commit availability group with automatic failover. These will have a listener, and a quorum held by a file-share witness on the domain controller.

My VLAN is 192.168.25.0/26.

If you haven't touched networking outside of what SQL Server makes you deal with, here's what that means. A VLAN is just a logically isolated network segment, in my case one carved out on my router for these five machines. The /26 is the subnet mask written in CIDR notation, and it tells you how many addresses that segment actually has. A /26 gives you 64 addresses (192.168.25.0 through 192.168.25.63), which is plenty for a handful of lab servers. You'll see this same /26 show up again later when the AG listener gets created, since SQL Server wants that mask spelled out for the IP it binds to.

Role	Hostname	IP
DC · DNS · Witness	`DC-01`	192.168.25.12
AG Primary	`SQL25-WIN25-01`	192.168.25.13
AG Secondary	`SQL25-WIN25-02`	192.168.25.14
Cluster name object (CNO)	`SQL25-CLU-01`	192.168.25.15
AG Listener	`SQL25-AG-01L`	192.168.25.16

Two of these rows aren't physical machines. The CNO is a computer object the cluster creates in AD to represent the cluster itself, and the listener is another computer object that represents the AG's single connection point. Both get their own IP and DNS name, but neither one is a server you log into. More on both below.

The domain is lab.local (NetBIOS LAB). If you're not used to AD terminology, the domain name (lab.local) is what you'll use in full commands and connection strings, while the NetBIOS name (LAB) is the short legacy form Windows still uses in places like LAB\svc-sql-engine, meaning the svc-sql-engine account inside the LAB domain.

Every node gets its IP from a DHCP reservation on the Unifi gateway rather than an in-guest static. A reservation just means the router always hands that machine the same address based on its network card's MAC address, so it behaves like a static IP without you having to configure it inside Windows. I find reservations easier to keep track of in one place, but a normal static IP set inside the guest works exactly the same for everything in this post.

Phase 1 - Deploy and Baseline

First get a SQL baseline captured (run on both instances):

SELECT @@VERSION, SERVERPROPERTY('Edition'), SERVERPROPERTY('EditionID'), SERVERPROPERTY('Collation');

Next, check that both instances are on the same version of SQL Server. Enterprise Edition is ideal. Standard Edition only supports basic availability groups, which are limited to two replicas and one database, but that's enough for the single test database in this lab.

Phase 2 - Active Directory and Domain Join

This phase is where I spent most of my time, mostly because I'd never stood up a fresh forest before. I've laid it out below in the order that worked, with some of my notes on stuff that helped me get unstuck.

Stand up the domain controller

First, rename the host and reboot, since a DC's name can't easily change after promotion.

Rename-Computer -NewName DC-01 -Force
Restart-Computer -Force

Next, point the DC's DNS at itself. This is a real "wait, why" moment the first time you hit it: once a machine becomes a domain controller, it also becomes a DNS server, and AD leans on DNS constantly to find things like other domain controllers and services. So the DC needs to ask itself for answers rather than pointing out to your router or ISP like a normal client would. I keep DHCP enabled on the server (the reservation on the Unifi gateway pins the IP anyway), so the only thing that needs to change here is where it resolves names.

$if = (Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object -First 1).Name
Set-DnsClientServerAddress -InterfaceAlias $if -ServerAddresses 127.0.0.1

Install the AD DS role, then create the forest. Install-ADDSForest is what actually promotes the box to a domain controller, installs DNS, and creates the domain everything else will join. Setting -DomainMode and -ForestMode to Win2025 is fine here since every machine in the lab is already on Server 2025.

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

Install-ADDSForest `
    -DomainName lab.local -DomainNetbiosName LAB `
    -DomainMode Win2025 -ForestMode Win2025 -InstallDns `
    -SafeModeAdministratorPassword (ConvertTo-SecureString 'YourStrongP@ssword!' -AsPlainText -Force) `
    -Force

The machine reboots on its own after this. Log back in as LAB\Administrator and confirm the forest is actually healthy before moving on.

Get-ADForest | Format-List Name,ForestMode,DomainNamingMaster
Get-Service ADWS,NTDS,DNS,Netlogon | Format-Table Name,Status
Resolve-DnsName lab.local
dcdiag /test:Advertising /test:Services /test:MachineAccount | Select-String 'passed|failed'

DNS forwarding, reverse zone, and time sync

The DC now answers authoritatively for lab.local, meaning it's the one source of truth for anything under that domain name, but it still needs somewhere to send everything else, like a request to resolve google.com. That's what a forwarder is: a second DNS server the DC hands off to whenever it gets asked about a name it doesn't own. I point mine at AdGuard, which is doing my ad blocking and upstream resolution for the rest of the network anyway.

The reverse zone is DNS running backwards. Normal DNS answers "what's the IP for this name," and a reverse zone answers "what's the name for this IP." I set one up for the lab subnet alongside the forward zone.

Last, since this DC is going to be the time source for the rest of the domain, I pointed it at a real NTP pool instead of letting it drift on its own. This matters more than it sounds like it should: Kerberos, the authentication protocol AD and SQL Server both rely on here, rejects requests if the clocks on either side have drifted more than about five minutes apart. While researching, I found that clock drift is a surprisingly common cause of logins that fail for no obvious reason.

Set-DnsServerForwarder -IPAddress 192.168.25.53
if (-not (Get-DnsServerZone -Name '0.25.168.192.in-addr.arpa' -EA SilentlyContinue)) {
    Add-DnsServerPrimaryZone -NetworkId '192.168.25.0/26' -ReplicationScope Forest
}
w32tm /config /manualpeerlist:'pool.ntp.org' /syncfromflags:manual /reliable:yes /update
Restart-Service w32time
Resolve-DnsName google.com | Select-Object -First 1

With that done, I went into AdGuard (192.168.25.53) under Settings > DNS > Upstream servers and added a conditional forward, which is a rule that says "if the request is for this specific domain, send it here instead of the normal upstream," so AdGuard sends anything for my domain back to the DC:

[/lab.local/]192.168.25.12

Organizational units and service accounts

I keep it simple with two OUs, one for the SQL Servers and one for service accounts.

$base = (Get-ADDomain).DistinguishedName
foreach ($ou in 'SQL Servers','Service Accounts') {
    if (-not (Get-ADOrganizationalUnit -Filter "Name -eq '$ou'" -EA SilentlyContinue)) {
        New-ADOrganizationalUnit -Name $ou -Path $base
    }
}

This is the part that actually caused me the most grief. I originally created my service accounts the normal way and then went back to set their Kerberos encryption types afterward. Every time I touched the account again, whether that was a password reset or an attribute change, it blanked the encryption types back out for some reason.

The fix is to set the encryption types in the same New-ADUser call that creates the account, so it's born correct instead of patched afterward:

$svcOu = "OU=Service Accounts,$base"
$sec   = ConvertTo-SecureString 'YourStrongP@ssword!' -AsPlainText -Force
foreach ($u in 'svc-sql-engine','svc-sql-agent','joinadmin') {
    if (-not (Get-ADUser -Filter "SamAccountName -eq '$u'" -EA SilentlyContinue)) {
        New-ADUser -Name $u -SamAccountName $u -Path $svcOu `
            -UserPrincipalName "$u@lab.local" `
            -AccountPassword $sec -Enabled $true -PasswordNeverExpires $true `
            -KerberosEncryptionType AES128,AES256
    }
}
Add-ADGroupMember 'Domain Admins' 'joinadmin' -EA SilentlyContinue

joinadmin is only there to join the two nodes to the domain. svc-sql-engine and svc-sql-agent are what the SQL Server services themselves will run under. You can confirm the encryption types took by checking msDS-SupportedEncryptionTypes is 24 (AES128 + AES256) on each account.

Join the SQL nodes to the domain

On each node, rename it and reboot first, since the machine name needs to be final before joining.

$NodeName = 'SQL25-WIN25-01'   # or 'SQL25-WIN25-02' on the second node
Rename-Computer -NewName $NodeName -Force
Restart-Computer -Force

After the reboot, point the node's DNS at the DC so the domain actually resolves, then join.

$if = (Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object -First 1).Name
Set-DnsClientServerAddress -InterfaceAlias $if -ServerAddresses 192.168.25.12
Resolve-DnsName lab.local -Server 192.168.25.12

$cred = New-Object System.Management.Automation.PSCredential(
    'joinadmin@lab.local',
    (ConvertTo-SecureString 'YourStrongP@ssword!' -AsPlainText -Force))
Add-Computer -DomainName lab.local -Credential $cred `
    -OUPath 'OU=SQL Servers,DC=lab,DC=local'
Restart-Computer -Force

If you're cloning VM templates like I am, make sure the template was properly sysprepped and generalized before you clone it. My first attempt used a template that hadn't been generalized, so every clone shared the same machine SID, which collided with the domain SID and made a normal domain join fail outright. The workaround at the time was an offline join with djoin, but once I fixed the template, Add-Computer just worked normally. I'm leaving the djoin steps out of this post since they shouldn't be necessary if your template is set up correctly, but it's the error to look for if a live join ever refuses to cooperate.

After the reboot, verify the join actually took.

Get-CimInstance Win32_ComputerSystem | Format-List Name,Domain,PartOfDomain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:lab.local

One more wrinkle: joined nodes don't always self-register their own DNS A record, even on a healthy secure dynamic update zone. An A record is just the DNS entry that maps a hostname to an IP address. Domain-joined machines normally create their own automatically, but that self-registration is a background process that occasionally doesn't land. Since these nodes have fixed IPs anyway, I just created static A records on the DC instead of chasing why dynamic registration didn't persist.

Add-DnsServerResourceRecordA -ZoneName lab.local -Name SQL25-WIN25-01 -IPv4Address 192.168.25.13
Add-DnsServerResourceRecordA -ZoneName lab.local -Name SQL25-WIN25-02 -IPv4Address 192.168.25.14

Repeat everything in this section on the second node before moving on.

Phase 3 - SQL Server Service Accounts

With both nodes joined, the SQL Server service on each one needs to run under the domain account rather than the local service account it started with. You can do this by hand with WMI, but it's fiddly to get the Windows-side permissions right, so I just used SQL Server Configuration Manager instead, which handles all of that for you.

On each node:

Open SQL Server Configuration Manager.
Click SQL Server Services in the left pane.
Right-click SQL Server (MSSQLSERVER) and choose Properties.
On the Log On tab, select This account, then enter LAB\svc-sql-engine and its password.
Click OK. Configuration Manager will offer to restart the service. Let it, since the change doesn't fully take effect until it does.

SQL Server Agent doesn't need the domain identity for anything in this post. It only matters if you want scheduled jobs to run as that account, and if you do, repeat the same steps for SQL Server Agent (MSSQLSERVER) using LAB\svc-sql-agent.

If the engine service refuses to start with a 7038 "SID inconsistent with trust" error right after a fresh domain join, a reboot usually clears it, since the LSA needs to re-read the right that was just granted. If it persists, the node's secure channel is probably broken and worth repairing with Test-ComputerSecureChannel -Repair. If you ever suspect a stale Kerberos ticket is involved, klist purge from an elevated prompt clears the cache and forces a fresh one on next login.

Last for this phase, align the instance settings, since editions and collation need to match across both nodes before you can build the AG.

sqlcmd -S localhost -E -b -Q "EXEC sys.sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sys.sp_configure 'max server memory (MB)', 6000; RECONFIGURE; EXEC sys.sp_configure 'max degree of parallelism', 4; RECONFIGURE;"
sqlcmd -S localhost -E -Q "SELECT SERVERPROPERTY('Edition') Edition, SERVERPROPERTY('ProductLevel') Patch, SERVERPROPERTY('Collation') Collation;"

Repeat this whole phase on the second node.

Phase 4 - Building the Cluster

Availability groups sit on top of a Windows Server Failover Cluster, so that comes next. A quick note on where each of these commands actually runs, since it isn't always obvious: installing the feature happens on each node separately, but forming the cluster itself is a single command run once from either node, since it acts on the whole cluster rather than one machine at a time.

On each node, install the failover clustering feature and reboot.

Install-WindowsFeature Failover-Clustering -IncludeManagementTools
Restart-Computer -Force

On the DC, create a file share to act as the witness. Quorum is the cluster's way of deciding who's allowed to be in charge when things go wrong, essentially a vote among the nodes plus this witness share, and it exists specifically to prevent "split-brain," where both nodes think they're the primary at the same time and start diverging. With only two nodes, a tie is always possible, so the witness acts as a tie-breaking third vote. It's just a plain SMB file share (a Windows network share, the same kind you'd use to drop a file on another PC). It doesn't hold any actual data, only a small file the cluster uses to check who currently holds the vote.

New-Item -Path C:\Shares\sqlclu01-fsw -ItemType Directory -Force | Out-Null
New-SmbShare -Name sqlclu01-fsw -Path C:\Shares\sqlclu01-fsw -FullAccess 'LAB\Domain Admins' -EA SilentlyContinue

From either node, validate and then create the cluster. Test-Cluster will throw storage and network warnings since there's no shared storage in this setup, which is expected, since availability groups don't use shared storage the way a traditional failover cluster instance would.

Test-Cluster -Node SQL25-WIN25-01,SQL25-WIN25-02
New-Cluster -Name SQL25-CLU-01 -Node SQL25-WIN25-01,SQL25-WIN25-02 `
    -StaticAddress 192.168.25.15 -NoStorage

The CNO confused me when I first read about needing to create it. When you create the cluster, Windows creates a computer object in AD for the cluster itself, separate from the two node objects, so the cluster has its own identity on the network with its own name (SQL25-CLU-01) and IP (.15). That identity is what actually authenticates to the witness share, not either node individually, which is why the permission below has to be granted to SQL25-CLU-01$ (the trailing $ is just how Windows denotes a computer account rather than a user account) and not to the node computer accounts. It needs full rights on the witness share, both at the share level and in NTFS, the Windows filesystem permission layer, or setting the quorum will fail.

Grant-SmbShareAccess -Name sqlclu01-fsw -AccountName 'LAB\SQL25-CLU-01$' -AccessRight Full -Force
$cno = 'LAB\SQL25-CLU-01$'
icacls C:\Shares\sqlclu01-fsw /grant ('{0}:(OI)(CI)F' -f $cno)

From either node again, set the quorum to node-and-file-share majority and confirm you're seeing three votes, one for each node plus the witness.

Set-ClusterQuorum -NodeAndFileShareMajority \\DC-01\sqlclu01-fsw
Get-ClusterNode | Format-Table Name,NodeWeight,State

One last thing to handle on the DC before moving on. The AG listener I'll add later is, like the CNO, its own computer object in AD with its own name and IP, and by default the CNO doesn't have permission to create one. If you skip this, adding the listener later fails with a fairly opaque "could not bring the Network Name online" error. Grant it now so that step works when you get there.

$ou = 'OU=SQL Servers,DC=lab,DC=local'
dsacls $ou /I:T /G ('{0}:CC;computer' -f 'LAB\SQL25-CLU-01$')

Phase 5 - Enabling Always On

On both nodes, enable the Always On feature, which ties the instance to the cluster and restarts the SQL service.

Import-Module SqlServer -EA SilentlyContinue
Enable-SqlAlwaysOn -ServerInstance localhost -Force

On a new installation, Microsoft's default network protocol configuration page shows TCP/IP disabled for Developer and Express editions, while Enterprise and Standard have it enabled. Named Pipes is listed as "disabled for network connections" for every edition, so a fresh Developer install doesn't accept connections from other machines until TCP/IP is turned on. Ports are just the numbered "doors" a service listens on. 1433 is SQL Server's normal client port, and 5022 is the port the AG endpoints in this post use to talk to each other. Clients, and the AG listener on 1433, need TCP/IP enabled. If you miss this, SSMS and the failover wizard fail with a Named Pipes error rather than anything that points at TCP being off, which is a confusing error to land on if you don't know Named Pipes was even involved. The New-NetFirewallRule lines after it open both ports through Windows Firewall, since the OS firewall drops the traffic unless a rule allows it.

$inst = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL').MSSQLSERVER
$tcp  = "HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\$inst\MSSQLServer\SuperSocketNetLib\Tcp"
Set-ItemProperty $tcp -Name Enabled -Value 1
Set-ItemProperty "$tcp\IPAll" -Name TcpPort -Value 1433
Set-ItemProperty "$tcp\IPAll" -Name TcpDynamicPorts -Value ''

New-NetFirewallRule -DisplayName 'SQL AG - engine 1433'  -Direction Inbound -Protocol TCP -LocalPort 1433 -Action Allow -EA SilentlyContinue | Out-Null
New-NetFirewallRule -DisplayName 'SQL AG - endpoint 5022' -Direction Inbound -Protocol TCP -LocalPort 5022 -Action Allow -EA SilentlyContinue | Out-Null

Restart-Service MSSQLSERVER -Force

On the primary node only, create a test database. It needs to be in full recovery mode with at least one full backup taken before an AG can add it. Microsoft's automatic seeding documentation is specific that these backups "are not used for automatic seeding, but they are required before including the database in an availability group."

New-Item C:\Backups -ItemType Directory -Force | Out-Null
sqlcmd -S localhost -E -C -Q "IF DB_ID('AgDemo') IS NULL CREATE DATABASE AgDemo; GO ALTER DATABASE AgDemo SET RECOVERY FULL; GO BACKUP DATABASE AgDemo TO DISK = N'C:\Backups\AgDemo_full.bak' WITH INIT; BACKUP LOG AgDemo TO DISK = N'C:\Backups\AgDemo_log.trn' WITH INIT;"

Phase 6 - Creating the Availability Group

Since both replicas run under the same domain account, LAB\svc-sql-engine, the AG endpoints can authenticate over Windows/Kerberos without needing certificates at all. Microsoft's transport security page says certificates are required when Windows Authentication isn't available, for example "when server instances aren't in trusted domains or when SQL Server is running as a local service."

On both nodes, create a SQL login for the service account (running the service as that account doesn't automatically create a login for it) and set up the endpoint.

sqlcmd -S localhost -E -C -Q "IF NOT EXISTS (SELECT 1 FROM sys.server_principals WHERE name = N'LAB\svc-sql-engine') CREATE LOGIN [LAB\svc-sql-engine] FROM WINDOWS; GO IF NOT EXISTS (SELECT 1 FROM sys.endpoints WHERE name='Hadr_endpoint') CREATE ENDPOINT Hadr_endpoint STATE=STARTED AS TCP (LISTENER_PORT=5022, LISTENER_IP=ALL) FOR DATABASE_MIRRORING (ROLE=ALL); GO GRANT CONNECT ON ENDPOINT::Hadr_endpoint TO [LAB\svc-sql-engine];"

On the primary, create the availability group with automatic seeding so the database streams to the secondary without a manual backup and restore.

CREATE AVAILABILITY GROUP [ag01]
  WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)
  FOR DATABASE [AgDemo]
  REPLICA ON
    N'SQL25-WIN25-01' WITH (
        ENDPOINT_URL = N'TCP://SQL25-WIN25-01.lab.local:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = AUTOMATIC,
        SEEDING_MODE = AUTOMATIC, BACKUP_PRIORITY = 50,
        SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)),
    N'SQL25-WIN25-02' WITH (
        ENDPOINT_URL = N'TCP://SQL25-WIN25-02.lab.local:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = AUTOMATIC,
        SEEDING_MODE = AUTOMATIC, BACKUP_PRIORITY = 50,
        SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL));

On the secondary, join the AG and grant it permission to create the database, which automatic seeding needs in order to create the database on the secondary.

ALTER AVAILABILITY GROUP [ag01] JOIN;
ALTER AVAILABILITY GROUP [ag01] GRANT CREATE ANY DATABASE;

Back on the primary, add the listener, the single stable name and IP clients will actually connect to, so they never need to know or care which node is currently primary. The subnet mask has to be spelled out here in its longhand dotted form rather than the /26 shorthand from earlier. They mean the same thing, but SQL Server's syntax wants it written out. You'll also want to make sure the listener's IP is excluded from your DHCP pool (the range of addresses your router hands out automatically) so nothing else gets assigned that address later and conflicts with it.

ALTER AVAILABILITY GROUP [ag01]
  ADD LISTENER N'SQL25-AG-01L' (
    WITH IP ((N'192.168.25.16', N'255.255.255.192')), PORT = 1433);

This is exactly the step the AD permission from Phase 4 was protecting against. Without granting the CNO rights to create computer objects in that OU, this fails with error 19471. If you hit it anyway, you can pre-stage the listener's computer object manually on the DC and grant the CNO's SID full control over it before retrying.

Last, confirm both replicas are healthy and connected.

SELECT ar.replica_server_name, hars.role_desc, hars.synchronization_health_desc, hars.connected_state_desc
FROM sys.dm_hadr_availability_replica_states hars
JOIN sys.availability_replicas ar ON hars.replica_id = ar.replica_id
ORDER BY ar.replica_server_name;

Both rows should come back HEALTHY and CONNECTED.

Phase 7 - Proving Failover Works

This is the part I was most looking forward to, since standing up an AG means nothing if you haven't actually watched it fail over. The listener is the whole point here. Clients should always connect through SQL25-AG-01L.lab.local,1433 and never talk to a node directly.

I started a simple heartbeat writer against the listener, inserting one row a second and printing failures, so any gap in timestamps shows exactly how long a test's downtime was.

$listener = 'SQL25-AG-01L.lab.local'
while ($true) {
    $t = Get-Date -Format 'HH:mm:ss.fff'
    $out = sqlcmd -S $listener -E -C -b -Q "INSERT AgDemo.dbo.Heartbeat DEFAULT VALUES;" 2>&1
    if ($LASTEXITCODE -eq 0) { Write-Host "$t  OK" -ForegroundColor Green }
    else                     { Write-Host "$t  FAIL: $out" -ForegroundColor Red }
    Start-Sleep -Milliseconds 1000
}

With that running in its own window, I ran through a few different tests:

Manual failover. From the current secondary, ALTER AVAILABILITY GROUP [ag01] FAILOVER; triggers a graceful role swap. Downtime was only a couple of seconds and there was zero data loss, which makes sense given synchronous commit.
Hard primary kill. From the Proxmox host, I hard-stopped the primary's VM with qm stop, simulating the whole box dying rather than a clean shutdown. Automatic failover kicked in and promoted the secondary.
Witness loss. Stopping the file share witness on the DC doesn't take down the AG, since a two-node cluster still holds quorum on the two node votes alone. It's just there to break a tie.
Split-brain check. Shutting down the secondary, then the primary, then starting only the former secondary back up left the cluster down with just one of three votes, exactly as it should. Node-and-file-share majority refused to auto-start with a minority of votes, which is the whole point of quorum. You can force it back online with Start-ClusterNode -FixQuorum if you're willing to accept the split-brain risk, but I only did this to see the protection actually hold.

After each test I confirmed the row count only ever went up, never down, which is what you'd expect from a synchronous-commit AG with no data loss on failover.

That's it, though there are a lot of steps. I think most shops have enough automation to set these up faster and more consistently than this. I haven't set up Ansible for my homelab yet, but I plan to before the Contained AG post, so I don't have to document every step by hand again. Feel free to leave questions or comments below.

Cannot connect to WMI provider in SQL Server Configuration Manager

Tue, 05 May 2026 00:00:00 GMT

I logged into a Windows server today to change the startup parameters and was met with this error:

"Cannot connect to WMI provider. You do not have permissions or the server is unreachable. Note that you can only manage SQL Server 2005 and later servers with SQL Server Configuration Manager Invalid class [0x80041010]"

Configuration Manager uses Windows Management Instrumentation (WMI) to get the status of the SQL Server services, and it couldn't connect. The first sentence of the error mentions permissions, but the code at the end is the useful part. Microsoft's <a href="https://learn.microsoft.com/en-us/troubleshoot/sql/tools/error-message-when-you-open-configuration-manager" target="_blank" rel="noopener noreferrer">article on this error</a> says both of its possible codes mean "the provider registration is missing rather than that access was denied." Invalid class specifically means the WMI namespace for SQL Server is there, but the classes Configuration Manager expects aren't registered in it. The same article says that registration is removed when an instance of SQL Server is uninstalled, including an instance of a different version on the same machine.

To fix it, recompile the provider with mofcomp.

I opened an elevated Command Prompt and changed to the SQL Server shared directory for my version. It was a SQL Server 2022 build, so I used:

cd "C:\Program Files (x86)\Microsoft SQL Server\160\Shared"

Before recompiling anything, I ran this to find the .mof file in the directory:

dir *.mof

The file name is different between versions of SQL Server. I'd seen sqlmgmproviderxpsp2up.mof in a different doc, and my folder had sqlmgmprovider.mof. Microsoft's article has a table of both. SQL Server 2022 (folder 160) and 2025 (folder 170) use sqlmgmprovider.mof, and 2005 through 2019 use sqlmgmproviderxpsp2up.mof. If you aren't sure which versions are installed, the article also gives a command that lists the .mof files across every version folder:

dir "%programfiles(x86)%\Microsoft SQL Server\*.mof" /s

If no .mof file shows up at all, there's nothing to recompile, and you're left with running a repair on the SQL Server installation instead.

Once I knew which file I had, this is what I ran:

mofcomp sqlmgmprovider.mof

At this point the problem was fixed for me. Microsoft's steps do include restarting the WMI service for the change to take effect, so if the error is still there, restart it with this in an elevated PowerShell session:

Get-Service winmgmt | Restart-Service -Force

Restarting the WMI service only takes a few seconds, and from what I found, it doesn't affect SQL Server, active connections, or running queries. What's at risk is anything polling through WMI at that moment. Some monitoring agents, PowerShell calls and performance counters all use WMI, so on a production server I'd do it during a low-activity or maintenance window.

How To Split a SQL Server Backup File

Thu, 02 Apr 2026 00:00:00 GMT

import Callout from "@/components/Callout.astro";

Someone came to me today asking for tips on migrating a large database backup from one server to another. The way I'd do it is to break the database backup into parts and upload them via an SFTP server or cloud storage, anywhere that both servers can access. There are three reasons why I think splitting backups into multiple files is better when you're dealing with multi-terabyte database backup transfers.

Parallelism - Many SFTP and cloud storage services allow multiple uploads at once. With one large file, unless your network connection is the bottleneck, you could be waiting ten times as long or more than you would with several files going at once.
Resumability - I've written in the past how network connections can be unreliable, so having your backup in chunks means if your VPN connection drops, you won't have to restart your upload from the beginning.
Size restrictions - Some corporate SFTPs have size limitations for single file uploads. Splitting gets around those limits if your backups exceed them.

I'll cover three ways to do it: SQL Server's native split, PowerShell, and 7-Zip.

SQL Server Native Split Backup

SQL Server can write a single backup across multiple files natively. Add multiple DISK targets to the BACKUP command:

BACKUP DATABASE AdventureWorks2025
TO DISK = 'F:\SQLBackups\AdventureWorks2025_1.bak',
   DISK = 'F:\SQLBackups\AdventureWorks2025_2.bak',
   DISK = 'F:\SQLBackups\AdventureWorks2025_3.bak'
WITH FORMAT, COMPRESSION;

SQL Server distributes the data across the files roughly evenly. All parts are required for restore. This also parallelizes disk I/O, which can make the backup itself faster.

That "all parts are required" line is worth taking seriously. Splitting into 18 files gives you 18 files that all have to arrive intact, and one corrupted or missing part leaves you without a usable backup. That holds for all three methods here.

Microsoft's documentation calls this a media set rather than a split. Each DISK target is a media family, and the media sets page says that when there's more than one family, "the backup set is distributed among them." For a restore from disk, "all the media families must be concurrently mounted," which is the documented way of saying you need every file at once. The number of devices is also fixed once the media set exists, so later backups to the same media set have to use the same number of files.

Before deleting anything on the source, check the file count and sizes on the destination. For the native split, RESTORE VERIFYONLY against the full set of DISK targets checks that the backup set is complete and readable.

To restore:

RESTORE DATABASE AdventureWorks2025
FROM DISK = 'F:\SQLBackups\AdventureWorks2025_1.bak',
     DISK = 'F:\SQLBackups\AdventureWorks2025_2.bak',
     DISK = 'F:\SQLBackups\AdventureWorks2025_3.bak'
WITH RECOVERY;

When to use this: You control the backup job and can re-run it. You want the split to happen at backup time, not as a separate step.

Limitation: You need to decide the number of files up front. If you want each part under, say, 120 GB for a 2 TB backup, you would need at least 18 files to get under that threshold.

Ola Hallengren

If you use Ola Hallengren's maintenance solution you can do this a couple of ways:

If you don't mind exactly how big each file is and just want a specific number of them, add @NumberOfFiles = n to the backup job, where n is the number of files you want to back up to.
If you care about the maximum size of each file, set @MaxFileSize = n in the backup job instead, where n is the maximum file size in MB.

PowerShell Byte-Level Split

Sometimes you don't have permission to change the backup job. If the backup already exists as a single file, you can split it after the fact with PowerShell.

<Callout type="warning"> Don't modify the only copy of the production server's backup. Copy it to a different workstation before splitting it. </Callout>

PowerShell Split

$file = 'F:\SQLBackups\AdventureWorks2025.bak'
$chunkSize = 16000KB ## Set file size here
$bufferSize = 400KB
$buffer = New-Object byte[] $bufferSize
$reader = [IO.File]::OpenRead($file)
$part = 1
$bytesLeft = $chunkSize

$writer = [IO.File]::OpenWrite("$file.part$part")
while (($read = $reader.Read($buffer, 0, [math]::Min($bufferSize, $bytesLeft))) -gt 0) {
    $writer.Write($buffer, 0, $read)
    $bytesLeft -= $read
    if ($bytesLeft -le 0) {
        $writer.Close()
        $part++
        $bytesLeft = $chunkSize
        $writer = [IO.File]::OpenWrite("$file.part$part")
    }
}
$writer.Close()
$reader.Close()

PowerShell Reassemble

On the destination, concatenate the parts back together:

$bufferSize = 400KB
$buffer = New-Object byte[] $bufferSize
$out = [IO.File]::OpenWrite('F:\SQLBackups\AdventureWorks2025_unchunked.bak')
Get-ChildItem 'F:\SQLBackups\AdventureWorks2025.bak.part*' | Sort-Object Name | ForEach-Object {
    $in = [IO.File]::OpenRead($_.FullName)
    while (($read = $in.Read($buffer, 0, $bufferSize)) -gt 0) {
        $out.Write($buffer, 0, $read)
    }
    $in.Close()
}
$out.Close()

<Callout type="info"> $bufferSize controls how many bytes are read from disk into memory per Read() call. It has no effect on chunk boundaries, which are set by $chunkSize. A larger buffer means fewer read and write calls. For a 1 TB file, the script's 400KB buffer works out to about 2.7 million reads, while a 4KB buffer would take about 268 million. In the split script, each read is also capped at what's left of the current chunk, so a buffer larger than $chunkSize doesn't help there. Keep it well below available RAM. </Callout>

When to use this: The backup already exists as one file and you don't want to install additional tools.

Limitation: It's more code to maintain than the other two options.

7-Zip Split Archive

7-Zip can split a file into volumes without compression using store mode:

7-Zip Split

7-Zip is on its official download page.

& "C:\Program Files\7-Zip\7z.exe" a -v16m -mx0 F:\SQLBackups\AdventureWorks2025.7z F:\SQLBackups\AdventureWorks2025.bak

-v16m sets each volume to 16 MB. -mx0 disables compression (store mode), so the file is split as-is with no CPU overhead. Output files are named AdventureWorks2025.7z.001, AdventureWorks2025.7z.002, etc.

7-Zip Reassemble

& "C:\Program Files\7-Zip\7z.exe" x F:\SQLBackups\AdventureWorks2025.7z.001 -oF:\SQLBackups\

Point the extraction at the .001 file. 7-Zip finds the rest of the parts on its own, so they all need to be in the same directory.

When to use this: You have an existing backup file, 7-Zip is available, and you want a simple split with a standard archive format the destination can unpack.

<Callout type="info"> If you do want compression, remove the -mx0 flag. For .bak files this is usually not worth the time and CPU cost on a multi-terabyte file. </Callout>

Which Method to Pick

Criteria	SQL Server Split	PowerShell	7-Zip
Requires re-running backup	Yes	No	No
Adds compression	WITH COMPRESSION	No	Optional (off by default with -mx0)
Extra tooling needed	None	None	7-Zip
Works on non-SQL files	No	Yes	Yes

For a multi-terabyte SQL Server backup going over a constrained SFTP link, 7-Zip with -mx0 is usually the best fit. The split is handled in a single command with no compression overhead. If you can't install 7-Zip on the source, PowerShell works with no dependencies. If you can re-run the backup, the native SQL Server split avoids post-processing entirely. Only the SQL Server split guarantees the parts are written in a way that SQL Server can read them directly, but all three methods produce files that can be reassembled into a valid backup. With the exception of the native split, there's no limitation to the file type, so you can use these methods to split and reassemble any large file, not just SQL Server backups.

One thing this post doesn't test is how the PowerShell and 7-Zip splits behave on a backup that's already compressed with WITH COMPRESSION. Both work on raw bytes rather than on anything SQL Server understands, so the reassembled file should be identical to the original either way, but that's reasoning rather than a result.

Understanding SQL Server Deadlocks Through the Prisoner's Dilemma

Tue, 17 Mar 2026 00:00:00 GMT

Everyone has written about deadlocks, so I wanted to try something different.

The Prisoner's Dilemma

Two suspects are arrested and held in separate rooms. Each is offered a deal to testify against the other and go free while the other serves the full sentence. If both stay silent, both serve a short sentence. If both testify, both serve a long one.

They can't talk to each other, so neither knows what the other will do.

	Suspect B stays silent	Suspect B testifies
Suspect A stays silent	Both serve 1 year	A serves 10, B goes free
Suspect A testifies	A goes free, B serves 10	Both serve 5 years

The rational move for each suspect is to testify, so both testify and both serve five years.

Your Transactions Are the Prisoners

Transaction A locks SalesOrderHeader and wants ProductInventory. Transaction B locks ProductInventory and wants SalesOrderHeader. Neither releases what it holds, so both wait.

	Transaction B releases	Transaction B holds
Transaction A releases	Both complete	B completes, A fails
Transaction A holds	A completes, B fails	Deadlock

SQL Server solves this by killing one of them. The victim's work is rolled back, and the other transaction completes.

Producing a Deadlock

Here's a way to produce a deadlock in AdventureWorks2022.

Open two separate query windows in SSMS (File > New Query, twice), both connected to AdventureWorks2022. Each window is its own connection. Run each statement one at a time, in step order.

Step	Session 1	Session 2
1	`BEGIN TRANSACTION;`<br/>`UPDATE Sales.SalesOrderHeader SET Comment = 's1' WHERE SalesOrderID = 43659;`
2		`BEGIN TRANSACTION;`<br/>`UPDATE Production.ProductInventory SET Quantity = Quantity WHERE ProductID = 1 AND LocationID = 1;`
3	`UPDATE Production.ProductInventory SET Quantity = Quantity WHERE ProductID = 1 AND LocationID = 1;`<br/>(hangs, waiting for Session 2)
4		`UPDATE Sales.SalesOrderHeader SET Comment = 's2' WHERE SalesOrderID = 43659;`<br/>(deadlock, 1205)

After Step 2, both sessions hold one lock each. After Step 3, Session 1 is blocked waiting on Session 2's lock.

Step 4 creates what's called a "circular wait": Session 1 is waiting on Session 2, and now Session 2 is waiting on Session 1. Neither can make progress because each holds what the other needs. SQL Server's deadlock monitor finds the cycle and ends one session with error 1205. It isn't instant. Microsoft's deadlocks guide says the monitor checks every 5 seconds by default, and more often, down to 100 milliseconds, while it keeps finding deadlocks.

You can also see the deadlock in the deadlock graph. The same guide says the system_health Extended Events session, which is on by default, "captures xml_deadlock_report events," so there's nothing extra to set up:

This graph is SQL Server's drawing of the prisoner's dilemma, with two nodes and arrows pointing at each other. The victim is the one SQL Server chose to kill.

The Cooperative Strategy

In the prisoner's dilemma, if the prisoners could agree on a strategy beforehand and trust each other to keep it, staying silent becomes the best choice. In SQL Server, that agreement is called "consistent lock ordering". The repro deadlocked because Session 1 locked the tables in one order and Session 2 locked them in the opposite order. If both sessions always lock SalesOrderHeader before ProductInventory, the circular wait can't form.

Step	Session 1 (consistent order)	Session 2 (consistent order)
1	Locks `SalesOrderHeader`	(waiting)
2	Locks `ProductInventory`	(waiting)
3	Commits, releases both	Locks `SalesOrderHeader`
4		Locks `ProductInventory`
5		Commits, releases both

There's no circular wait, so both complete.

That's one fix, but if you can't control the lock order, or deadlocking is still a recurring problem, there are a few other options.

Read Committed Snapshot Isolation

If you can't control lock ordering, say the queries come from an ORM or a vendor application, consider enabling Read Committed Snapshot Isolation (RCSI) at the database level.

ALTER DATABASE YourDatabase SET READ_COMMITTED_SNAPSHOT ON;

With RCSI enabled, reads stop taking the row and page locks they used to and instead read the last committed version of the row. It's close to say reads stop taking shared locks, but not exact. The <a href="https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide" target="_blank" rel="noopener noreferrer">locking and row versioning guide</a> says "Read operations require only the schema stability (Sch-S) table level locks and no page or row locks," so there's still a lock, it's just not one that a writer is going to collide with. That removes the most common class of reader-writer deadlocks without changing any query code. Writers still block writers.

Those row versions get kept in tempdb, and the <a href="https://learn.microsoft.com/en-us/sql/relational-databases/databases/tempdb-database" target="_blank" rel="noopener noreferrer">tempdb documentation</a> lists version stores among the things tempdb holds, including "row versions that are generated by data modification transactions in a database that uses row versioning-based READ COMMITTED or SNAPSHOT isolation transactions." So this moves work into tempdb rather than removing it, which is worth knowing on an instance where tempdb is already busy.

Optimized Locking (SQL Server 2025+ / Azure SQL)

If you're on Azure SQL Database or SQL Server 2025, Optimized Locking changes how the engine holds row locks. Normally a transaction acquires a lock on every row it touches and holds all of them until commit. With Optimized Locking, each row lock is released as soon as the row is written, and the transaction instead holds a single lightweight lock on its Transaction ID (TID). Fewer locks held for less time means fewer opportunities for a deadlock cycle to form.

The optimized locking documentation says accelerated database recovery (ADR) must be enabled first. RCSI isn't required, but the lock after qualification part of optimized locking only works with it on, so it's worth enabling too:

-- Accelerated Database Recovery is a prerequisite
ALTER DATABASE AdventureWorks2022 SET ACCELERATED_DATABASE_RECOVERY = ON;

-- RCSI is what gives you the full benefit (Lock After Qualification)
ALTER DATABASE AdventureWorks2022 SET READ_COMMITTED_SNAPSHOT ON;

Then enable Optimized Locking:

ALTER DATABASE AdventureWorks2022 SET OPTIMIZED_LOCKING = ON;

It's always enabled on Azure SQL Database and on Azure SQL Managed Instance with the Always-up-to-date or 2025 update policy. On SQL Server 2025 it's available but off by default, and SQL Server 2022 and older don't have it.

If you're on a version that supports it and you already have RCSI on, as far as I can tell enabling it is low-risk and worth doing. Writer-writer deadlocks on the same rows can still happen. Lock ordering fixes the cause, and Optimized Locking only makes it come up less often.

Retry Logic in the Application

I find this perfectly fine for most systems, and I see it in the wild more often than RCSI.

The application gets error 1205 back, so it's easy to catch and retry. SQL Server rolls back the victim and leaves the other transaction intact. A simple retry loop in the application handles it.

If you're hitting deadlocks often enough that retries matter, the actual problem is still there and worth addressing. It just depends on how you define "often" and "matter". If it's a rare occurrence and the cost of retries is low, this might be good enough.

Controlling the Victim

By default, SQL Server picks the transaction that's least expensive to roll back. You can override that with SET DEADLOCK_PRIORITY, and the priority is checked first. The <a href="https://learn.microsoft.com/en-us/sql/t-sql/statements/set-deadlock-priority-transact-sql" target="_blank" rel="noopener noreferrer">documentation</a> says "If the sessions have different deadlock priorities, the session with the lowest deadlock priority is chosen as the deadlock victim," and when the priorities match, SQL Server "chooses the session that is less expensive to roll back."

The range is -10 to 10, and NORMAL, the default, is 0. So if nobody has set a priority, every session is at 0 and the choice comes down to rollback cost. The deadlocks guide adds that if the priority and the cost are both the same, "a victim is chosen randomly."

-- Make this session the preferred deadlock victim
SET DEADLOCK_PRIORITY LOW;   -- equivalent to -5

-- Protect this session from being chosen
SET DEADLOCK_PRIORITY HIGH;  -- equivalent to 5

-- Set a specific numeric value
SET DEADLOCK_PRIORITY -3;

This is useful when one transaction is cheap to retry and another is expensive. Set the cheap one to LOW and SQL Server will consistently sacrifice it, keeping the expensive one alive. It's an interesting option, but I've never seen it used in production. That doesn't make it bad, just uncommon.

The key takeaway from all of this is that frequent deadlocks are a sign that something is wrong. Two transactions acquiring the same resources in opposite order will produce one eventually. Retry logic, deadlock priority and optimized locking make it less likely or less costly, but fixing the order is what removes the cycle.

How to Migrate Data Using bcp

Fri, 13 Mar 2026 00:00:00 GMT

import Callout from "@/components/Callout.astro";

On a recent cloud migration, I needed to move one year of data from one table on a client's servers to another SQL Server hosted in a VM in the cloud. The table already existed on the destination, so I only needed to move the data. The problem was that the VM we were moving into didn't have enough space to restore the entire database, so a full BACKUP/RESTORE/DELETE wasn't an option. I used bcp because it didn't require installing anything on the client's server.

The first thing I ran into was a certificate chain error when bcp connected to the local instance. The fix was the -u flag, which tells bcp to trust the server certificate. I added it to every command after that. According to the bcp documentation, -u needs bcp version 18 or later, which ships with SQL Server 2025, and bcp -v shows which version you have.

Next, I generated a format file. It maps the columns in the export to the columns in the destination table, and it's worth doing first so you can inspect it before any data moves.

bcp AdventureWorks2022.Person.Person format nul -S localhost -T -n -f person.fmt -u

If the format file exports successfully, the CMD window doesn't print anything. You can review it by opening the .fmt file in Notepad, and it should look something like this:

<Callout type="warning"> If you use a three-part name like AdventureWorks2022.Person.Person, don't also pass -d with the database name. bcp will error, telling you that you can't specify the database name twice. </Callout>

Before running the full year, I tested with one week to make sure the format file was right and the row counts matched.

bcp "SELECT * FROM AdventureWorks2022.Person.Person WHERE ModifiedDate >= '2013-01-01' AND ModifiedDate < '2013-01-08'" queryout person_test.bcp -S localhost -T -f person.fmt -u

Once that checked out, I ran the full year:

bcp "SELECT * FROM AdventureWorks2022.Person.Person WHERE ModifiedDate >= '2013-01-01' AND ModifiedDate < '2014-01-01'" queryout person_2013.bcp -S localhost -T -f person.fmt -u

I'm always pleasantly surprised by how fast bcp is. This export of 27,000 rows took about 3 seconds, and I've had exports of millions of rows take just a few minutes.

I copied the .bcp and .fmt files to the destination machine and ran the import. The table had an identity column and I needed to keep the original values, so I passed -E. I also set the destination database to simple recovery beforehand to keep log growth manageable.

-E has a permissions requirement worth knowing about if you're working with a limited account on someone else's server. The documentation says a bcp in "minimally requires SELECT and INSERT permissions on the target table," and that ALTER TABLE is also required when you use -E to keep identity values. The same list has two other cases that need ALTER TABLE: the table has constraints and you haven't passed the CHECK_CONSTRAINTS hint, or it has triggers and you haven't passed FIRE_TRIGGERS.

bcp AdventureWorks2022_dest.Person.Person in person_2013.bcp -S localhost -T -f person.fmt -u -E -b 10000 -e person_errors.txt -q

<Callout type="info"> Some guides recommend -h TABLOCK to reduce lock overhead during bulk inserts. In my case the database wasn't actively being used during the migration, so it didn't matter either way. </Callout>

The -b 10000 sets a batch size. By default, bcp imports every row in the file as one batch, so a failure near the end rolls back the whole import. With a batch size set, each batch is its own transaction, and the documentation says that "if the transaction for any batch fails, only insertions from the current batch are rolled back." Batches that already committed stay in the table.

After the import, I ran SELECT COUNT(*) with the same WHERE clause on both servers to confirm the numbers matched, checked that the error file was empty, and ran UPDATE STATISTICS on the destination table.

I don't have to do this very often, but it's nice to have in the toolkit for when I do.

Flags I Used

Flag	What it does
`-S`	Server and instance name
`-T`	Windows integrated auth
`-n`	Native binary format. Only needed when generating the format file. Omit it when using `-f`, or bcp warns that `-f` overrides it
`-f`	Path to the format file
`-E`	Keep identity values from the file instead of generating new ones
`-b`	Batch size in rows, so each batch commits as its own transaction
`-e`	File to write rejected rows and error reasons to
`-h`	Table hints passed to the bulk insert operation
`-q`	Runs `SET QUOTED_IDENTIFIER ON` for the connection. Needed for names with spaces or quotes, and inserts fail without it on tables with indexes on computed columns or indexed views
`-u`	Trust the server certificate (bcp 18 or later)

The full flag reference is in the bcp documentation.

How to Timeout an External Process in PowerShell

Thu, 05 Mar 2026 00:00:00 GMT

I was troubleshooting a PowerShell script that was part of an automation pipeline today. For the most part, everything ran fine, but I noticed one instance where the process would hang. The only way I was able to stop it was to kill it from Task Manager. I knew the automation typically takes 5-6 seconds per run, so I wanted the script to time itself out after 30 seconds.

Surprisingly, I'd never had to do anything like this before. After a little research, I found the WaitForExit(Int32) method, which I thought was perfect.

WaitForExit(Int32) is a method on the System.Diagnostics.Process object. It blocks the current thread for up to the number of milliseconds you give it, then returns true if the process exited in that window or false if it didn't. In PowerShell, you get the process object by passing -PassThru to Start-Process, which returns the object instead of discarding it. From there you call WaitForExit(30000) for a 30-second limit, check the return value, and call Kill() if it came back false.

The process isn't killed automatically when the timeout runs out, so that step has to be written out. Microsoft's documentation for Kill() says it "executes asynchronously," so calling WaitForExit() right after makes sure the process has fully stopped before the script continues. Calling Close() at the end frees the resources held for the exited process.

Here's an example of how I used it:

$proc = Start-Process python -ArgumentList "automation.py" -PassThru

if (-not $proc.WaitForExit(30000)) {
    $proc.Kill()
    $proc.WaitForExit()
    Write-Host "Timed out. Process killed."
} else {
    Write-Host "Done. Exit code: $($proc.ExitCode)"
}

$proc.Close()

It's important to note that there are two versions of WaitForExit, one with a parameter and one without. What WaitForExit(Int32) gives you that the no-argument version doesn't is a decision point. With WaitForExit(), your script hands control to the process and doesn't get it back until the process exits, which the documentation describes as waiting "indefinitely." If the process hangs, your script hangs with it. With WaitForExit(30000), you get control back after 30 seconds regardless. The process is still running at that point. Nothing interrupted it, you just stopped waiting for it. That's when you decide what to do next. In this case, I kill it, but you could also log it, retry it, or skip it.

To make this concrete, say your script normally finishes in 5 seconds but occasionally gets stuck. With WaitForExit():

$proc = Start-Process python -ArgumentList "automation.py" -PassThru
$proc.WaitForExit()
Write-Host "Done."

If the script hangs, Write-Host "Done." never runs, and your pipeline stops there. With WaitForExit(30000), a normal 5-second run returns true after 5 seconds and lands in the else branch. If it hangs, you get control back after 30 seconds, kill it, and the rest of your script continues.

The no-argument WaitForExit() still has its place, like right after Kill(), where you aren't setting a time limit but confirming the process is gone. What you want to avoid is using it for the timeout itself, where you need a way out if the process hangs.

One more detail from the Kill() documentation. Kill() stops only the process you started, not any processes it started in turn. On .NET Core 3.0 and later, there's a Kill(true) overload that also stops the process's descendants. The same page notes that WaitForExit() only reflects the process itself, not its descendants, even when you use Kill(true).

Wide vs Narrow Table Design in SQL Server

Sun, 15 Feb 2026 00:00:00 GMT

This post benchmarks a common modeling decision in SQL Server: should monthly values live as columns in a wide row, or as rows in a narrow fact-style table?

I took monthly sales and modeled it two ways. In Sales_Wide, months are columns (Jan through Dec). In Sales_Narrow, month is data (SalesMonth, Amount). I loaded 10,000 products across 5 years (2022-2026), which gave me 50,000 rows in Sales_Wide and 600,000 rows in Sales_Narrow.

For measurement, I used SET STATISTICS IO, TIME ON and looked at actual plan shape (scan vs seek). Then I ran the same business questions against both models: a single-month total and a Jan-Dec yearly breakdown.

SELECT SUM(Mar)
FROM Sales_Wide
WHERE SalesYear = 2026;

SELECT SUM(Amount)
FROM Sales_Narrow
WHERE SalesMonth = '2026-03-01';

SELECT
    SUM(Jan), SUM(Feb), SUM(Mar), SUM(Apr),
    SUM(May), SUM(Jun), SUM(Jul), SUM(Aug),
    SUM(Sep), SUM(Oct), SUM(Nov), SUM(Dec)
FROM Sales_Wide
WHERE SalesYear = 2026;

SELECT
    SUM(CASE WHEN MONTH(SalesMonth) = 1 THEN Amount END) AS Jan,
    SUM(CASE WHEN MONTH(SalesMonth) = 2 THEN Amount END) AS Feb,
    SUM(CASE WHEN MONTH(SalesMonth) = 3 THEN Amount END) AS Mar,
    SUM(CASE WHEN MONTH(SalesMonth) = 4 THEN Amount END) AS Apr,
    SUM(CASE WHEN MONTH(SalesMonth) = 5 THEN Amount END) AS May,
    SUM(CASE WHEN MONTH(SalesMonth) = 6 THEN Amount END) AS Jun,
    SUM(CASE WHEN MONTH(SalesMonth) = 7 THEN Amount END) AS Jul,
    SUM(CASE WHEN MONTH(SalesMonth) = 8 THEN Amount END) AS Aug,
    SUM(CASE WHEN MONTH(SalesMonth) = 9 THEN Amount END) AS Sep,
    SUM(CASE WHEN MONTH(SalesMonth) = 10 THEN Amount END) AS Oct,
    SUM(CASE WHEN MONTH(SalesMonth) = 11 THEN Amount END) AS Nov,
    SUM(CASE WHEN MONTH(SalesMonth) = 12 THEN Amount END) AS Dec
FROM Sales_Narrow
WHERE SalesMonth >= '2026-01-01'
  AND SalesMonth < '2027-01-01';

Before adding secondary indexes, narrow paid a large penalty because the month filter could not seek cleanly. You can see that immediately in the numbers.

Query (lower is better)	Wide (No index)	Narrow (No index)
March logical reads	710	1790
March elapsed ms	3	21
Yearly logical reads	710	1790
Yearly elapsed ms	46	131

Then I added the two indexes that match how these queries filter.

CREATE INDEX IX_Sales_Narrow_SalesMonth
ON Sales_Narrow (SalesMonth)
INCLUDE (Amount);

CREATE INDEX IX_Sales_Wide_SalesYear
ON Sales_Wide (SalesYear)
INCLUDE (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec);

After that, the comparison became much clearer. Sales_Narrow is excellent for single-month lookup, while Sales_Wide is still better for this fixed Jan-Dec report shape.

Query (lower is better)	Wide (indexed)	Narrow (indexed)
March logical reads	144	30
March CPU ms	0	0
March elapsed ms	4	0
Yearly logical reads	144	317
Yearly CPU ms	0	93
Yearly elapsed ms	31	116

Those results line up with the plans: both models move to seeks, but they still do different amounts of work for different query shapes.

There is also a storage tradeoff. The narrow model has more rows and, with supporting indexes, it consumes more total space.

Table	Rows	Reserved (before idx)	Reserved (after idx)	Data	Index Size (after idx)
Sales_Wide	50000	5832 KB	11824 KB	5640 KB	5672 KB
Sales_Narrow	600000	14472 KB	27376 KB	14248 KB	12632 KB

So what is better? In this demo, both are better at different things. If your core workload is a fixed cross-tab by year, wide is leaner for that output. If your core workload is time-centric filtering and slicing, narrow is the more natural model, as long as you index for that access path.

The practical takeaway is straightforward: model for the questions you actually ask, and back that model with the indexes those questions need.

One final note: if this same workload moved from monthly data to daily data, this tradeoff would usually tilt further toward the narrow pattern. A wide design based on time buckets gets harder to maintain and query as granularity increases, while a date-based narrow model stays consistent and indexable. We kept this demo monthly on purpose so the side-by-side comparison stays simple.

-- Repro setup (create and load demo data)
USE master;
GO

IF DB_ID('RowsVsColumnsDemo2026') IS NULL
    CREATE DATABASE RowsVsColumnsDemo2026;
GO

USE RowsVsColumnsDemo2026;
GO

DROP TABLE IF EXISTS Sales_Narrow;
DROP TABLE IF EXISTS Sales_Wide;
GO

CREATE TABLE Sales_Wide (
    ProductID int NOT NULL,
    SalesYear int NOT NULL,
    Jan money NULL,
    Feb money NULL,
    Mar money NULL,
    Apr money NULL,
    May money NULL,
    Jun money NULL,
    Jul money NULL,
    Aug money NULL,
    Sep money NULL,
    Oct money NULL,
    Nov money NULL,
    Dec money NULL,
    CONSTRAINT PK_Sales_Wide
        PRIMARY KEY (ProductID, SalesYear)
);

CREATE TABLE Sales_Narrow (
    ProductID int NOT NULL,
    SalesMonth date NOT NULL,
    Amount money NOT NULL,
    CONSTRAINT PK_Sales_Narrow
        PRIMARY KEY (ProductID, SalesMonth)
);

WITH P AS (
    SELECT TOP (10000)
        ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS ProductID
    FROM sys.objects a CROSS JOIN sys.objects b
)
INSERT INTO Sales_Wide
SELECT
    p.ProductID,
    y.SalesYear,
    ABS(CHECKSUM(NEWID())) % 10000,
    ABS(CHECKSUM(NEWID())) % 10000,
    ABS(CHECKSUM(NEWID())) % 10000,
    ABS(CHECKSUM(NEWID())) % 10000,
    ABS(CHECKSUM(NEWID())) % 10000,
    ABS(CHECKSUM(NEWID())) % 10000,
    ABS(CHECKSUM(NEWID())) % 10000,
    ABS(CHECKSUM(NEWID())) % 10000,
    ABS(CHECKSUM(NEWID())) % 10000,
    ABS(CHECKSUM(NEWID())) % 10000,
    ABS(CHECKSUM(NEWID())) % 10000,
    ABS(CHECKSUM(NEWID())) % 10000
FROM P p
CROSS JOIN (VALUES (2022),(2023),(2024),(2025),(2026)) y(SalesYear);

INSERT INTO Sales_Narrow (ProductID, SalesMonth, Amount)
SELECT
    ProductID,
    DATEFROMPARTS(SalesYear, MonthNum, 1),
    Amount
FROM Sales_Wide
UNPIVOT (
    Amount FOR MonthName IN
    (Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec)
) u
CROSS APPLY (
    VALUES (CASE MonthName
        WHEN 'Jan' THEN 1 WHEN 'Feb' THEN 2 WHEN 'Mar' THEN 3
        WHEN 'Apr' THEN 4 WHEN 'May' THEN 5 WHEN 'Jun' THEN 6
        WHEN 'Jul' THEN 7 WHEN 'Aug' THEN 8 WHEN 'Sep' THEN 9
        WHEN 'Oct' THEN 10 WHEN 'Nov' THEN 11 WHEN 'Dec' THEN 12
    END)
) m(MonthNum);

SET STATISTICS IO, TIME ON;

How to Merge SQL Server Data Files

Wed, 21 Jan 2026 00:00:00 GMT

I ran DBCC SHRINKFILE with EMPTYFILE against a 400GB database in FULL recovery and watched the transaction log go from about 20GB to nearly 200GB before I killed it. The operation is fully logged, one page at a time, and in FULL recovery every one of those page moves is sitting in the log waiting on a log backup. That's the thing I'd want to know before starting, so it's going first.

The database that got me here had one .mdf and seven .ndf files. That's not unusual in older systems and it's usually not necessary now. The workload wasn't pushing any storage limits and the disk was modern enough to handle a single data file, so the plan was to restore it as-is and then consolidate.

Multiple data files used to spread I/O across spinning disks, which was a real benefit at the time. On SSDs and SANs that advantage is typically small or gone, and managing the extra files costs more than it returns.

The screenshots below come from a small test database with the same kind of layout, one .mdf and three .ndf files, and I've included the script that builds it so you can follow along without touching anything real.

Why This Database Had Eight Files

SQL Server stores data inside filegroups, which are made up of logical files that point to the actual .mdf or .ndf files on disk. When you restore a backup, SQL Server expects every file in that backup to exist. There's no way to merge files during the restore itself. You have to bring the database online first, then consolidate afterward.

I prefer to collapse files when they're just leftover structure from an older environment:

You're no longer on spinning rust.
There's no real multi-volume layout behind them anymore.
The extra files make backups, monitoring, and restores more complicated than they need to be.

Multiple data files still make sense in some scenarios (TempDB, multiple storage tiers, massive OLTP), but in a lot of line-of-business systems they’re just historical clutter.

Demo Setup: Build a Playground With Multiple Data Files

Here's a self-contained lab script you can run on a dev instance. It creates a database with one MDF and three NDFs, loads some data, and gives you something to merge.

USE master;
GO

IF DB_ID('DemoMergeFiles') IS NOT NULL
BEGIN
    ALTER DATABASE DemoMergeFiles SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
    DROP DATABASE DemoMergeFiles;
END
GO

CREATE DATABASE DemoMergeFiles
ON PRIMARY
(
    NAME = N'DemoMergeFiles_Primary',
    FILENAME = N'F:\SQLData\DemoMergeFiles_Primary.mdf',
    SIZE = 200MB,
    FILEGROWTH = 50MB
),
(
    NAME = N'DemoMergeFiles_NDF1',
    FILENAME = N'F:\SQLData\DemoMergeFiles_NDF1.ndf',
    SIZE = 200MB,
    FILEGROWTH = 50MB
),
(
    NAME = N'DemoMergeFiles_NDF2',
    FILENAME = N'F:\SQLData\DemoMergeFiles_NDF2.ndf',
    SIZE = 200MB,
    FILEGROWTH = 50MB
),
(
    NAME = N'DemoMergeFiles_NDF3',
    FILENAME = N'F:\SQLData\DemoMergeFiles_NDF3.ndf',
    SIZE = 200MB,
    FILEGROWTH = 50MB
)
LOG ON
(
    NAME = N'DemoMergeFiles_Log',
    FILENAME = N'F:\SQLData\DemoMergeFiles_Log.ldf',
    SIZE = 200MB,
    FILEGROWTH = 50MB
);
GO

ALTER DATABASE DemoMergeFiles SET RECOVERY SIMPLE;
GO

Adjust paths to match wherever your instance keeps data and log files.

Load Some Data So The Files Actually Get Used

The table is wide on purpose, so its pages spread across every file in the filegroup.

USE DemoMergeFiles;
GO

IF OBJECT_ID('dbo.BigDemo', 'U') IS NOT NULL
    DROP TABLE dbo.BigDemo;
GO

CREATE TABLE dbo.BigDemo
(
    Id INT IDENTITY(1,1) PRIMARY KEY CLUSTERED,
    SomeText CHAR(4000) NOT NULL,
    SomeNumber INT NOT NULL,
    CreatedAt DATETIME2 NOT NULL
);
GO

-- Adjust this to make EMPTYFILE take longer or shorter.
DECLARE @TargetRows INT = 500000;

WITH Numbers AS
(
    SELECT TOP (@TargetRows)
           ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS n
    FROM sys.all_objects AS a
    CROSS JOIN sys.all_objects AS b
)
INSERT dbo.BigDemo (SomeText, SomeNumber, CreatedAt)
SELECT REPLICATE('X', 4000),
       n % 1000,
       DATEADD(SECOND, n, '2025-01-01')
FROM Numbers;
GO

On my test system, half a million rows was enough to put data in every file without taking long to load.

Determine File Usage Patterns

After the restore, or the demo setup above, the first thing I look at is the file layout and how much space each file is actually using.

USE DemoMergeFiles;
GO

SELECT  name,
        type_desc,
        physical_name,
        size * 8 / 1024 AS SizeMB,
        FILEPROPERTY(name, 'SpaceUsed') * 8 / 1024 AS UsedMB
FROM sys.database_files;

Pre-Migration Safety Preparations

In production I do a few things before touching the file structure:

Make sure there's a recent backup and that it actually restores.
Switch to SIMPLE recovery if the database can go without log backups for a while. Microsoft's recovery model page says to back up the log before switching away from FULL, and after switching back to take "a full or differential database backup to start the log chain," so I plan for both of those backups as part of the job.
Pick a time without long-running queries or index rebuilds. Moving an IAM page needs a schema modification (Sch-M) lock, and the DBCC SHRINKFILE documentation says "long-running queries can block a shrink operation," and that "any new query requiring a Sch-S lock on an IAM page can queue behind the shrink operation." On SQL Server 2022 and later there's WITH WAIT_AT_LOW_PRIORITY, which keeps the shrink from holding those queries up. The syntax allows it alongside EMPTYFILE, though the documentation's examples only show it with a regular shrink.

In this demo we already set the database to SIMPLE. If you're starting from a restore in FULL, this is roughly what I’d do:

ALTER DATABASE DemoMergeFiles SET RECOVERY SIMPLE;
GO

Switching to SIMPLE doesn't make EMPTYFILE any lighter. Shrink isn't on Microsoft's list of operations that can be minimally logged, so every page move is fully logged whatever the recovery model. What SIMPLE changes is when that log space can be reused. The log truncates "under the simple recovery model, after a checkpoint" instead of waiting on a log backup, which is the difference between my 20GB-to-200GB log in FULL and a log that can clear itself as it goes. The shrink documentation calls it "a long-running and resource-intensive operation," so in production I tell stakeholders that before I start. The database stays online, but EMPTYFILE takes a significant amount of time.

Move Pages With EMPTYFILE

To collapse files within a filegroup, you move all the pages out of the files you're removing and into the ones you're keeping.

The core commands for a single file look like this:

USE DemoMergeFiles;
GO

DBCC SHRINKFILE (N'DemoMergeFiles_NDF3', EMPTYFILE);
GO

Once the file is empty, removing it is one more command:

ALTER DATABASE DemoMergeFiles
REMOVE FILE DemoMergeFiles_NDF3;
GO

Behind the scenes, EMPTYFILE walks the file page-by-page, moving allocations into other files in the same filegroup. The documentation says it "migrates all data from the specified file to other files in the same filegroup," and that filegroup restriction is why this collapses files inside a filegroup and can't be used to move data between them. It's fully logged, and it's single-threaded, which the shrink documentation doesn't mention either way.

The same page has a detail that matters if you stop one partway, like I did with the 400GB database: "If you use the EMPTYFILE parameter and cancel the operation, the file isn't marked to prevent additional data from being added." That marking is what keeps new data out of a file while it's being emptied. The pages that already moved stay moved, but after a cancel the file can take new writes again, so it's worth running EMPTYFILE again before trying to remove it.

Monitoring Data Page Migration Progress

EMPTYFILE is slow and says very little in the Messages tab while it runs, so I watch it from sys.dm_exec_requests.

SELECT  session_id,
        command,
        status,
        percent_complete,
        start_time,
        total_elapsed_time,
        wait_type,
        wait_time,
        last_wait_type,
        cpu_time,
        reads,
        writes
FROM sys.dm_exec_requests
WHERE command LIKE '%DBCC%';

In the demo this finishes quickly. If you want to watch it for longer, increase @TargetRows in the data load.

In production, a ~220 GB NDF took about three hours. It runs online, but I still schedule it in a maintenance window because of the I/O it generates.

Remove The Emptied File

Once EMPTYFILE finishes, the file has no allocated pages and can be removed. After removing it, check the layout again:

SELECT  name,
        type_desc,
        physical_name,
        size * 8 / 1024 AS SizeMB,
        FILEPROPERTY(name, 'SpaceUsed') * 8 / 1024 AS UsedMB
FROM sys.database_files;

In production I repeat the "EMPTYFILE + REMOVE FILE" sequence for each secondary file I'm removing.

Post-Migration Validation

Once the files are down to one, I go back over a few things before I call it done:

Check the file layout again.
Run DBCC CHECKDB.
Take a fresh full backup if you have time.
Switch recovery model back to whatever it should be.

-- Sanity check
DBCC CHECKDB (N'DemoMergeFiles') WITH NO_INFOMSGS;
GO

-- Reset database back to FULL
ALTER DATABASE DemoMergeFiles SET RECOVERY FULL;
GO

Production Environment Considerations

Pre-growing the destination files doesn't make EMPTYFILE any faster. It avoids autogrowth events during the move, which is worth doing, but the page migration is still single-threaded and still fully logged.
FULL recovery is what caused the log growth I opened with. If you can't switch to SIMPLE, frequent log backups during the operation are the alternative, and you need somewhere to put them.
Consolidating files isn't a performance fix. The benefit is less administrative overhead, with one file to think about instead of eight during a restore.

When Multiple Data Files Are Still Worth It

I wouldn't do this to every database with .ndf files:

TempDB is the usual exception. Microsoft's setup guidance defaults it to one data file per logical processor, up to eight, and suggests adding more in multiples of four if contention shows up.
Very large databases spanning multiple volumes might still need multiple files per filegroup.
Partition schemes and archival strategies sometimes lean on separate files for a reason.

The move takes a long time, but it only happens once, and afterwards there's one data file instead of eight. That matters most on the day someone has to restore it somewhere else.

None of this makes the server faster tomorrow. It reduces operational complexity. If you want to show the process to your team or capture screenshots for documentation, the DemoMergeFiles database above runs the whole thing end to end without touching production.

Automating sp_WhoIsActive Installation

Mon, 17 Nov 2025 00:00:00 GMT

I use <a href="https://github.com/amachanic/sp_whoisactive/releases" target="_blank" rel="noopener noreferrer">sp_WhoIsActive</a> on pretty much every SQL Server I work with. Installing it by hand works fine. The project's README says to download sp_WhoIsActive.sql, open it in SSMS and run it. Now that dbatools can do that for me, the manual route feels like an extra step. If you don't have dbatools installed yet, I keep a short reference here: <a href="https://chandlergray.com/blog/installing-dbatools/" target="_blank" rel="noopener noreferrer">Installing dbatools</a>.

With dbatools available, the install is two lines:

$instance = Connect-DbaInstance -SqlInstance "localhost\MSSQLSERVER" -TrustServerCertificate
Install-DbaWhoIsActive -SqlInstance $instance -Database master -Verbose

Install-DbaWhoIsActive downloads the latest release from GitHub each time it runs, unless you point it at a local copy of the file. The <a href="https://dbatools.io/Install-DbaWhoIsActive" target="_blank" rel="noopener noreferrer">command's documentation</a> covers both options.

The same page explains why -Database master is written out. In an interactive session the command defaults to master on its own, but in a script it would stop and prompt for a database, so the parameter is required there. Master is also the right place for it. Installed there, the procedure can be run from every database on the instance, and installed in a user database it only works in that one. The sp_WhoIsActive README gives the same advice.

When I need it on several servers, I loop through the list:

$servers = @(
  "prod1\SQL"
  ,"prod2\SQL"
  ,"dev\SQL"
)

foreach ($s in $servers) {
  $i = Connect-DbaInstance -SqlInstance $s -TrustServerCertificate
  Install-DbaWhoIsActive -SqlInstance $i -Database master -Verbose
}

It saves a few minutes and keeps the install the same across the environments I touch.

The loop has no error handling. For three servers the output is easy enough to watch as it runs. For a longer list, I'd wrap the body of the loop in a try/catch and collect the servers that failed, so the list of what still needs attention is waiting at the end.

Don't Outsource Your Problem

Fri, 31 Oct 2025 00:00:00 GMT

I've fired off plenty of screenshots hoping someone else would save me five minutes of reading, and it never helped. You hit an error, take one look at the message, and drop it in Teams with a quick "anyone seen this before?" hoping someone will come back with an answer.

That's what I call outsourcing your problem.

Asking for help is fine. It's part of working in tech, but how you ask matters. When you just forward the problem, you're asking someone else to start cold. They don't know what you're doing, what changed, or what you've already checked, so they have to do all the discovery you skipped.

If you want real help, bring context. Read the message and try to understand what it's saying. Even if you don't get far, it shows the other person where to start. Compare these two:

"Anyone know how to fix this?" vs. "I ran X and got this error. It looks like Y is failing, but I'm not sure why. Can you help me read it?"

The second one tells people you've tried to think it through. They'll respond faster, and you'll learn something instead of just copying a fix.

Most people don't expect you to know everything, but they do expect you to care enough to figure out what's happening before asking for a rescue. So before you hit send on that screenshot, read the error, think about what changed, and try to narrow it down. Then, if you're still stuck, ask for help with context.

This doesn't mean working everything out alone. If it's a common error with a common fix, and I can find the answer in the archives by myself, I'll take it. The case where I try to stay with it is when I barely understand what I'm trying to build in the first place.

That happened when I installed Proxmox for the first time. The storage pool I set up was only recognizing some of the space on my drives, and I didn't notice until I was moving my media library onto a VM and started getting errors saying I was out of drive space. I spent the first few hours learning how to troubleshoot drives on Linux, mostly reading Stack Overflow and Reddit posts, trying to figure out how to even figure out what was happening. It came down to how ZFS handles drives of different sizes, which was a gap in my understanding and not something wrong with Proxmox.

I could have reached out to someone I knew who probably would have steered me in the right direction sooner. I didn't, because I barely understood what I was trying to accomplish, and I wanted to use it to fill in that gap. I also didn't want them to feel like they needed to take responsibility for my problem. That second reason is the part of this I care about most. Handing someone a screenshot and nothing else hands them the problem too.

The best fixes I've learned came from slowing down long enough to understand what the system was actually saying.

Installing dbatools

Wed, 15 Oct 2025 00:00:00 GMT

I write a lot about SQL Server automation, and dbatools comes up constantly. Instead of rewriting the install steps in every post, I'm putting them here once so I can point back to them.

The full instructions live on the official site at <a href="https://dbatools.io/install" target="_blank" rel="noopener noreferrer">dbatools.io/install</a>. If you're new to dbatools, follow those first, since they're maintained by the project and this page is only my summary of them. Their <a href="https://dbatools.io/getting-started/" target="_blank" rel="noopener noreferrer">Getting Started page</a> is worth a look while you're there. It's mostly examples, which is a good way to see what the module can do.

The install the dbatools site recommends is one line, and it doesn't need an admin session:

Install-Module dbatools -Scope CurrentUser

-Scope CurrentUser puts the module in a folder under your own profile, and Microsoft's <a href="https://learn.microsoft.com/en-us/powershell/module/powershellget/install-module" target="_blank" rel="noopener noreferrer">Install-Module documentation</a> describes that location as "accessible only to the current user of the computer." One side effect follows from that. A scheduled task or SQL Agent job running under a different account, like a service account, won't find a module you installed this way, and it needs its own copy or an install for all users.

Installing for all users is Install-Module dbatools from an administrator PowerShell session. Leaving -Scope off doesn't always mean all users, though. The same documentation says the default depends on the PowerShellGet version. Version 1.x defaults to all users, while 2.0 and later on PowerShell 6 or higher default to the current user unless the session is elevated. Writing the scope out avoids having to know which one you're on.

If you're prompted about trusting the repository, say yes, since it's the official source. On older systems you may also need to trust PSGallery explicitly:

Set-PSRepository -Name PSGallery -InstallationPolicy Trusted

To check that it worked:

Get-Command -Module dbatools

And to pick up a newer release later:

Update-Module dbatools

Note: If you get errors about script execution policy, you may need to let PowerShell run the module's scripts. The simplest way is:
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
Microsoft's <a href="https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies" target="_blank" rel="noopener noreferrer">execution policy documentation</a> explains the setting. RemoteSigned runs scripts written on the local machine and requires a trusted signature on scripts downloaded from the internet. The same page points out that execution policy "isn't a security boundary," so it's there to stop accidents rather than attacks.

That covers most modern setups. For machines without internet access, the dbatools site has an offline install guide, and it also lists Chocolatey (choco install dbatools) as another option.

Setting Up an FTP Server on Ubuntu with vsftpd

Fri, 26 Sep 2025 00:00:00 GMT

I run my servers inside Proxmox, so in this case the FTP service lives on an Ubuntu Server VM there. The same steps apply whether you're on bare metal or any other hypervisor.

This sets up plain FTP, which sends the username, the password and the file contents across the network unencrypted. On a home LAN behind a router, that's a decision you can make for yourself, but not on anything exposed to the internet. The vsftpd.conf man page has an ssl_enable option that encrypts both the login and the data connections, or you can use SFTP over SSH instead of FTP.

Create the VM

Install Ubuntu Server LTS and give it a static LAN IP so it’s easy to reach later. I used a bridged adapter in Proxmox so the VM behaves like any other machine on my network.

If the VM can’t be reached from another machine, double-check the network adapter mode and make sure the IP address is in the right subnet.

Update the OS

Bring the system up to date before adding anything else.

sudo apt update && sudo apt upgrade -y

Mirror issues can cause failures. Running the command again usually clears it up.

Install vsftpd

Install the FTP daemon package.

sudo apt install vsftpd -y

If the service doesn’t appear to exist, confirm with systemctl status vsftpd.

Create an FTP User

I added a dedicated account just for FTP traffic so it’s separate from system logins.

sudo adduser ftpuser

Set a password when prompted.

Later login failures (530 Login incorrect) often mean the account is disabled in /etc/ftpusers or local_enable isn’t set in the config.

Set Up the Directory Structure

vsftpd refuses to start a session where the chroot directory itself is writable by the user. To work around this, I made a locked root folder with a writable subdirectory for uploads.

The man page doesn't document that check, so the error message is the best guide to it. It does have a warning on chroot_local_user, which is the setting that jails users. It says the option "has security implications, especially if the users have upload permission, or shell access." Keeping the root locked and the writable area down to one directory is one way to limit that.

sudo mkdir -p /srv/ftp/uploads
sudo chown root:root /srv/ftp
sudo chmod 755 /srv/ftp
sudo chown ftpuser:ftpuser /srv/ftp/uploads

Common errors:

500 OOPS: vsftpd: refusing to run with writable root inside chroot usually means permissions on /srv/ftp are wrong. It must be owned by root and not writable.

Configure vsftpd

Open the config:

sudo nano /etc/vsftpd.conf

Here’s what I used:

listen=YES
listen_ipv6=NO

anonymous_enable=NO
local_enable=YES
write_enable=YES
chroot_local_user=YES

That config sets up the account and the chroot but doesn't pin the passive port range, so vsftpd picks from a wide default and the firewall rules further down won't line up with it. The man page gives the default for both pasv_min_port and pasv_max_port as "0 (use any port)," and says a range "can be used to specify a narrow port range to assist firewalling," which is the reason to set them at all. Add these two so the range matches what you open in UFW:

pasv_min_port=30000
pasv_max_port=30049

The man page says chroot_local_user=YES places local users "in a chroot() jail in their home directory after login." adduser gives ftpuser a home directory under /home, so to use the /srv/ftp layout above, point the user at it. The local_root option sets the directory vsftpd changes into after a local login:

local_root=/srv/ftp

If directory listings stall, the passive port range isn’t open.
If the server advertises 127.0.1.1 in passive mode, add pasv_address=<your_LAN_IP> to the config.

Restart and Enable the Service

Restart the daemon and enable it at boot.

sudo systemctl restart vsftpd
sudo systemctl enable vsftpd

If it fails to enable, check the logs:

journalctl -u vsftpd -n 50 --no-pager

Adjust the Firewall

If UFW is enabled, open the command port and the passive range.

sudo ufw allow 21/tcp
sudo ufw allow 30000:30049/tcp

UFW must be active for these rules to matter. Verify with sudo ufw status.

Test Locally

Before trying a client, I tested from the server itself.

curl -v --user 'ftpuser:YourPassword' ftp://127.0.0.1/
curl -v --user 'ftpuser:YourPassword' -T /etc/hosts ftp://127.0.0.1/uploads/
ls -l /srv/ftp/uploads

530 Login incorrect: check username, password, and config.
550 Permission denied: verify /srv/ftp/uploads is owned by ftpuser.

Connect from Another Machine

Connect with an FTP client using your VM’s IP address.

Host: <LAN_IP>
Port: 21
Protocol: FTP
Username: ftpuser
Password: your password
Transfer mode: Passive

I only use these FTP servers on my local network, so I haven't gone overboard with hardening them for internet exposure. Network security isn't my specialty, so I stick to the basics. If you've got suggestions for tightening things up, either for FTP specifically or my home lab in general, I'd be glad to hear them.

The Monty Hall Problem That Made Me a Better DBA

Tue, 22 Jul 2025 00:00:00 GMT

import Callout from "@/components/Callout.astro";

Switching doors in the Monty Hall problem wins two games out of three, and staying wins one. I know that's the answer and it still doesn't feel right to me. It's also what I think of when I'm looking at an execution plan that SQL Server compiled for somebody else's parameter.

The game

You're on a game show with three doors. There's a car behind one of them and a goat behind each of the other two. You pick a door, and the host, Monty, opens one of the two you didn't pick to show you a goat. Then he asks whether you want to keep your door or switch to the other closed one.

With two doors left it looks like a coin flip. What makes it different is that Monty knows where the car is and never opens that door. Wikipedia's article on the problem lists the rules the usual answer depends on, including that the host "must always open a door to reveal a goat and never the car." Your first pick was right one time in three, and nothing Monty does afterwards changes that, so the other two thirds are sitting behind the door he left closed.

If you'd rather see it than follow the reasoning, this plays the game 200,000 times:

import random

N = 200_000
stay = switch = 0
for _ in range(N):
    car = random.randrange(3)
    pick = random.randrange(3)
    opened = random.choice([d for d in range(3) if d != pick and d != car])
    other = [d for d in range(3) if d != pick and d != opened][0]
    stay += pick == car
    switch += other == car

print(f"stay {stay / N:.4f}  switch {switch / N:.4f}")

It prints numbers close to 0.33 for staying and 0.67 for switching. MythBusters tested it too, in a 2011 episode called "Wheel of Mythfortune."

Where SQL Server comes in

The first time a stored procedure runs, SQL Server compiles a plan for it using the parameter values from that call, then caches the plan and reuses it for later calls. Microsoft's page on recompiling a stored procedure puts it this way: "any parameter values that are used by the procedure when it compiles are included as part of generating the query plan." This is what people mean by parameter sniffing. If the first value is a typical one, the plan suits most of the calls that follow. If it isn't, every call after it runs on a plan built for a value it doesn't have.

That's where the game comes to mind for me. A choice gets made with the information available at the time, and the question is whether to revisit it once you know more. By default SQL Server doesn't revisit it. The cached plan stays until something causes a recompile. The comparison is loose, since there's no host and none of the probability carries over, but "should I switch now that I know more" is the question I end up asking about a cached plan.

The demo

The setup builds a table where one value makes up almost every row. Run it on a test instance, because the steps after it clear the plan cache.

-- Setup
CREATE DATABASE MontyDB
GO

DROP TABLE IF EXISTS dbo.MontyTest;

CREATE TABLE dbo.MontyTest (
	Id INT IDENTITY PRIMARY KEY
	,Category VARCHAR(20)
	,SomeData CHAR(100)
	);

-- Insert skewed data: 1 very common value, 2 rare values
INSERT INTO dbo.MontyTest (
	Category
	,SomeData
	)
SELECT CASE 
		WHEN n <= 1000
			THEN 'RareA'
		WHEN n <= 2000
			THEN 'RareB'
		ELSE 'Common'
		END
	,REPLICATE('x', 100)
FROM (
	SELECT TOP (100000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS n
	FROM sys.all_objects a
	CROSS JOIN sys.all_objects b
	) AS x;
-- (100000 rows affected)

-- Create index to make plan choices interesting
CREATE NONCLUSTERED INDEX IX_Monty_Category ON dbo.MontyTest (Category);

That's 1,000 rows of 'RareA', 1,000 of 'RareB' and 98,000 of 'Common', so 'Common' is 98% of the table.

<Callout type="warning"> DBCC FREEPROCCACHE with no arguments clears every plan on the instance, not only the ones in this database. The documentation says it "causes all plans to be evicted," which "can cause a sudden, temporary decrease in query performance as the number of new compilations increases." On SQL Server 2016 and later, ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE clears the plans for the current database only. </Callout>

Step 1: Create a stored procedure to trigger plan reuse

-- Clean cache and create procedure
DBCC FREEPROCCACHE;
GO

DROP PROCEDURE IF EXISTS dbo.SniffMonty;
GO
CREATE PROCEDURE dbo.SniffMonty @Category VARCHAR(20)
AS
BEGIN
    SET NOCOUNT ON;
    SELECT * FROM dbo.MontyTest WHERE Category = @Category;
END;
GO

Step 2: Run it with the rare value first

-- This execution generates the cached plan
EXEC dbo.SniffMonty @Category = 'RareA';

That call compiles a plan for 'RareA' and caches it. Running the procedure again with 'Common' reuses that plan.

-- Run with common value, reusing the plan compiled for RareA
EXEC dbo.SniffMonty @Category = 'Common';

The numbers under the operator, 98000 of 1000 (9800%), are the actual row count over the estimate. Hovering over the operator shows the same thing in more detail, with 1000 for "Estimated Number of Rows Per Execution" and 98000 for "Actual Number of Rows for All Executions."

The estimate of 1,000 came from 'RareA', which is the value the plan was compiled for. The call that reused it returned 98 times as many rows as the plan expected.

Step 3: Clear the cache and reverse the order

-- Clear cache
DBCC FREEPROCCACHE;
GO

-- Now run with the common value first
EXEC dbo.SniffMonty @Category = 'Common';
-- Then rare
EXEC dbo.SniffMonty @Category = 'RareA';

Both calls ran in one batch, so the screenshot has both plans. 'Common' went first and got 98000 of 98000 (100%), which is what it looks like when a plan runs with the value it was compiled for. 'RareA' reused that plan and got 1000 of 98000 (1%). The estimate is now 98 times too high where it was 98 times too low before.

What the plans actually show

The setup creates an index on Category so the optimizer has a choice to make, but it didn't use that index in any of these runs. Every plan above is the same Clustered Index Scan, which reads the whole table, and the tooltip shows it reading all 100,000 rows. The estimate changed between runs and the plan stayed the same.

The likely reason is in the green text at the top of each plan. SQL Server suggests a missing index that includes SomeData. The procedure selects every column, and IX_Monty_Category only has Category, so using it would mean a trip back to the table for the rest of each row. That's the key lookup I wrote about in avoiding key lookups. For this table, SQL Server estimated that scanning was cheaper even when it expected only 1,000 rows. Confirming it would mean rerunning the demo with fewer columns selected, or with the suggested index in place, and checking whether the two orders then produce different plans.

So the demo shows the estimate going stale, which is the core of parameter sniffing, but it doesn't show a stale plan costing anything. The elapsed times are all small: 0.023s for 'Common' on the plan compiled for 'RareA', 0.033s for 'Common' on its own plan, and 0.006s for 'RareA' on the plan compiled for 'Common'. The trouble starts when the estimate decides between two different plans. Microsoft describes that case as one where "a single cached plan for a parameterized query isn't optimal for all possible incoming parameter values."

Ways to switch doors

Recompile. EXEC ... WITH RECOMPILE compiles a plan for the values in that call. The statement-level version, OPTION (RECOMPILE) inside the procedure, tells SQL Server to "generate a new, temporary plan for the query and immediately discard that plan after the query completes execution," according to the query hints documentation. Every call pays for a compile that way, which is worth measuring before using it on a procedure that runs constantly. In this demo, recompiling would give each call an accurate estimate, but going by the screenshots it would still be a scan.

-- Force recompile per-execution
EXEC dbo.SniffMonty @Category = 'Common' WITH RECOMPILE;
EXEC dbo.SniffMonty @Category = 'RareA' WITH RECOMPILE;

OPTIMIZE FOR UNKNOWN. The same page says this hint makes the optimizer "use the average selectivity of the predicate across all column values, instead of using the runtime parameter value." With three distinct values in this table, I'd expect that to come out around a third of the rows, which is wrong for all three of them, though the demo doesn't show the estimate it actually produces.

OPTIMIZE FOR (@Category = 'Common'). This compiles the plan as if every call passed 'Common'. That suits a table like this one, where almost every call probably will, and it puts 'RareA' where it was in Step 3.

Parameter Sensitive Plan optimization. On SQL Server 2022 and later, PSP optimization "automatically enables multiple, active cached plans for a single parameterized statement," chosen by the parameter value at runtime. It needs database compatibility level 160, it "currently only works with equality predicates," which Category = @Category is, and it doesn't run on queries with a RECOMPILE hint. The screenshots don't show MontyDB's compatibility level, so it isn't clear whether PSP was available when they were taken.

What this doesn't answer yet

Two things are still open. The first is a version of this demo where the index really is the better choice for 'RareA', so the stale estimate leads to a different plan instead of the same one. The second is running it at compatibility level 160 to see whether PSP splits the procedure into separate plans for 'RareA' and 'Common'.

SELECT * in SQL Server: Payload and Throughput

Wed, 09 Jul 2025 00:00:00 GMT

In this test, SELECT * had an estimated row size of 2,965 bytes, while the four columns the application actually uses came to 342, about 8.7 times smaller.

I wanted to see what changed in my environment when I used SELECT * instead of listing only the columns my application needed, so I ran the same single-customer lookup three ways against a CustomerProfile table with 500,000 rows. The three forms were a narrow application payload (CustomerID, Email, LastLogin, Status), an explicit full payload, and SELECT *.

From plan details, all three versions used the same lookup method in this run. The main difference was the size of the payload returned to the application:

Query shape	Estimated row size
Narrow projection	342 bytes
Explicit full projection	2965 bytes
`SELECT *`	2965 bytes

In this run, SELECT * returned a payload about 8.7x wider than the narrow query.

Plan property captures from the run:

The performance details from this run are below. Query cost was read from the plan banner and CPU/elapsed came from STATISTICS TIME output.

Query	Relative query cost (single-query batch)	Estimated CPU cost (plan)	Observed elapsed time
Narrow projection	100%	0.0001581	0-1 ms
Explicit full projection	100%	0.0001581	37 ms
`SELECT *`	100%	0.0001581	39-40 ms

Two notes help with interpretation. First, query cost here is relative to the current batch, so it's useful for side-by-side shape checks but not as a measure of scale by itself. Second, CPU is reported as 0 ms for all three queries in this run, which means CPU was below the visible resolution of this capture. Because of that, the scale math below uses payload size and elapsed time.

Using the row-size delta from this run, 2965 - 342 = 2623 extra bytes were returned per call when SELECT * was used instead of the narrow query.

Executions/day	Extra payload/day	Extra payload/month (30d)
100	262,300 bytes (~0.25 MB)	~7.50 MB
1,000	2,623,000 bytes (~2.50 MB)	~75.06 MB
100,000	262,300,000 bytes (~250.15 MB)	~7.33 GB
1,000,000	2,623,000,000 bytes (~2.44 GB)	~73.29 GB

Using the same run's elapsed-time values also gives a straightforward throughput view:

Executions/day	Narrow projection (1 ms)	Explicit full projection (37 ms)	`SELECT *` (39-40 ms)
100	0.1 sec	3.7 sec	3.9-4.0 sec
1,000	1 sec	37 sec	39-40 sec
100,000	1m 40s	61m 40s	65m 0s-66m 40s
1,000,000	16m 40s	10h 16m 40s	10h 50m 0s-11h 6m 40s

For CPU, this capture reported 0 ms per call for all three queries. That means CPU was below SQL Server's visible 1 ms resolution in this test. The table below shows the practical implication: measured CPU remains 0 at this capture granularity, and the only safe extrapolation is an upper bound of < 1 ms per call.

Executions/day	Measured CPU/day (from this run)	Upper bound if each call were `< 1 ms`
100	0 ms	< 0.1 sec
1,000	0 ms	< 1 sec
100,000	0 ms	< 100 sec
1,000,000	0 ms	< 1,000 sec (~16m 40s)

This doesn't mean every SELECT * query is a problem. It shows that in this scenario, wider payload has a measurable cost profile, especially as daily execution counts increase. If an application really needs the full row, SELECT * can still be reasonable. If it only needs a few columns, returning everything adds overhead without adding value.

If you want to check this on your own instance, run the setup and comparison queries below and inspect Estimated Row Size plus the STATISTICS TIME output.

Setup (500k-row demo table)

USE master;
GO

IF DB_ID('SelectStarEvaluationDemo') IS NULL
    CREATE DATABASE SelectStarEvaluationDemo;
GO

USE SelectStarEvaluationDemo;
GO

DROP TABLE IF EXISTS dbo.CustomerProfile;
GO

CREATE TABLE dbo.CustomerProfile
(
    CustomerID int IDENTITY(1,1) NOT NULL,
    Email nvarchar(320) NOT NULL,
    LastLogin datetime2(0) NOT NULL,
    Status char(1) NOT NULL,
    FirstName nvarchar(80) NULL,
    LastName nvarchar(80) NULL,
    Address1 nvarchar(120) NULL,
    Address2 nvarchar(120) NULL,
    City nvarchar(80) NULL,
    StateCode char(2) NULL,
    PostalCode nvarchar(20) NULL,
    CountryCode char(2) NULL,
    Phone nvarchar(30) NULL,
    MarketingOptIn bit NULL,
    BirthDate date NULL,
    LoyaltyTier tinyint NULL,
    CreditLimit money NULL,
    LastOrderAmount money NULL,
    LastOrderDate datetime2(0) NULL,
    Notes nvarchar(400) NULL,
    Preferences nvarchar(500) NULL,
    InternalFlags int NULL,
    RiskScore decimal(9,4) NULL,
    JsonProfile nvarchar(1000) NULL,
    SSN_Encrypted varbinary(256) NULL,
    CONSTRAINT PK_CustomerProfile PRIMARY KEY CLUSTERED (CustomerID)
);
GO

;WITH n AS
(
    SELECT TOP (500000)
        ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS i
    FROM sys.all_objects a
    CROSS JOIN sys.all_objects b
)
INSERT dbo.CustomerProfile
(
    Email, LastLogin, Status,
    FirstName, LastName, Address1, Address2, City, StateCode, PostalCode,
    CountryCode, Phone, MarketingOptIn, BirthDate, LoyaltyTier,
    CreditLimit, LastOrderAmount, LastOrderDate, Notes, Preferences,
    InternalFlags, RiskScore, JsonProfile, SSN_Encrypted
)
SELECT
    CONCAT('user', i, '@example.com'),
    DATEADD(MINUTE, -1 * (i % 100000), SYSUTCDATETIME()),
    CASE WHEN i % 7 = 0 THEN 'I' ELSE 'A' END,
    CONCAT('First', i),
    CONCAT('Last', i),
    CONCAT(i, ' Main St'),
    NULL,
    CONCAT('City', i % 1000),
    RIGHT('00' + CONVERT(varchar(2), (i % 50) + 1), 2),
    RIGHT('00000' + CONVERT(varchar(5), i % 100000), 5),
    'US',
    CONCAT('555-01', RIGHT('00' + CONVERT(varchar(2), i % 100), 2)),
    CASE WHEN i % 3 = 0 THEN 1 ELSE 0 END,
    DATEADD(DAY, -1 * (i % 20000), CAST('2025-01-01' AS date)),
    i % 5,
    (i % 20000) * 1.0,
    (i % 5000) * 1.0,
    DATEADD(DAY, -1 * (i % 365), SYSUTCDATETIME()),
    REPLICATE('n', 100),
    REPLICATE('p', 120),
    i % 1024,
    CAST((i % 10000) / 100.0 AS decimal(9,4)),
    CONCAT('{"segment":"', i % 12, '","score":', i % 100, '}'),
    CONVERT(varbinary(256), HASHBYTES('SHA2_256', CONVERT(varchar(20), i)))
FROM n;
GO

Queries to Compare

SET STATISTICS IO, TIME ON;
GO

SELECT CustomerID, Email, LastLogin, Status
FROM dbo.CustomerProfile
WHERE CustomerID = 250000;
GO

SELECT *
FROM dbo.CustomerProfile
WHERE CustomerID = 250000;
GO
SELECT
    CustomerID, Email, LastLogin, Status,
    FirstName, LastName, Address1, Address2, City, StateCode, PostalCode,
    CountryCode, Phone, MarketingOptIn, BirthDate, LoyaltyTier,
    CreditLimit, LastOrderAmount, LastOrderDate, Notes, Preferences,
    InternalFlags, RiskScore, JsonProfile, SSN_Encrypted
FROM dbo.CustomerProfile
WHERE CustomerID = 250000;
GO

For my use case, the practical takeaway is simple: match the query payload to what the application actually needs.

How to Set SQL Server Autogrowth for All Databases (and Why You Should)

Mon, 12 May 2025 00:00:00 GMT

I inherit a lot of SQL Server databases. Different teams, different eras, different ideas of what "good enough" looks like. One thing that always surprises me is how inconsistent the autogrowth settings are. Filegrowths in megabytes, percentages, tiny increments... it's all over the place.

In my earlier post on safely shrinking SQL Server transaction logs, I touched on why autogrowth matters. Each growth of the log adds more virtual log files (VLFs), and a log that grows in many small steps ends up with a lot of them, which slows down recovery and restores.

I'm often taking over databases that are 10+ years old, with no history, no documentation, and no log monitoring to speak of. There's nobody around to ask why things are set the way they are. So, barring any evidence to the contrary, I take the same approach every time and standardize autogrowth to 1024MB for every user database.

The Script

This is the script I use:

SELECT 
    db.name AS DatabaseName
    ,db.database_id AS DatabaseId
    ,mf.type AS FileType
    ,mf.name AS FileName
    ,'USE ' + db.name + '; ALTER DATABASE [' + db.name + '] MODIFY FILE (NAME = [' + mf.name + '], FILEGROWTH = 1024MB);' AS Script
FROM sys.databases db
JOIN sys.master_files mf ON db.database_id = mf.database_id
WHERE db.database_id > 4;

Run it, get your ALTER DATABASE commands, and apply them. This doesn't change current file sizes. It only changes future growth, so it happens in predictable chunks.

As written, the script covers log files as well as data files. On SQL Server 2022 and later, there's a reason to handle logs differently, which is covered below.

Why This Might Not Work for You

There's no one-size-fits-all in database management. This approach assumes:

You care more about reducing VLF fragmentation than squeezing every gigabyte.
You have the disk space to absorb larger growth steps.
You're okay with uniformity until you get better data.

If you're managing a system with tight disk constraints, high-churn databases, or specific growth patterns (think OLAP vs OLTP workloads), this blanket setting might not be right. For legacy systems where nobody knows why the settings are what they are, it's a solid default until you have evidence otherwise.

One Note on Log Files and IFI

SQL Server 2022 added instant file initialization (IFI) for log file growth. Normally, SQL Server fills new file space with zeros before using it. Data files have been able to skip that for a long time, but log files always had to be zeroed first. Microsoft's instant file initialization page says that starting with SQL Server 2022, "transaction log autogrowth events up to 64 MB can benefit from instant file initialization," and that growth events "larger than 64 MB can't." Log IFI also doesn't need the Perform Volume Maintenance Tasks privilege that data file IFI does. The same page notes that the default autogrowth for new databases is already 64 MB.

A log set to grow by 1024MB still gets zeroed on every growth. Aaron Bertrand tested this in Log File Instant File Initialization, comparing 64MB and 1GB log autogrowth on SQL Server 2019 and 2022. On 2022, the 64MB setting took roughly 20% off his workload's duration by getting rid of the PREEMPTIVE_OS_WRITEFILEGATHER waits spent zeroing the file.

On SQL Server 2022, a 64MB log growth also creates a single VLF, according to Microsoft's transaction log architecture guide, so keeping log growth at 64MB doesn't work against the VLF count the way small growths did on older versions.

This only affects log files, and only on SQL Server 2022 and later. Data files still want the bigger growth, in my opinion. To apply the script to data files only and handle logs separately, add AND mf.type = 0 to the WHERE clause.

How to Safely Shrink a SQL Server Transaction Log File

Sun, 11 May 2025 00:00:00 GMT

Your disk is running low on space. You find a blog post or Stack Overflow answer suggesting DBCC SHRINKFILE, so you run it. It either seems to work or does nothing. Either way, the log eventually grows back, your I/O takes a hit, and the problem comes back a week later.

Shrinking your transaction log is a temporary measure, not a fix. If you're doing it regularly, you're probably solving the wrong problem.

What DBCC SHRINKFILE Really Does

A transaction log is divided internally into virtual log files (VLFs). Shrinking a log file can only release VLFs at the end of the file that are inactive, meaning nothing in them is still needed. Microsoft's DBCC SHRINKFILE documentation says that when part of the active log sits past the target size, SQL Server "frees as much space as possible, and then issues an informational message." If the VLFs at the end are still in use, nothing gets released.

Example:

USE [YourDatabase];
GO
DBCC SHRINKFILE (N'YourDatabase_Log', 1024);  -- target size in MB
GO

You won't get an error. The file just doesn't shrink. And if you're in full recovery mode without frequent log backups, SQL Server can't mark old log space as reusable.

The same page has a troubleshooting section for exactly this, headed "The file doesn't shrink." It says "a common reason for a transaction log file not to shrink is the absence of regular transaction log backups." It also says a log file "can only be shrunk to a virtual log file boundary," so a target smaller than one VLF won't be reached even when the space is free.

Reproducing the Problem

Here's a simple demo you can try to see why shrinking often doesn't work:

-- Step 1: Create a test database
CREATE DATABASE TestShrink;
GO

-- Step 2: Set recovery model to FULL and try to shrink
ALTER DATABASE TestShrink SET RECOVERY FULL;
GO
DBCC SHRINKFILE (TestShrink_Log, 1);
GO

-- Step 3: Open a transaction that holds the log open
USE TestShrink;
BEGIN TRAN;
SELECT 1; -- Keeps the transaction open

-- Step 4: Attempt to shrink again
DBCC SHRINKFILE (TestShrink_Log, 1);
GO

With the transaction open and no log backups taken, the shrink command has nothing to release. SQL Server is doing its job by keeping that data safe, and that means holding onto log space.

SQL Server will also tell you what the log is waiting on, in sys.databases:

SELECT name, log_reuse_wait_desc, recovery_model_desc
FROM sys.databases
WHERE database_id > 4;

Microsoft's transaction log documentation lists every value of log_reuse_wait_desc and what it means. A few of the common ones:

LOG_BACKUP: a log backup is needed before the log can be truncated (full or bulk-logged recovery only).
ACTIVE_TRANSACTION: a transaction is still open, which is what the demo above shows.
AVAILABILITY_REPLICA: an availability group secondary is still applying log records.
REPLICATION: transactions for replication haven't been delivered to the distribution database yet.
NOTHING: there's reusable space in the log.

Why Regular Shrinking Can Make Things Worse

Shrinking isn't harmless. After a shrink, the log has to grow back, and each growth adds more VLFs. Microsoft's transaction log architecture guide explains how many. Since SQL Server 2014, a growth smaller than one eighth of the current log size adds a single VLF. Larger growths add 4, 8 or 16 VLFs depending on their size, and on SQL Server 2022 a growth of 64 MB or less adds just one. So a log that grows back in many small steps ends up with far more VLFs than one grown back in a single step.

The guide says a high VLF count slows down database recovery during startup, and restores, because SQL Server has to build a list of every VLF first. Its symptoms section describes counts in the range of several hundred thousand, and it suggests keeping the total to "a maximum of several thousand."

Shrinking a data file has a separate cost that the DBCC SHRINKFILE documentation spells out: "A shrink operation doesn't preserve the fragmentation state of indexes in the database, and can increase index fragmentation." That applies to data files rather than the log, but it's one more reason not to treat shrinking as routine maintenance.

Shrinking also hides the real issues: no log backups, inefficient transaction patterns, poor autogrowth settings, or a log undersized for the workload.

How to Actually Manage Your Log File

Here's what works:

Size it right from the start. Look at historical peak usage and give the log enough room for it.
Use fixed autogrowth sizes rather than percentages, so each growth adds a predictable number of VLFs.
Schedule frequent log backups (for full or bulk-logged recovery). This is what lets SQL Server reuse inactive VLFs.
Monitor log space so you know what's going on before reaching for the shrink button.

SQL Server 2022+:

SELECT
    DB_NAME(database_id) AS [Database]
    ,total_log_size_mb = total_log_size_in_bytes / 1048576.0
    ,used_log_space_mb = used_log_space_in_bytes / 1048576.0
    ,percent_used = used_log_space_in_bytes * 100.0 / total_log_size_in_bytes
FROM sys.dm_db_log_space_usage;

Older versions:

DBCC SQLPERF(LOGSPACE);

When It Is Okay to Shrink

Say you just offloaded a massive archive table or ran a one-time migration, and your log grew far beyond what your workload needs. In that case, a one-time shrink is fine. Afterwards, resize the file to something appropriate and let it grow only when it needs to. Microsoft's guide describes the same approach for a log with too many VLFs. Shrink it, grow it back to the size it needs in one step with ALTER DATABASE ... MODIFY FILE, then review the autogrowth settings. It also says to make sure you have a valid, restorable backup before doing any of that.

If you're running scheduled log shrinks in a job, it's time to take a closer look at your backup strategy.

Wrapping Up

If your transaction log is getting too big, it's usually telling you something about your recovery model, your backup frequency, or your workload.

Don't treat DBCC SHRINKFILE like a maintenance task. Treat it like a fire extinguisher. Use it only when you have to, and figure out how to avoid the fire next time.

Migrating Your SSRS ReportServer Database

Wed, 07 May 2025 00:00:00 GMT

import Callout from "@/components/Callout.astro";

Migrating an SSRS ReportServer database is deceptively simple. You copy the .bak file, run RESTORE, and expect everything to work... or so I thought. Without careful handling of encryption keys, logins, and service-account mappings, you can end up with a database that won't decrypt connection strings or throws permission errors in the portal.

Microsoft's migration guide for Reporting Services calls backing up the encryption key "critical to migration success." The report server database holds the reports, shared data sources, subscriptions and schedules, but the stored connection strings and credentials in it are encrypted. Restoring the key on the new server is what makes them usable again.

Export the Encryption Key

Before creating or copying any database backups, export the SSRS encryption key from the source server. In Report Server Configuration Manager, go to Encryption Keys, select Backup, and choose a secure path for the .snk file. Give it a strong password and store both the file and the password somewhere safe.

Back Up the ReportServer Database

With the encryption key saved, take a full backup of the ReportServer database:

BACKUP DATABASE [ReportServer]
  TO DISK = N'D:\Backups\ReportServer_FULL.bak'
  WITH FORMAT, COMPRESSION, STATS = 10;

Verify the backup completes successfully and copy the resulting .bak file to the destination server's backup folder. Also double-check that the destination instance has its own fresh ReportServer backup in case you need to roll back.

There's a second database, ReportServerTempDB. Microsoft's guide says the report server database and the temporary database "are interdependent and must be moved together," and its backup and restore page explains why a backup of it is worth having. You don't need the data in it, but you do need its table structure, and if it's lost, "the only way to get it back is to recreate the report server database." So back up both.

Restore the Database on the Destination

I always switch the ReportServer database into single-user mode to prevent connection conflicts:

USE [master];
ALTER DATABASE [ReportServer] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO

Restore the database, overwriting any existing copy:

RESTORE DATABASE [ReportServer]
  FROM DISK = N'N:\Backups\ReportServer_FULL.bak'
  WITH REPLACE, STATS = 5;
GO

Return the database to multi-user mode:

ALTER DATABASE [ReportServer] SET MULTI_USER;
GO

Right after, check sys.databases or the SQL Server error log to make sure there were no lock or permission errors during the restore.

Reassign Database Owner and Fix Logins

SSRS requires sa as the database owner. Run:

USE [ReportServer];
ALTER AUTHORIZATION ON DATABASE::ReportServer TO sa;
GO

Next, remap any orphaned users whose SIDs no longer match. For example:

EXEC sp_change_users_login 'Auto_Fix', 'YourUser';

Microsoft's documentation for sp_change_users_login marks it as a feature that "will be removed in a future version of SQL Server" and points to ALTER USER instead, so ALTER USER [YourUser] WITH LOGIN = [YourUser] is the longer-lasting way to do the same remap. Either way, check that each database user maps to its server login afterwards.

Recreate the SSRS Service Account User

The SSRS service account (commonly RptSrvc) must exist inside ReportServer and belong to the RSExecRole:

-- 1. Create the service‐account login (if it doesn’t already exist)
CREATE LOGIN [DOMAIN\RptSrvc] FROM WINDOWS;
GO

-- 2. Grant rights in the ReportServer database
USE [ReportServer];
GO
CREATE USER [DOMAIN\RptSrvc] FOR LOGIN [DOMAIN\RptSrvc];
GO
EXEC sp_addrolemember 'RSExecRole', 'DOMAIN\RptSrvc';
GO

-- 3. Grant rights in the ReportServerTempDB database
USE [ReportServerTempDB];
GO
CREATE USER [DOMAIN\RptSrvc] FOR LOGIN [DOMAIN\RptSrvc];
GO
EXEC sp_addrolemember 'db_owner', 'DOMAIN\RptSrvc';
GO

After running this, check that a simple query against an SSRS catalog table (for example SELECT TOP 1 * FROM dbo.Catalog) succeeds under the RptSrvc account.

Restore the Encryption Key on the Destination

Back in Report Server Configuration Manager on the destination server, open Encryption Keys, choose Restore, select the .snk file you exported earlier, and enter the password. Microsoft's guide says this step is "necessary for enabling reversible encryption on preexisting connection strings and credentials that are already in the report server database."

<Callout type="info"> Shared data sources are stored in the report server database, so they come across with the restore, but their saved connection details depend on the key. Microsoft's guide says to "review data source information to see whether the data source connection information is still specified" once the migration is done. Plan to open each shared data source in the new portal and confirm its connection string and credentials before relying on the reports that use it. </Callout>

Validate the Web Portal

Finally, open your SSRS web portal in a browser, go through several folders, and render a few reports. If you get a 404, an authentication failure, or a rendering error, check the SSRS service log (ReportServerService__*.log) for clues, whether it's database connectivity, decryption, or URL binding, and fix the underlying issue before testing again.

Conclusion

Export and restore the encryption key, back up and move both databases, fix ownership and logins, recreate the service-account user, and then check the data sources. In that order, most of the usual surprises go away. I'll eventually wrap these steps into a PowerShell module, but for now the process is straightforward enough and doesn't take that long.

How to Install SQL Server 2022 on MacOS

Tue, 29 Apr 2025 00:00:00 GMT

Microsoft is pretty upfront about the fact that SQL Server doesn't run natively on macOS. Back in college, I learned this the hard way. I bought a Windows license, spun up a VirtualBox VM on my 8GB MacBook Pro, and limped my way through installing SQL Server 2016 for a database class. It was miserable.

If only 2015 Chandler knew about Docker.

What is Docker?

If you've used virtual machines, think of containers as a leaner, more efficient alternative. Instead of virtualizing hardware and running a full operating system for every instance, containers share the host system's kernel and isolate the app at the process level. In our case, it's SQL Server in a pre-packaged box. Docker runs on Windows, Linux, and macOS.

Installing Docker

Macs come in two flavors: Intel and Apple Silicon. Docker Desktop supports both, but the setup steps differ slightly. Follow the official Docker Desktop install guide and make sure to pick the version that matches your Mac.

After installing, open Docker Desktop.

The difference between the two kinds of Mac matters for SQL Server too. Microsoft's container quickstart says the SQL Server images "are supported only on Linux hosts running on Intel and AMD x86-64 CPUs," and that "emulation or translation environments (for example, Rosetta 2, Prism, or QEMU) aren't tested or supported." On an Apple Silicon Mac, the container runs under emulation, which is outside what Microsoft supports. That's fine for learning and local testing, but if something strange happens, there's no support path for it.

The same page lists at least 2 GB of RAM and 2 GB of disk space as prerequisites, so check how much memory Docker Desktop is allowed to use if the container has trouble staying up.

Install SQL Server

Actually deploying SQL Server is easy, and it's the reason this is worth doing over a VM. Open Terminal and check that Docker is working:

docker version

If that fails with -bash: docker: command not found, Docker may not be in your system's PATH. I fixed this with:

sudo ln -s /Applications/Docker.app/Contents/Resources/bin/docker /usr/local/bin/docker

If docker version still doesn't work, search for the error you're getting. Once it does, pull the SQL Server 2022 image:

docker pull mcr.microsoft.com/mssql/server:2022-latest

Once that completes, start the container. Change the password before running it:

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
   -p 1433:1433 --name sql1 --hostname sql1 \
   -d \
   mcr.microsoft.com/mssql/server:2022-latest

This shouldn't take long. When it's done, you have SQL Server 2022 running on your local machine on port 1433.

The password has to follow SQL Server's default password policy. Microsoft's quickstart says that means at least eight characters, drawn from three of these four sets: uppercase letters, lowercase letters, digits, and symbols. If the password doesn't meet that, the page says "the container can't set up SQL Server, and stops working." docker logs sql1 shows the error log so you can see why.

The image tags on Docker Hub now include 2025-latest alongside 2022-latest, 2019-latest and 2017-latest. To run a different version, swap the tag in both commands.

What now?

This setup isn't meant for production, but it's great for local testing, development, and learning. If you want to go further, these are good places to start:

That's SQL Server on a Mac without a VM, which would have saved 2015 me 4GB of RAM.

How to Analyze Wait Stats in SQL Server 2022

Mon, 28 Apr 2025 00:00:00 GMT

import Callout from "@/components/Callout.astro";

<Callout type="warning"> This query is written for SQL Server 2022. It should work on other versions, but it'll likely miss some wait types that don't exist in 2022. </Callout>

A look at wait stats can show where a server is struggling. SQL Server isn't what I would call "good" at describing its problems, and it doesn't fix them on its own, so the waits are one of the better places to start.

sys.dm_os_wait_stats returns a row for every wait type, and there are a lot of them. The wait types table in Microsoft's <a href="https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-os-wait-stats-transact-sql" target="_blank" rel="noopener noreferrer">documentation for the view</a> had 953 entries as of September 2026. I don't want to memorize them, so I wanted something that filtered out the noise for me. The query below groups the ones I care about into a handful of categories and drops the rest.

Before reading any of it, check how far back the numbers go. The same page says the statistics "aren't persisted after the database engine restarts," and that everything is cumulative since the last restart or the last time someone cleared them. sqlserver_start_time in sys.dm_os_sys_info gives you the restart time, so you know whether you're looking at a day of history or a year of it.

If you've just inherited a server and need to understand its history, keep the existing wait statistics intact. Only clear the old data when you're troubleshooting a live incident and need a fresh baseline. For those live investigations, run:

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);
GO

The Script

The script below puts each wait into one of five categories: CPU, Memory, Database Blocking, I/O or Tempdb Contention. It filters out the noise, then uses a single GROUPING SETS query to return both the detailed rows and a total per category in one pass.

-- Wait types by category.
WITH WaitCategories AS (
    SELECT
        wait_type,
        wait_time_ms,
        signal_wait_time_ms,
        waiting_tasks_count,
        CASE 
            -- Benign Wait Types
            WHEN wait_type IN (
                'BROKER_EVENTHANDLER', 'BROKER_RECEIVE_WAITFOR', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH',
                'BROKER_TRANSMITTER', 'CHECKPOINT_QUEUE', 'CHKPT', 'CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT',
                'CLR_SEMAPHORE', 'DBMIRROR_DBM_EVENT', 'DBMIRROR_EVENTS_QUEUE', 'DBMIRROR_WORKER_QUEUE',
                'DBMIRRORING_CMD', 'DIRTY_PAGE_POLL', 'DISPATCHER_QUEUE_SEMAPHORE', 'EXECSYNC', 'FSAGENT',
                'FT_IFTS_SCHEDULER_IDLE_WAIT', 'FT_IFTSHC_MUTEX', 'HADR_CLUSAPI_CALL',
                'HADR_FILESTREAM_IOMGR_IOCOMPLETION', 'HADR_LOGCAPTURE_WAIT', 'HADR_NOTIFICATION_DEQUEUE',
                'HADR_TIMER_TASK', 'HADR_WORK_QUEUE', 'KSOURCE_WAKEUP', 'LAZYWRITER_SLEEP', 'LOGMGR_QUEUE',
                'MEMORY_ALLOCATION_EXT', 'ONDEMAND_TASK_QUEUE', 'PARALLEL_REDO_DRAIN_WORKER',
                'PARALLEL_REDO_LOG_CACHE', 'PARALLEL_REDO_TRAN_LIST', 'PARALLEL_REDO_WORKER_SYNC',
                'PARALLEL_REDO_WORKER_WAIT_WORK', 'PREEMPTIVE_HADR_LEASE_MECHANISM',
                'PREEMPTIVE_SP_SERVER_DIAGNOSTICS', 'PREEMPTIVE_OS_LIBRARYOPS', 'PREEMPTIVE_OS_COMOPS',
                'PREEMPTIVE_OS_CRYPTOPS', 'PREEMPTIVE_OS_PIPEOPS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS',
                'PREEMPTIVE_OS_GENERICOPS', 'PREEMPTIVE_OS_VERIFYTRUST', 'PREEMPTIVE_OS_DELETESECURITYCONTEXT',
                'PREEMPTIVE_OS_REPORTEVENT', 'PREEMPTIVE_OS_FILEOPS', 'PREEMPTIVE_OS_DEVICEOPS',
                'PREEMPTIVE_OS_QUERYREGISTRY', 'PREEMPTIVE_OS_WRITEFILE', 'PREEMPTIVE_OS_WRITEFILEGATHER',
                'PREEMPTIVE_XE_CALLBACKEXECUTE', 'PREEMPTIVE_XE_DISPATCHER', 'PREEMPTIVE_XE_GETTARGETSTATE',
                'PREEMPTIVE_XE_SESSIONCOMMIT', 'PREEMPTIVE_XE_TARGETINIT', 'PREEMPTIVE_XE_TARGETFINALIZE',
                'POPULATE_LOCK_ORDINALS', 'PWAIT_ALL_COMPONENTS_INITIALIZED',
                'PWAIT_DIRECTLOGCONSUMER_GETNEXT', 'PWAIT_EXTENSIBILITY_CLEANUP_TASK',
                'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP', 'QDS_ASYNC_QUEUE',
                'QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP', 'REQUEST_FOR_DEADLOCK_SEARCH',
                'RESOURCE_QUEUE', 'SERVER_IDLE_CHECK', 'SLEEP_BPOOL_FLUSH', 'SLEEP_DBSTARTUP',
                'SLEEP_DCOMSTARTUP', 'SLEEP_MASTERDBREADY', 'SLEEP_MASTERMDREADY', 'SLEEP_MASTERUPGRADED',
                'SLEEP_MSDBSTARTUP', 'SLEEP_SYSTEMTASK', 'SLEEP_TASK', 'SLEEP_TEMPDBSTARTUP',
                'SNI_HTTP_ACCEPT', 'SOS_WORK_DISPATCHER', 'SP_SERVER_DIAGNOSTICS_SLEEP',
                'SOS_WORKER_MIGRATION', 'VDI_CLIENT_OTHER', 'SQLTRACE_BUFFER_FLUSH',
                'SQLTRACE_INCREMENTAL_FLUSH_SLEEP', 'SQLTRACE_WAIT_ENTRIES', 'STARTUP_DEPENDENCY_MANAGER',
                'TRACEWRITE', 'WAIT_FOR_RESULTS', 'WAITFOR', 'WAITFOR_TASKSHUTDOWN', 'WAIT_XTP_HOST_WAIT',
                'WAIT_XTP_OFFLINE_CKPT_NEW_LOG', 'WAIT_XTP_CKPT_CLOSE', 'WAIT_XTP_RECOVERY',
                'XE_BUFFERMGR_ALLPROCESSED_EVENT', 'XE_DISPATCHER_JOIN', 'XE_DISPATCHER_WAIT',
                'XE_LIVE_TARGET_TVF', 'XE_TIMER_EVENT')
                THEN 'Benign'
            -- CPU Wait Types
            WHEN wait_type IN (
                'CXPACKET', 'CXCONSUMER', 'SOS_SCHEDULER_YIELD', 'THREADPOOL')
                THEN 'CPU'
            -- Memory Wait Types
            WHEN wait_type IN (
                'MEMORY_GRANT_UPDATE', 'RESOURCE_SEMAPHORE', 'RESOURCE_SEMAPHORE_QUERY_COMPILE')
                THEN 'Memory'
            -- Database Blocking Wait Types
            WHEN wait_type LIKE 'LCK_M_%' THEN 'Database Blocking'
            -- I/O Wait Types
            WHEN wait_type IN (
                'WRITELOG', 'BACKUPIO', 'ASYNC_IO_COMPLETION', 'PAGEIOLATCH_SH',
                'PAGEIOLATCH_UP', 'PAGEIOLATCH_EX', 'IO_COMPLETION', 'WRITE_COMPLETION', 'LOGBUFFER',
                'LOGMGR', 'LOGMGR_RESERVE_APPEND', 'DISKIO_SUSPEND')
                THEN 'I/O'
            -- Tempdb Contention Wait Types
            WHEN wait_type IN (
                'PAGELATCH_EX', 'LATCH_EX', 'PAGELATCH_SH', 'LATCH_SH', 'PAGELATCH_UP')
                THEN 'Tempdb Contention'
            -- Other Wait Types
            ELSE 'Other'
        END AS WaitCategory
    FROM sys.dm_os_wait_stats
)
-- Combine detailed and aggregated results using GROUPING SETS
SELECT
    CASE
        WHEN GROUPING(wait_type) = 0 THEN 'Detailed'
        ELSE 'Aggregated'
    END AS ResultType,
    WaitCategory,
    wait_type,
    SUM(wait_time_ms) AS wait_time_ms,
    SUM(signal_wait_time_ms) AS signal_wait_time_ms,
    SUM(waiting_tasks_count) AS waiting_tasks_count
FROM WaitCategories
WHERE 1=1
    AND WaitCategory NOT IN ('Benign', 'Other') -- Exclude 'Benign' and 'Other' categories
    AND waiting_tasks_count > 0
GROUP BY
    GROUPING SETS (
        (WaitCategory, wait_type), -- Detailed results
        (WaitCategory)             -- Aggregated results
    )
ORDER BY
    CASE
        WHEN GROUPING(wait_type) = 1 THEN 1 -- Place aggregated results at the bottom
        ELSE 0
    END,
    wait_time_ms DESC;

How to Read the Results

Rows labeled Detailed show each wait type the query tracks, and rows labeled Aggregated total each category. The detailed rows are for drilling in, and the aggregates at the bottom give a high-level view of where SQL Server is spending most of its time.

Don't fixate on the single top wait type. A category made up of several smaller waits can add up to more than the one wait at the top of the list, so compare the category totals and not just the peaks.

The filter at the end of the query drops two categories. Benign is the list of waits that are safe to ignore, and I got that list from query 42 in Glenn Berry's DMVs. Other is everything that isn't in one of my categories, which means a wait type the query doesn't know about won't show up at all. If a server looks fine by this query and clearly isn't, changing AND WaitCategory NOT IN ('Benign', 'Other') to AND WaitCategory <> 'Benign' shows what's been hiding in Other.

The categories are my own, and the Tempdb Contention label is the loosest of them. PAGELATCH_EX waits happen in tempdb, but they also happen in user databases when many sessions insert rows at the end of an index on a sequential column, like an identity. Microsoft's article on <a href="https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/performance/resolve-pagelatch-ex-contention" target="_blank" rel="noopener noreferrer">resolving PAGELATCH_EX contention</a> covers that case, which it calls last-page insert contention. It also gives a way to tell the two apart. The wait_resource for a waiting session starts with the database ID, and an ID of 5 or higher is a user database, while 2 is tempdb. So if this query points at Tempdb Contention, check that before adding tempdb files.

How to Configure and Tune MAXDOP

Sun, 27 Apr 2025 00:00:00 GMT

When I first started learning SQL Server administration, I read a lot of articles on configuring Max Degree of Parallelism (MAXDOP). Most of them described it as a limit on how many processors a query can use. Microsoft's documentation is more specific. The limit applies per task, and it "isn't a per request or per query limit." A single parallel request can start several tasks, each using one worker and one scheduler, so a plan with more than one parallel branch can have more workers running than the number you set.

A setting of 0 lets SQL Server use all available processors, up to 64, and the same page says that "isn't the recommended value for most cases." A setting of 1 stops SQL Server from generating parallel plans. Any value from 1 to 32,767 sets the limit, and if it's higher than the number of processors available, SQL Server uses the number available.

How to set MAXDOP

There are a lot of conflicting blog posts about how to set MAXDOP, so I fall back to Microsoft's recommendation. It isn't right for every server, but sometimes it fits as-is. These are Microsoft's current recommendations for SQL Server 2016 and newer:

Server configuration	Number of processors	Guidance
Server with single NUMA node	Less than or equal to eight logical processors	Keep MAXDOP at or under the number of logical processors
Server with single NUMA node	Greater than eight logical processors	Keep MAXDOP at 8
Server with multiple NUMA nodes	Less than or equal to 16 logical processors per NUMA node	Keep MAXDOP at or under the number of logical processors per NUMA node
Server with multiple NUMA nodes	Greater than 16 logical processors per NUMA node	Keep MAXDOP at half the number of logical processors per NUMA node, with a maximum value of 16

The NUMA nodes in that table are the soft-NUMA nodes SQL Server creates on its own when it detects more than eight physical cores per NUMA node or socket, or the hardware NUMA nodes if soft-NUMA is turned off. The page says the recommendations are aimed at keeping all the worker threads of a parallel query inside one of those nodes.

To make this simpler, I rewrote the table as a T-SQL script that gives me the recommendation without working it out by hand:

DECLARE @maxdop INT
	,@cpu_count INT
	,@numa_count INT
	,@cpu_per_node INT
	,@recommended INT;

SELECT @maxdop = CONVERT(INT, value_in_use)
FROM sys.configurations
WHERE name = 'max degree of parallelism';

SELECT @cpu_count = cpu_count
	,@numa_count = numa_node_count
FROM sys.dm_os_sys_info;

IF @numa_count = 1
BEGIN
	IF @cpu_count <= 8
		SET @recommended = @cpu_count;
	ELSE
		SET @recommended = 8;
END
ELSE
BEGIN
	SET @cpu_per_node = @cpu_count / @numa_count;

	IF @cpu_per_node <= 16
		SET @recommended = @cpu_per_node;
	ELSE
		SET @recommended = CASE 
				WHEN (@cpu_per_node / 2) > 16
					THEN 16
				ELSE (@cpu_per_node / 2)
				END;
END

SELECT @maxdop AS Current_MAXDOP
	,@recommended AS Recommended_MAXDOP
	,CASE 
		WHEN @maxdop = @recommended
			THEN 'Pass'
		ELSE 'Fail'
		END AS MAXDOP_Status;

The script divides cpu_count by numa_node_count from sys.dm_os_sys_info. The <a href="https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-os-sys-info-transact-sql" target="_blank" rel="noopener noreferrer">documentation for that view</a> says numa_node_count "includes physical NUMA nodes and soft NUMA nodes," which matches what the table is counting. The column exists from SQL Server 2016 SP2 onward, so the script won't run on anything older.

The results show the current value, the recommended one, and whether they match. To make the change, put the recommended value into this:

USE master;
GO
EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO

EXEC sp_configure 'max degree of parallelism', 8; -- <-- Set your recommended value here.
GO
RECONFIGURE WITH OVERRIDE;
GO

EXEC sp_configure 'show advanced options', 0;
GO
RECONFIGURE;
GO

How to Monitor MAXDOP

This is where things can get messy if you overthink them. Changing MAXDOP will change query performance, so I measure both the slowest query I have and a reasonably fast one first. Then I set MAXDOP to Microsoft's recommendation and keep an eye on overall performance over the next few hours, days and weeks.

If queries get slower, check the query plan. MAXDOP is likely too high if queries that used to run fast on a single thread are now using more threads without running any faster, or are waiting longer to start. If it's too low, you'll see the opposite, with queries stuck on one thread doing work that could have been split up. Don't be afraid to adjust it as you learn more about the server.

The cost threshold for parallelism is worth looking at alongside it. MAXDOP limits how wide a parallel plan can go, and the cost threshold decides whether SQL Server considers a parallel plan at all. The cost threshold documentation says the default of 5 "is a starting point, not a recommendation," and that raising it can keep smaller OLTP queries on serial plans. It suggests changing it in small increments and watching a full business cycle between changes. The same page has a short table of symptoms. When the threshold is too low, too many light queries go parallel and CXPACKET and CXCONSUMER dominate the wait stats. When it's too high, CPU-heavy queries that should go parallel don't, and SOS_SCHEDULER_YIELD dominates instead.

One detail on that page is easy to miss. A query can still get a parallel plan when its cost is below the threshold, because the decision is made from a cost estimate taken earlier in optimization than the final plan cost you see. So a cheap query running in parallel isn't proof the threshold is set wrong.

Using Query OPTION (MAXDOP n)

Some DBAs, or a sly developer, might use the OPTION (MAXDOP n) query hint to force a specific degree of parallelism on a specific query. In most cases this isn't a recommended practice, and it's best suited to measuring and troubleshooting performance at different settings. You can use it in production. Here's an example of the hint:

SELECT column1, column2
FROM VeryLargeTable
OPTION (MAXDOP 4);

Setting MAXDOP at the database level probably won't be the right choice for every query, so the query level may be the only way to satisfy stakeholders. Keep track of the queries using this hint and use it sparingly. If the server ever changes, it's easier to change the setting once than to find every query with a hint and remeasure it.

The query hint is one of three ways to override the server setting. The MAXDOP documentation lists the query level (the hint, or a Query Store hint), the database level through a database scoped configuration, and the workload level through a Resource Governor workload group. When a query's parallelism doesn't match the server setting, one of those is usually the reason.

Two newer features can also explain a value you didn't set yourself. Starting with SQL Server 2019, setup recommends a MAXDOP value during installation based on the processors it finds, so a newer install may already match the table. SQL Server 2022 added degree of parallelism (DOP) feedback, which adjusts parallelism for repeating queries based on their elapsed time and waits.

No two shops are the same. Follow the Microsoft recommendation until it no longer works for you, and keep measuring after the change so that problems show up before the 2:00 AM wake-up calls do.

Optimizing SQL Server Backup Transfers with Robocopy

Tue, 22 Apr 2025 00:00:00 GMT

This morning I stared at a 30 GB SQL Server backup and a VPN that managed about 1 MB/s and dropped every 45 to 60 minutes. I thought, "If I split this into thirty 1 GB pieces and copy them in parallel, maybe I can outrun the disconnects." Later that morning I ran a quick PowerShell script to slice the .bak into 30 parts, which took just a couple of minutes.

I tested transfer times next. At around 1 MB/s, each slice copied in roughly 15 to 17 minutes. In a typical VPN window I could finish two slices and start another before the link dropped. When the VPN hiccuped, I lost at most one gigabyte instead of dozens, but the overall transfer time stayed the same. Moving 30 GB at 1 MB/s still takes about eight hours, plus a few extra minutes for splitting and retries. I had smaller failure domains, but no net time savings.

By midday I was frustrated and decided to tune Robocopy's parallelism. I wrote a simple harness to copy the first handful of slices with different /MT thread counts and measured each run:

$sourceDir   = '\\server\share'
$destDir     = 'D:\migrations'
$filePattern = 'large.bak.part00[1-5]'
$mtOptions   = 2,4,8,16,32
$results     = @{}

foreach ($mt in $mtOptions) {
    $start = Get-Date
    robocopy $sourceDir $destDir $filePattern /Z /MT:$mt /R:1 /W:1 | Out-Null
    $results[$mt] = (Get-Date) - $start
}

$bestMt = ($results.GetEnumerator() |
           Sort-Object Value.TotalSeconds |
           Select-Object -First 1).Key

Write-Host "Best MT value is" $bestMt

That test took on the order of half an hour, and /MT:8 came out on top. It's worth knowing that 8 is also Robocopy's default. The robocopy documentation says /mt accepts a value "between 1 and 128" and that "the default value for n is 8." The test also ran over the same link that dropped every 45 to 60 minutes, so a run that happened to hit a disconnect would look slower than it really was.

With that, I launched the full copy:

robocopy \\server\share D:\migrations large.bak.part* /Z /MT:8 /R:3 /W:5

The /R:3 /W:5 on that command matter more than they look. The same page lists Robocopy's defaults as 1,000,000 retries with a 30-second wait between each, so on an unreliable link it's worth setting both yourself. The page also lists a /compress switch that "requests network compression during file transfer, if applicable," which could be worth testing when bandwidth is the limit.

Next, to avoid a single long list of files, I ran three Robocopy sessions in parallel, each handling a batch of slices:

$parts  = Get-ChildItem '\\server\share\large.bak.part*' | Sort-Object Name
$groups = @(
    $parts[0..9],
    $parts[10..19],
    $parts[20..29]
)

foreach ($batch in $groups) {
    $fileArgs = $batch.Name -join ' '
    Start-Process robocopy -ArgumentList '\\server\share', 'D:\migrations', $fileArgs, '/Z', '/MT:8', '/R:3', '/W:5' -NoNewWindow
}

I let those jobs run unattended into the afternoon and evening, and by the end of the day all 30 parts had arrived successfully.

Finally, to rebuild the original .bak file once all the parts have transferred, you can stitch them back together with a PowerShell loop in your migration folder:

$parts  = Get-ChildItem 'D:\migrations\large.bak.part*' | Sort-Object Name
$out    = 'D:\migrations\restored-large.bak'
if (Test-Path $out) { Remove-Item $out }
foreach ($part in $parts) {
    Get-Content $part -Encoding Byte -ReadCount 0 | Add-Content $out -Encoding Byte
}

This reads each slice in order and writes it into restored-large.bak. After that, you can point RESTORE DATABASE at restored-large.bak.

That loop only works in Windows PowerShell 5.1. Microsoft's Get-Content documentation says the -AsByteStream parameter "was introduced in Windows PowerShell 6.0," and Byte is no longer one of the -Encoding values. On PowerShell 7, use Get-Content $part -AsByteStream -ReadCount 0 | Add-Content $out -AsByteStream. The -ReadCount 0 matters in either version. The default of 1 "reads one byte in each read operation and converts each byte into a separate object," which on a 30 GB file is billions of objects.

Or, from a classic CMD prompt, run:

copy /b large.bak.part* restored-large.bak

Either method stitches the chunks back into the original backup file, ready to restore. Before you run the restore, check that the reassembled file is the same size as the original, and run RESTORE VERIFYONLY against it.

Today I learned that chopping a large file into pieces rarely speeds up the total transfer, because the bandwidth doesn't change. What splitting does give you is a smaller failure domain, so a dropped VPN costs one gigabyte instead of everything. Pair that with Robocopy's restartable mode (/Z) and sensible retry settings, and you have a straightforward, resilient workflow. When your VPN inevitably drops, you'll be glad you let a tested tool handle the resume logic for you.

Querying Dates in SQL Server for Performance

Tue, 31 Dec 2024 00:00:00 GMT

Query tuning is often more than speed. It's also about understanding how SQL Server processes data and which patterns give the right results. I tested how six different ways of filtering dates affect performance, using SET STATISTICS IO ON and SET STATISTICS TIME ON.

Setup

I set myself the task of retrieving user activity from the Users table in the StackOverflow database for the year 2017, since the copy I have only has data up through 2018. The table has millions of rows, so I thought it would make a good example. There's a nonclustered index covering this query, which I've scripted below. LastAccessDate is a datetime column.

USE [StackOverflow]
GO

SET ANSI_PADDING ON
GO

CREATE NONCLUSTERED INDEX [IX_LastAccessDate_DisplayName_Reputation] ON [dbo].[Users]
(
	[LastAccessDate] ASC,
	[DisplayName] ASC,
	[Reputation] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 100, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
GO

Here are the six approaches I tested, along with my results.

1. BETWEEN with precise timestamps. This is probably the most common method I see in the wild.

2. >= and <, again with precise timestamps. This one is also fairly common.

Nothing unusual so far. Both queries returned 1,923,109 rows with 11,167 logical reads, ran fast enough for my needs, and gave me the data I expected. Let's keep going.

3. BETWEEN again, but with plain dates instead of timestamps. I wanted to see whether the less precise date format would make the query non-sargable, meaning unable to use the index to seek.

There's no real change in speed or reads, but if you look closely, it returned 1,920,209 rows, which is 2,900 fewer than the first two queries. More on that below.

4. The same idea with >= and <. Nothing significant to report. It returned the same 1,923,109 rows with the same 11,167 reads as the first two.

5. BETWEEN again, but converting the datetime column to a VARCHAR to change the date format.

6. The same VARCHAR conversion as step 5, with >= and <.

Both CONVERT versions returned the full 1,923,109 rows, but logical reads went from about 11,000 to about 53,000, and CPU time went from about 15 seconds to about 41 seconds. They also show a scan count of 9 instead of 1.

About those missing rows

Query 3 is the one worth going back to. BETWEEN includes both ends of the range, but on a datetime column, '2017-12-31' means midnight at the start of December 31st. Microsoft's BETWEEN documentation has an example of exactly this. When the time part isn't specified, "it defaults to 12:00 A.M.," so any row later than that on the last day falls outside the range. That's where the 2,900 rows went, and the query gave no sign that anything was missing.

Query 1 has a subtler version of the same problem. datetime values are rounded to increments of .000, .003 or .007 seconds, and Microsoft's datetime documentation shows '23:59:59.999' being stored as 00:00:00.000 on the following day. So BETWEEN '2017-01-01 00:00:00.000' AND '2017-12-31 23:59:59.999' actually ends at midnight on January 1st, 2018, and would include any row stamped exactly at that moment. It returned the same count as query 2 here, so there weren't any in this data, but the range isn't what it looks like.

>= '2017-01-01' AND < '2018-01-01' avoids both problems. It also keeps working on a datetime2 column, which is accurate to 100 nanoseconds, where an end value like 23:59:59.997 would leave out anything in the last few fractions of a second.

Final Thoughts

Logical reads went up almost five-fold with CONVERT. Wrapping the column in a function means SQL Server has to convert every row's value before it can compare it, so it can't seek on the index. Microsoft's index design guide defines a sargable predicate as "a Search ARGumentable predicate that can use an index to speed up the execution of the query," and the jump in reads here is what losing that looks like.

On the sargable versions, BETWEEN and >=/< performed about the same, so the reason to prefer >= and < is the boundary rather than speed. I'll be avoiding CONVERT on my datetime columns, and BETWEEN on anything with a time component.

Using PowerShell to Automate Glenn Berry's SQL DMV Queries

Sun, 22 Sep 2024 00:00:00 GMT

I find myself using Glenn Berry's SQL Server DMV queries more than any other performance tuning or diagnostic tool. Because I run them so often, I needed a way to quickly connect to a server, collect the data, and move on until I have time to review it properly. In my role, speed and accuracy are important, so any chance I get to automate something, I take it.

Glenn Berry's scripts are already well documented, and I recommend running them manually to understand what each one is telling you. I wanted to streamline the process further, so I wrote a PowerShell script that runs the diagnostic queries for me and saves the results to review later. It's also useful when troubleshooting an issue in real time.

What Is dbatools?

The script is built on dbatools, the PowerShell module that comes up in most of my automation posts. The dbatools documentation and GitHub repository are the places to start, and I have a short post on installing it.

The Script

Most of the real work is done by Invoke-DbaDiagnosticQuery in dbatools, which the command's documentation credits to Andre Kamman. The same page says the most recent version of Glenn Berry's queries is included in the dbatools module, so there's nothing separate to download. My script is a wrapper around it that connects to a SQL Server instance, runs the instance-level queries and optionally the database-specific ones, exports the results to CSV files, and compiles them into a single Excel workbook.

Accessing the Script

The script is available on my GitHub repository. If I change anything, that's where the update will be.

Prerequisites

PowerShell Execution Policy: Your execution policy has to allow scripts to run. Get-ExecutionPolicy shows the current one, and the dbatools install post has the setting I use.

Required Modules: The script will try to install dbatools and ImportExcel on its own, but it's good practice to install them manually first to avoid any potential issues.

Install-Module -Name dbatools -Scope CurrentUser
Install-Module -Name ImportExcel -Scope CurrentUser

How to Use the Script

Running it is mostly a matter of answering prompts:

Download the Script:
- Visit the GitHub repository
- Download the script to a local directory. It's stored in the repository as Glenn Berry's DMV's using PowerShell.ps1, and the examples below use the name from the script's own help text, Export-SQLDiagnosticData.ps1, so rename it or adjust the commands.
Run the Script:
- Open PowerShell.
- Navigate to the directory containing the script.
- Execute the script:

.\Export-SQLDiagnosticData.ps1

Respond to Prompts:
- SQL Server Name: Enter the name of the SQL Server instance you wish to connect to. If you press Enter without typing anything, it defaults to localhost.
- Export Path: Specify the root directory where you want the export files to be saved. The default is C:\Users\YourUsername\Documents\SQLDiagnosticData.
- Authentication Method:
  - Type 1 for Windows Authentication or 2 for SQL Server Authentication.
  - If you choose SQL Server Authentication, you'll be prompted to enter your SQL Server credentials.
- Run Database-Specific Queries: Type Y to run database-specific diagnostic queries or N to skip. The default is N.
  - If you select Y, a list of databases on the server will be displayed.
  - Enter the numbers corresponding to the databases you want to analyze, separated by commas (for example 1,3,5).
Wait for Completion:
- The script will connect to the SQL Server instance, execute the diagnostic queries, export the results to CSV files, and merge them into an Excel workbook.
- Progress and any relevant messages will be displayed in the console.
Review the Results:
- Navigate to the export path you specified.
- Open the SQLDiagnostics.xlsx file to review the collected data.

Pro Tip

You can skip most of the prompts by passing the answers as parameters:

.\Export-SQLDiagnosticData.ps1 -SqlInstance "YourServerName" -ExportRootPath "C:\Your\Export\Path" -RunDatabaseQueries -DatabaseNames "DB1","DB2"

One thing to keep in mind when reading the results is that many of these DMVs, including wait stats and index usage, are cumulative since the last restart. So a single run shows everything since the server started rather than what it's doing right now.

As always, I'd love to hear feedback on this script. If you have suggestions for making it better, leave a comment and I'll try to add them.

Identifying and Removing Duplicate Indexes in SQL Server

Fri, 13 Sep 2024 00:00:00 GMT

In an earlier post, I mentioned I was looking for ways to simplify my performance tuning. One of the approaches I've taken is finding exact duplicate indexes. Duplicate indexes are a problem because any time you insert, update, or delete a row in that table, SQL Server has to update the same index more than once. I don't like doing the same task twice, so I don't want SQL Server to have to do it either.

Why Duplicate Indexes Are Problematic

For this post, a duplicate is an index with the same key columns, in the same order and sort direction, and the same included columns as another index on the same table. That's the definition the query below uses.

Issues caused by duplicate indexes include:

Storage: Each index takes disk space, so a duplicate is space you don't need.
Slower writes: Every INSERT, UPDATE, and DELETE has to maintain both copies.
Longer maintenance: Index rebuilds and statistics updates have one more index to work through.

The Script

This is the query I use to find exact duplicate indexes in a database. Running it is straightforward, and I've broken it into parts below for anyone who wants to see how it works.

;WITH CTE_IndexData
AS (
	SELECT s.name AS SchemaName
		,t.name AS TableName
		,i.name AS IndexName
		-- Key columns of the index
		,STUFF((
				SELECT ', ' + c.name + ' ' + CASE 
						WHEN ic.is_descending_key = 1
							THEN 'DESC'
						ELSE 'ASC'
						END
				FROM sys.index_columns ic
				INNER JOIN sys.columns c ON ic.object_id = c.object_id
					AND ic.column_id = c.column_id
				WHERE ic.object_id = i.object_id
					AND ic.index_id = i.index_id
					AND ic.is_included_column = 0
				ORDER BY ic.key_ordinal
				FOR XML PATH('')
					,TYPE
				).value('.', 'NVARCHAR(MAX)'), 1, 2, '') AS KeyColumnList
		-- Included columns of the index
		,STUFF((
				SELECT ', ' + c.name
				FROM sys.index_columns ic
				INNER JOIN sys.columns c ON ic.object_id = c.object_id
					AND ic.column_id = c.column_id
				WHERE ic.object_id = i.object_id
					AND ic.index_id = i.index_id
					AND ic.is_included_column = 1
				ORDER BY ic.key_ordinal
				FOR XML PATH('')
					,TYPE
				).value('.', 'NVARCHAR(MAX)'), 1, 2, '') AS IncludeColumnList
		,i.is_disabled
		-- Generate the DROP INDEX statement
		,'DROP INDEX [' + i.name + '] ON [' + s.name + '].[' + t.name + ']' AS DropIndexStatement
	FROM sys.indexes i
	INNER JOIN sys.tables t ON i.object_id = t.object_id
	INNER JOIN sys.schemas s ON t.schema_id = s.schema_id
	WHERE t.is_ms_shipped = 0
		AND i.type_desc IN (
			'NONCLUSTERED'
			,'CLUSTERED'
			)
	)
SELECT d1.SchemaName
	,d1.TableName
	,d1.IndexName
	,d1.KeyColumnList
	,d1.IncludeColumnList
	,d1.is_disabled
	,d1.DropIndexStatement
FROM CTE_IndexData d1
WHERE EXISTS (
		SELECT 1
		FROM CTE_IndexData d2
		WHERE d1.SchemaName = d2.SchemaName
			AND d1.TableName = d2.TableName
			AND d1.KeyColumnList = d2.KeyColumnList
			AND ISNULL(d1.IncludeColumnList, '') = ISNULL(d2.IncludeColumnList, '')
			AND d1.IndexName <> d2.IndexName
		)
ORDER BY d1.SchemaName
	,d1.TableName
	,d1.KeyColumnList;

How It Works

Gathering Basic Index Information

First, I use a Common Table Expression (CTE) called CTE_IndexData to gather some basic information about the indexes that already exist:

SELECT s.name AS SchemaName
    ,t.name AS TableName
    ,i.name AS IndexNam

Retrieve Key Columns

Next, I create a comma-separated list of the key columns for each index, including the sort order (ASC/DESC). A subquery concatenates the column names and sort orders into a single string using the FOR XML PATH('') trick, and STUFF removes the leading comma and space.

,STUFF((
    SELECT ', ' + c.name + ' ' + CASE 
            WHEN ic.is_descending_key = 1
                THEN 'DESC'
            ELSE 'ASC'
            END
    FROM sys.index_columns ic
    INNER JOIN sys.columns c ON ic.object_id = c.object_id
        AND ic.column_id = c.column_id
    WHERE ic.object_id = i.object_id
        AND ic.index_id = i.index_id
        AND ic.is_included_column = 0
    ORDER BY ic.key_ordinal
    FOR XML PATH('')
        ,TYPE
    ).value('.', 'NVARCHAR(MAX)'), 1, 2, '') AS KeyColumnList

Retrieve Included Columns

This creates a comma-separated list of included columns for each index. This works similarly to the key columns retrieval but filters on is_included_column = 1.

,STUFF((
    SELECT ', ' + c.name
    FROM sys.index_columns ic
    INNER JOIN sys.columns c ON ic.object_id = c.object_id
        AND ic.column_id = c.column_id
    WHERE ic.object_id = i.object_id
        AND ic.index_id = i.index_id
        AND ic.is_included_column = 1
    ORDER BY ic.key_ordinal
    FOR XML PATH('')
        ,TYPE
    ).value('.', 'NVARCHAR(MAX)'), 1, 2, '') AS IncludeColumnList

Drop Index Statement

This part is just to script out the DROP INDEX statement. It has nothing to do with finding duplicates. It was just a "nice to have."

,i.is_disabled
,'DROP INDEX [' + i.name + '] ON [' + s.name + '].[' + t.name + ']' AS DropIndexStatement

Find the Duplicates in my Results

Lastly, the main query finds the duplicates by comparing key and included columns. It joins the CTE_IndexData to itself, as d1 and d2, so we can compare indexes within the same table.

Here's how it works:

Different Index Names: d1.IndexName <> d2.IndexName stops an index from matching itself.
Same Schema and Table: Both sides have to be on the same table.
Same Key Columns: d1.KeyColumnList = d2.KeyColumnList. The list includes sort order, so an ASC and a DESC index on the same column don't match.
Same Included Columns: ISNULL(d1.IncludeColumnList, '') = ISNULL(d2.IncludeColumnList, ''), so two indexes with no included columns compare as equal instead of as NULL against NULL.

SELECT d1.SchemaName
    ,d1.TableName
    ,d1.IndexName
    ,d1.KeyColumnList
    ,d1.IncludeColumnList
    ,d1.is_disabled
    ,d1.DropIndexStatement
FROM CTE_IndexData d1
WHERE EXISTS (
    SELECT 1
    FROM CTE_IndexData d2
    WHERE d1.SchemaName = d2.SchemaName
        AND d1.TableName = d2.TableName
        AND d1.KeyColumnList = d2.KeyColumnList
        AND ISNULL(d1.IncludeColumnList, '') = ISNULL(d2.IncludeColumnList, '')
        AND d1.IndexName <> d2.IndexName
    )
ORDER BY d1.SchemaName
    ,d1.TableName
    ,d1.KeyColumnList;

Limitations

There are a number of things this query doesn't check for, so take precautions when dropping any index. When deciding which of the pair to drop, it's best to drop the one with fewer reads, which this query shows:

SELECT o.name AS TableName
    ,i.name AS IndexName
    ,i.type_desc AS IndexType
    ,u.user_seeks AS UserSeeks
    ,u.user_scans AS UserScans
    ,u.user_lookups AS UserLookups
    ,u.user_updates AS UserUpdates
    ,u.last_user_seek AS LastUserSeek
    ,u.last_user_scan AS LastUserScan
    ,u.last_user_lookup AS LastUserLookup
    ,u.last_user_update AS LastUserUpdate
FROM sys.dm_db_index_usage_stats AS u
INNER JOIN sys.indexes AS i ON u.object_id = i.object_id
    AND u.index_id = i.index_id
INNER JOIN sys.objects AS o ON i.object_id = o.object_id
WHERE u.database_id = DB_ID()
    --AND o.name = 'Badges' -- Filter by table name
ORDER BY o.name
     ,i.name;

Before you trust those numbers, check how long the server has been up. The sys.dm_db_index_usage_stats documentation says "the counters are initialized to empty whenever the database engine is started," so an index that looks unused might be one nobody has needed since the last reboot. SELECT sqlserver_start_time FROM sys.dm_os_sys_info tells you the window you're actually looking at. A monthly report that runs on the first is invisible in three days of data, and if you drop its index because the counters say zero, you'll find out about the report when it next runs.

A restart isn't the only thing that clears them. The same page says "whenever a database is detached or is shut down (for example, because AUTO_CLOSE is set to ON), all rows associated with the database are removed." So on a database quiet enough for AUTO_CLOSE to keep closing it, the counters can be empty no matter how long the instance has been up, and the uptime check won't show it.

The query also doesn't check whether either index is unique, or compare compression or fill factor, just to name a few, so check those yourself. A unique index needs the most care, since it enforces a constraint as well as serving reads, and dropping it changes what the table allows rather than just how it performs.

As always, test changes in a non-production environment before making them in production. In other words, don't ruin your Friday.

Before dropping an index, script out its CREATE INDEX statement and keep it somewhere, so putting it back doesn't depend on remembering the definition.

How to Improve SQL Server Performance by Avoiding Key Lookups

Tue, 10 Sep 2024 00:00:00 GMT

Recently I've been looking into simplifying my performance tuning. One of the more straightforward ways to improve a query is to get rid of key lookups. A key lookup happens when SQL Server finds rows through a nonclustered index but needs columns that aren't in that index. It goes back to the clustered index for each row to get the rest. Microsoft's operator reference calls it "a bookmark lookup on a table with a clustered index," and the same thing on a heap shows up as a RID Lookup. Either way, it's extra I/O for every row the index finds.

Investigating the I/O Performance

Since I want to focus on I/O, I start by running SET STATISTICS IO ON to measure logical reads for each query, and I also turn on the actual execution plan to check for index suggestions from the optimizer.

This is the query, against a Users table:

SELECT DisplayName, UpVotes, DownVotes
FROM Users
WHERE DisplayName = 'Alex'

The STATISTICS IO output:

Table 'Users'. Scan count 7, logical reads 320359, physical reads 0, page server reads 0, read-ahead reads 316400, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

The number that matters here is 320,359 logical reads. The table has no indexes except the clustered index on the primary key, and the execution plan suggests creating this one:

CREATE NONCLUSTERED INDEX [IX_Users_DisplayName]
ON Users (DisplayName)

Adding the Index

After adding the index, I ran the query again. The results already show an improvement:

Table 'Users'. Scan count 7, logical reads 76773, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

That's a big drop in logical reads, but 76,773 still seems high for such a simple query. What's left is the key lookups. UpVotes and DownVotes aren't part of the new index, so SQL Server goes back to the clustered index to get them for every row the index finds.

The suggested index only had DisplayName in it. Missing index suggestions can include columns, and Microsoft's guide to missing index suggestions lists included columns among the things they suggest. The same guide is clear that they're estimates made before the query runs, and that they "aren't prescriptions to create indexes exactly as suggested." So it's worth checking whether an index built from a suggestion actually covers the query.

Including Columns

UpVotes and DownVotes aren't part of the WHERE clause, so they don't need to be key columns. I added them to the INCLUDE clause of the index instead:

CREATE NONCLUSTERED INDEX [IX_Users_DisplayName_INCLUDES]
ON Users (DisplayName)
INCLUDE (UpVotes, DownVotes)

Then I ran the query one last time:

Table 'Users'. Scan count 1, logical reads 32, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

With the key lookups gone, logical reads went from 320,359 to 32, and the scan count went from 7 to 1.

Keep in mind that creating several small indexes like this will slow down INSERT, UPDATE, and DELETE operations, just like any index does, so use them sparingly and create covering indexes where they make sense. Microsoft's guide makes a related point. Before creating an index from a suggestion, look at the indexes already on the table and combine them where you can, instead of adding one that overlaps. Here, that means IX_Users_DisplayName is redundant once IX_Users_DisplayName_INCLUDES exists, since they have the same key. Monitoring and maintaining your indexes is just as important as creating new ones.

How to Download and Install the Latest Cumulative Update for SQL Server

Mon, 09 Sep 2024 00:00:00 GMT

Microsoft isn't perfect, so it releases regular updates to SQL Server. They come in a few forms, but the one I see most is the Cumulative Update (CU). Microsoft's servicing model page gives the schedule for SQL Server 2017 and later. CUs come out every month for the first year after a release, and every two months for the remaining four years of the five-year mainstream lifecycle. A version that has been out for a while is on the two-month schedule, which helps when planning maintenance windows.

Below are the steps to download and install the latest CU on your SQL Server.

Download the Latest CU

The latest CU for each supported version is listed on Microsoft's release page.

Each cumulative update is specific to a SQL Server version (SQL Server 2019, 2022, and so on), so check which version you're on first by running this in SSMS:

SELECT @@VERSION

Before you go looking, check that your version still gets CUs. The servicing page says "CU31 for 2017 is the last CU for SQL Server 2017," and that Microsoft no longer ships CUs for SQL Server 2016 and earlier, only on-demand fixes and security updates.

From the release page, select your version, and you'll be taken to the KB page for that CU. Read the documentation for your CU, then scroll down to the section marked How to obtain or download this or the latest cumulative update package and click the link labeled Download the latest cumulative update package for SQL Server 20xx now.

That takes you to one more page, where you download the CU itself. It's usually an .exe named something like SQLServer20xx-KBxxxxxxx-x64.exe.

Installing the CU

Installing a CU requires downtime for your SQL Server, so get a maintenance window before you start. Make sure you have a recent database backup before installing the CU. It can be the difference between a 15-minute maintenance task and a 3-hour phone call with your boss, sales, and an angry client. Once that's done, right-click the .exe and choose Run as Administrator to open the SQL Server Update installer.

The installer walks you through a few steps:

Accept the License Terms: Read through and accept the license agreement.
Select SQL Server Instances: The installer detects the SQL Server instances on the machine. Choose the ones you want to update.
File Check: The installer checks that the files it needs aren't in use. When it finishes, click Next.
Summary: Review the summary to make sure it's accurate, and click Update.

The update takes a few minutes, depending on your system and SQL Server configuration. The selected instances may be unavailable while it runs, so this is when users start calling if they weren't told about the downtime.

When it finishes, check that every operation shows Successful and close the installer.

Post Installation Tasks

I've seen some people suggest restarting SQL Server after applying a CU, but unless the installer asks for it, I don't find that necessary. To check that the update was applied, open SSMS, connect to your instance, and run this query again:

SELECT @@VERSION

This time you should see the CU after the version number, along with the KB number (for example Microsoft SQL Server 20xx (RTM-CUxx) (KBxxxxxxx)...).

If the install failed and you need to roll back to the previous version, the instructions for uninstalling that KB are at the bottom of the KB article.

CUs and GDRs

There's a second kind of update to know about. A General Distribution Release (GDR) is an update Microsoft releases for issues with broad impact, security issues, or both, and it's the kind that comes through Windows Update. The servicing page says a GDR "can have either an RTM baseline or a CU baseline," and each baseline has its own line of GDRs. So a server that has only ever received GDRs is on a different line of builds than one that gets CUs. The page has examples for working out which line a given server is on. Its general advice is that "Microsoft always recommends that you install the latest CU that's available for a given SQL Server version."

As always, if you run into issues or need help troubleshooting, leave a comment below and I or someone in the community can help.

How to Download and Install Microsoft SQL Server 2022

Sun, 08 Sep 2024 00:00:00 GMT

Installing SQL Server 2022 is a straightforward process if you follow the right steps. This covers downloading the installer, running it, and two settings worth checking once it's done.

Downloading SQL Server 2022

The latest official release is on Microsoft's SQL Server Downloads page. If you're looking for an older or specific version, it's on the Microsoft Evaluation Center under the SQL Server section.

The download asks you to choose between Developer Edition and Express Edition. Microsoft's editions page says Developer Edition "includes all the functionality of Enterprise edition, but is licensed for use as a development and test system, not as a production server." Express Edition is free, and the same page caps it at a 10 GB database and 1,410 MB of memory for the buffer pool.

For this guide, I'm using Developer Edition.

Installing SQL Server 2022

After downloading the installer, copy SQL2022-SSEI-Dev.exe (or SQL2022-SSEI-Expr.exe for Express) to the machine where you want to install SQL Server. Right-click the file and choose "Run as Administrator" to start.

Once the installer opens, you'll have three options:

Basic: A quick installation with default settings.
Custom: Walks you through the full setup wizard so you can choose each setting.
Download Media: Downloads the full installation files to use later.

For most installations, Basic is enough. Accept the License Terms, select your installation location, and click Install. It usually takes a few minutes, depending on your hardware and Windows version.

Two settings to check afterwards

Basic doesn't walk you through the wizard's configuration pages, and two of those pages set values that affect how the instance behaves. Microsoft's setup documentation describes what each one does when it's skipped.

Max degree of parallelism (MAXDOP). Starting with SQL Server 2019, setup works out a recommended MAXDOP from the number of cores. If the page is skipped, the documentation says setup uses that recommended value "instead of the default Database Engine value for previous versions (0)."

Max server memory. If the Memory page is skipped, setup uses the Database Engine default of 2,147,483,647 MB, which in practice means no limit. Microsoft's server memory configuration guidance covers how to pick a value, and it's worth reading before you set one.

This shows what the instance actually ended up with:

SELECT name, value_in_use
FROM sys.configurations
WHERE name IN ('max degree of parallelism', 'max server memory (MB)');

Post-Installation

When installation completes, setup shows the configuration it used and confirms whether it succeeded. If something went wrong, it writes a log file with more detail that you can use to troubleshoot.

If you cancel the installation partway through, clean up any leftover files in the installation directory and uninstall any partially installed SQL Server components. Otherwise, they can cause problems the next time you try to install.

This guide only covers installation, not security, best practices, or database configuration. With the installation done, SQL Server 2022 is ready for creating new databases or migrating existing ones.

If you run into an error, search for the error code first, since most installation errors have known solutions. If that doesn't turn anything up, feel free to leave a comment.

How to Download and Install SQL Server Management Studio (SSMS)

Sun, 08 Sep 2024 00:00:00 GMT

SQL Server Management Studio (SSMS) is Microsoft's official tool for working with SQL Server. For database administrators who need to read and write T-SQL and review execution plans, it's close to essential. Developers use SSMS too, and there are other options like the SQL Server extension for Visual Studio Code, but it doesn't offer the same experience. I personally prefer SSMS, though I do more DBA work than development work.

When I first wrote this post, SSMS came as a single installer, SSMS-Setup-ENU.exe. That changed with SSMS 21. It now installs through the Visual Studio Installer, and what you download is a small bootstrapper rather than SSMS itself. If you're looking for SSMS-Setup-ENU.exe because that's what you used last time, it's no longer how the current version installs.

Downloading SSMS

The latest release is linked from Microsoft's SQL Server Management Studio install page.

The download is vs_SSMS.exe. Microsoft's page calls it "a stub installer, or bootstrapper." It installs the Visual Studio Installer, which then installs SSMS, and the page says plainly that "there's no standalone MSI."

Installing SSMS

Once the download completes, go to where it was saved and double-click vs_SSMS.exe. You need administrator permissions on the machine, and if you get a User Account Control prompt, choose Yes.

The Visual Studio Installer opens with a few optional choices:

Workloads: Groups of extra features. The page gives the Hybrid and Migration workload as an example, for assessing upgrade readiness and migrating data. None of them are required for SSMS itself.
Individual components: The same idea at a finer grain, if you'd rather pick individual pieces than a whole workload.
Installation location: Worth deciding now. Microsoft's page says you can choose a different drive for SSMS and the download cache "only when you first install SSMS," and changing it later means uninstalling and reinstalling.

Then click Install. It can take anywhere from a few minutes to half an hour, depending on your system.

Post-Installation

When the installation finishes, you can open SSMS from the Start Menu or by searching for it. A reboot usually isn't required, but if you see a prompt to restart or run into any issues, it's a good idea to go ahead and do it.

Versions

SSMS 22 works with SQL Server 2014 and later, according to the install page, and it can be installed side by side with other versions of SSMS. If you need to manage something older than SQL Server 2014, Microsoft's release history page has links to earlier versions.

As of September 2026, the current release is 22.10.1. Only the latest release gets fixes. The support policy says "the SSMS team doesn't actively back-port fixes to an earlier release," so if something is broken on an older install, the first step is to update and see whether it's still broken.

This guide only covers installation. Connecting to remote servers, configuring databases, and security are all worth reading up on separately. If you run into issues along the way, feel free to leave a comment.

Resolving SQL Server Instance and Database Collation Discrepancies: Step-by-Step Guide

Thu, 25 Jul 2024 00:00:00 GMT

Recently I ran into a situation while migrating a database to a new SQL Server instance where the instance collation was different from the database collation. JOIN, ORDER BY, GROUP BY, and other operations started failing with collation conflict errors. I had a strict deadline to get these applications migrated, so I decided to rebuild the instance collation to match the new application databases.

Microsoft's Set or Change the Server Collation page lays out the full sequence, and it's more than the rebuild on its own. You script out your user databases, export the data with something like bcp, drop all the user databases, rebuild master with /SQLCOLLATION, then recreate everything and import it back. I skipped the export and import steps because I was restoring the databases from backups afterward anyway, but it's worth reading the documented sequence before you decide this is the route you want.

Temp tables inherit tempdb's collation, which comes from the instance. The same page lists what the server collation governs, including the "collation of the CHAR, VARCHAR, NCHAR, and NVARCHAR columns in system views, system functions, and the objects in tempdb (for example, temporary tables)." That's why the errors show up where they do. Temp tables get the instance's collation, so comparing a column in your database with a column in a #temp table means comparing two different collations.

This is the heavy option. Microsoft's rebuild system databases page says master, model, msdb, and tempdb are "dropped and recreated" and that user modifications to them are lost. That means logins, SQL Agent jobs, linked servers, and server-level settings all have to be put back afterward. The lighter alternative is fixing the queries instead. The COLLATE clause supports database_default, which can make a temp table column use the current database's collation instead of tempdb's. The preparation below is all about being able to put back what the rebuild removes.

Preparations

Run the following queries and copy the results to Notepad or an Excel spreadsheet.

-- View system configuration
SELECT * FROM sys.configurations;

-- View server properties
SELECT SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductLevel') AS ProductLevel,
SERVERPROPERTY('ResourceVersion') AS ResourceVersion,
SERVERPROPERTY('ResourceLastUpdateDateTime') AS ResourceLastUpdateDateTime,
SERVERPROPERTY('Collation') AS Collation;

-- View database files locations
SELECT name, physical_name AS current_file_location
FROM sys.master_files
WHERE database_id IN (DB_ID('master'), DB_ID('model'), DB_ID('msdb'), DB_ID('tempdb'));

Before moving forward, I backed up everything that would be lost due to the rebuild, including SQL logins, jobs, alerts, linked servers, and permissions. I also made sure I had recent backups of every database.

SQL Server Configuration

To save the current SQL Server settings, I ran the following script and copied the results to a file:

-- Enable advanced options
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

DROP TABLE IF EXISTS #ConfigSettings;

-- Create a temp table to store the configuration settings
CREATE TABLE #ConfigSettings (
    name NVARCHAR(35),
    minimum INT,
    maximum INT,
    config_value INT,
    run_value INT,
    config_script NVARCHAR(MAX)
);

-- Insert the configuration settings into the temp table
INSERT INTO #ConfigSettings (name, minimum, maximum, config_value, run_value)
EXEC sp_configure;

-- Update the temp table to add the script column
UPDATE #ConfigSettings
SET config_script = 'EXEC sp_configure ''' + name + ''', ' + CAST(config_value AS NVARCHAR(10)) + ';';

-- Select the results
SELECT * FROM #ConfigSettings;

This script captures the SQL Server settings that will be wiped out during the rebuild. Save the results to a folder dedicated to the rebuild process.

Script Logins and Permissions

SQL logins need to be exported along with users and roles. I created the two stored procedures from Microsoft's page on transferring logins, then ran this to generate a script that recreates the logins, which I saved to my REBUILD folder:

EXEC sp_help_revlogin

Script Msdb Objects

Everything in this section is optional, so only do the parts you need. In my case, I needed to copy the SQL Jobs, Alerts, and Operators. If you have Linked Servers, Endpoints, Extended Events, or Database Mail, now is the time to copy those configurations too. I expanded SQL Server Agent in Object Explorer, selected the Jobs folder, and pressed F7 to bring up Object Explorer Details. From there I could highlight the jobs I wanted and script them as CREATE To a file in my REBUILD folder. I then repeated these steps for the Alerts and Operators.

Script Master Objects

This section is optional too and depends on how the server is used. I always install sp_WhoIsActive and similar stored procedures in the master database. Right-click on the objects you need to keep and script them, individually or all together, to the REBUILD folder.

Rebuilding the System Databases

Once I completed those steps, I moved on to rebuilding the system databases. This step requires downtime. I logged in to the database server and found the setup.exe for SQL Server, which for me was in C:\Program Files\Microsoft SQL Server\160\Setup Bootstrap\SQL2022. I opened a CMD prompt, changed to that directory, and ran:

setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=<ListOfAdminAccounts> /SAPWD=<YourStrongPassword> /SQLCOLLATION=<NewInstanceCollation>

Microsoft has a list of additional parameters you can add to the command.

After the command completed, I logged back into SQL Server via SSMS and verified the database collation with:

SELECT name, collation_name FROM sys.databases WHERE database_id < 5

With that behind me, I was able to run the CREATE scripts I generated earlier, as well as the configuration script.

I needed to add the following to the top of my sp_configure script to enable Advanced Options.

EXEC sp_configure 'show advanced options', '1'
GO
RECONFIGURE
GO

After that was finished, I disabled Advanced Options again.

EXEC sp_configure 'show advanced options', '0'
GO
RECONFIGURE
GO

Finally, I restored all databases from the most recent backup, completing the migration.