Chandler Gray

How to Deploy a SQL Server Availability Group for High Availability

Sat, 25 Jul 2026 00:00:00 GMT

Despite building dozens of SQL Server availability groups at work, I've yet to build one for my homelab. The main reason is that in order to do it right, I needed to set up an Availability Domain, which I have never done before. However, it is currently done, so I was ready to get started.

This post will mainly only cover standard AGs, meaning I won't be outlining how to create a Contained AG, but I do plan to write one for that specifically at a different time.

Some details about my homelab before I begin.

I run a single Proxmox node, managed largely through Terraform.
Storage is just a standard ZFS model.
I reserved each of the IP addresses for the servers, LB, etc... through my Unifi gateway.
Each of the servers I am running in the lab (Two SQL Servers, one AD) are all running on non-licensed Windows Server 2025.
My two SQL Servers are both running SQL Server 2025 Enterprise Developer Edition.
Very obvious, but of course if my storage or host dies, HA won't really help me since I'm only on one host, but this is just for my homelab and nothing critical will be stored on them so I am accepting the 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 am doing is two SQL Server 2025 nodes in 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 as follows

VLAN 192.168.25.0/26:

If you haven't touched networking outside of what SQL Server makes you deal with, a quick translation: 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, validate that both instances are on the same version of SQL Server, ideally Enterprise Edition, but Standard works ok for this lab as well.

Phase 2 - Active Directory and Domain Join

I'll admit this phase is where I spent most of my time, mostly because I hadn't stood up a fresh forest, ever. 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," a reverse zone answers "what's the name for this IP." It sounds like a nice-to-have, but both SQL Server and Windows clustering actually check reverse lookups in a few places, so skipping this zone can cause odd failures later that have nothing obviously to do with DNS.

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. When researching, I found 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 worth knowing that error exists 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, normally domain-joined machines 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 prompt to restart the service, let it, since the change doesn't fully take effect until it does.

If you want SQL Server Agent running under the domain identity too, since it isn't required for anything in this post, only useful if you want scheduled jobs to run as that account, 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

A word on the CNO, since it was confusing to me when I 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

Worth calling out: a default SQL install often has the TCP/IP protocol disabled in favor of Named Pipes, an older way for processes to talk to each other that works fine on a single machine but was never meant for the kind of network traffic an AG listener needs to serve. Ports are just the numbered "doors" a service listens on; 1433 is SQL Server's normal client door, and 5022 is the door AG replicas use to talk to each other. AG replication traffic over 5022 still works fine without TCP/IP enabled, but clients, and the AG listener itself on 1433, need TCP enabled. If you miss this, SSMS and the failover wizard will 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 already know that Named Pipes was even in the running. The New-NetFirewallRule lines after it open those two ports through Windows Firewall, since even with TCP enabled inside SQL Server, the OS firewall will silently drop the traffic unless a rule explicitly 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, since automatic seeding needs that starting point to stream from.

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. Certificate-based endpoints are really only necessary when the replicas run under different accounts.

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 automatically, since without that grant, automatic seeding fails silently rather than throwing an error you'd notice.

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, SQL Server's syntax just 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, so that was great.
Witness loss. Stopping the file share witness on the DC also does not 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.

And "that's it".... there are a lot of steps here. I think most shops have a lot more automation that allows for these to be set up much more consistently and faster. Unfortunately I have not set up Ansible for my homelab yet, but the plan is to set this up before my next demo for creating the Contained AG so I don't need to document all of those steps. Feel free to leave any 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 modify the startup parameters when I 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]"

As the error suggests, the SQL Server Configuration Manager could not connect to the WMI provider. The Windows Management Instrumentation (WMI) is responsible for reporting the status of the SQL Server services to the Configuration Manager. This should get configured automatically during the install, but sometimes this part of the install can fail to complete, and SQL Server may or may not report it.

To fix this and regain access to the SQL Server Configuration Manager, you need to recompile the provider using the mofcomp command.

I did this by opening an elevated Command Prompt and changing the directory to the SQL Server shared directory for my version. In my case, it was a SQL Server 2022 build, and therefor I used:

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

Before I ran the command to recompile the provider, I ran this to find the .mof file in the directory:

dir *.mof

The only reason I recommend doing this is because apparently the name of the file is different amongst different versions of SQL Server. I saw sqlmgmproviderxpsp2up.mof used in a different doc, so be on the lookout for that one. Anyway, since SQL Server ships with the .mof file, you should find only one instance in this directory. If nothing shows up here, you're left with needing to run a repair on the SQL Server installation via Control Panel > Program > SQL Server > Repair

After identifying the appropriate .mof file, you can finally recompile the provider using the mofcomp command. This is what I ran:

mofcomp sqlmgmprovider.mof

At this point, the problem was fixed for me, but Microsoft's documentation suggests you need to restart the WMI service for the change to go into effect. So if the issue persists, you can restart the service using this command in PowerShell:

Get-Service winmgmt | Restart-Service -Force

Restarting the WMI service should only take a few seconds and it doesn't impact SQL Server, active connections, or running queries. The only thing at risk is anything polling via WMI at that exact moment. I found some monitoring agents, PowerShell calls, and performance counters all use WMI, so it's worth doing this during a low-activity window or a maintenance window if you're doing this on a production server.

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. In my experience, the ideal way to do this is to break the database backup in "parts", and upload them via an SFTP server or cloud storageanywhere 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 solutions offer functionality to allow for multiple uploads at once. When you're trying to upload one large file (unless you're limited by your network connection speeds) you could be waiting 10x or more longer than if you were to upload multiple files 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. This is a unique way to get around those upload size restrictions if your backups exceed them.

The three different ways to accomplish this task are: SQL Server 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.

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're not overly picky about the actual size of the database files and want them backed up to a specific number of files, you can modify the backup job to include @NumberOfFiles = n where n equals the number of files you want to backup to.
If you are picky about the max size of each of the files, you can configure that in the backup job by setting @MaxFileSize = n where n, in this case, equals the maximum size of the file in MB.

PowerShell Byte-Level Split

Sometimes you don't have permissions to modify the existing database backup commands, so if the backup already exists as a single file, split it after the fact with PowerShell.

<Callout type="warning"> Do not modify the existing/only copy of the production server's backup. Always duplicate the backup 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 determined solely by $chunkSize. A larger buffer reduces the number of syscalls and improves throughput on large files: at 64MB, a 1 TB file requires ~16,000 read/write pairs per chunk rather than ~256,000 at 4KB. For small files the difference is negligible. Scale $bufferSize up for production use; just keep it well below available RAM and no larger than $chunkSize. </Callout>

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

Limitation: Could be considered more complex 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's downloads can be found on their 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. It will loop through the directory to find all parts. Because of this, all parts must 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.

Understanding SQL Server Deadlocks Through the Prisoner's Dilemma

Tue, 17 Mar 2026 00:00:00 GMT

Everyone has written about deadlocks, so 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.

Neither can communicate with 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 lose.

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, and each window is its own connection. Run each statement one at a time, in the order shown left to right.

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 whats 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 detects this cycle and immediately kills one session with error 1205.

Additionally, you can see the deadlocks in the system_health Extended Events deadlock graph:

This graph is the prisoner's dilemma drawn by SQL Server. Just two nodes with 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, staying silent becomes the best choice. In SQL Server, that agreement is call "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

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, queries no longer take shared locks, instead they read the last committed version of the row from tempdb. This eliminates the most common class of reader-writer deadlocks without changing any query code. Writers still block writers, but reads stop getting deadlocks entirely. The tradeoff is that tempdb gets more traffic.

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.

It requires two things to be enabled before it can be turned on:

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

-- RCSI unlocks 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;

On Azure SQL it's already on by default. On SQL Server 2022 and older it isn't available.

Is it the best option? 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 structural cause. Optimized Locking reduces how often that structure becomes a problem.

Retry Logic in the Application

I actually find this solution to be perfectly fine for most systems, and I see this out in the wild more often than RCSI.

Since the 1205 error message is something the application can read it's easy to 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

When SQL Server detects a deadlock, it picks the transaction cheapest to roll back, measured by the amount of transaction log that would need to be undone. You can override that with SET DEADLOCK_PRIORITY. The range is -10 to 10. The session with the lower value gets killed first. If both sessions have the same priority, SQL Server falls back to log cost.

-- 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 solution but I've actually never seen it actually used in production. That's not to say it's bad, just that it's not common.

The key takaway from all of this is that frequent deadlocks are a sign that something is a problem. Two transactions acquiring the same resources in opposite order will always produce one eventually. Fix the order, eliminate 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 migrate just one year of one table of data from a client's servers to another SQL Server hosted in a VM in the cloud. The data structure already existed, I just needed to move the data to it. Our problem was that the VM that we were moving into didn't actually have enough space to restore the entire database, so a full BACKUP/RESTORE/DELETE wasn't an option. I used bcp for this since it wouldn't require me to install anything on the client's server.

One thing I ran into before anything else: bcp threw a certificate chain error when connecting to the local instance. The fix is the -u flag, which tells bcp to trust the server certificate without validating the chain. This requires bcp version 18 or later, so you can run bcp -v to check. I have it to every command.

The first thing I did was generate a format file. This 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

You won't get any output in the CMD window from this if the format file was successfully exported. Once it's exported you can review the output by opening the .fmt file in Notepad, and it should look something like this:

<Callout type="warning"> One thing to watch is 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. I've had exports of millions of rows take just a few minutes.

I copied the .bcp and .fmt files to the destination machine, then 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.

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>

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

That's pretty much it! 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 will warn that `-f` overrides it
`-f`	Path to the format file
`-E`	Preserve identity values from the file instead of generating new ones
`-b`	Batch size in rows, so each batch commits independently
`-e`	File to write rejected rows and error reasons to
`-h`	Table hints passed to the bulk insert operation
`-q`	Executes `SET QUOTED_IDENTIFIER ON` -- required when the target table has filtered indexes, indexed views, or computed columns
`-u`	Trust the server certificate without validating the chain

Full flag reference 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 the process was to kill it from Task Manager. I knew the automation should only typically take a 5-6 seconds per run, so I wanted the script to time itself out after 30 seconds.

Surprisingly, I've 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 that blocks the current thread for up to the specified number of milliseconds, then returns true if the process exited within that window or false if it did not. 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 is not killed automatically on timeout, so that step is explicit. Note that Kill() only sends the termination signal, so calling WaitForExit() immediately after ensures the process has fully stopped before continuing. Call Close() afterward to release the OS handle.

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()

Now its important to note that there are actually two versions of WaitForExit, one includes a parameter and one does not. The key thing WaitForExit(Int32) gives you that the no-argument version does not is a decision point. With WaitForExit(), your script hands control to the process and does not get it back until the process decides to exit. If the process hangs, your script hangs with it, permanently. With WaitForExit(30000), your script hands control to the process, but gets it back after 30 seconds regardless. The process is still running at that point, it was not interrupted, you just stopped waiting for it. That is when you decide what to do next. In this case, 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. Your pipeline stops here. With WaitForExit(30000), if the script finishes in 5 seconds, the method returns true after 5 seconds and you hit the else branch. If it hangs, you get control back after 30 seconds, kill it, and the rest of your script continues. The process got its window. You decided what happened when it did not use it.

The no-argument WaitForExit() does have its place, such as after Kill(), since you're not waiting with a timeout but confirming the process is fully gone. What you want to avoid is using it in place of WaitForExit(Int32) for the timeout case itself, where you need a decision point and a way out if the process hangs.

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 recently encountered a database that consisted of one .mdf file and seven .ndf files. Although this configuration is not uncommon in older systems, it is no longer necessary in most modern environments. The workload was not pushing any storage limits, and the underlying disk was modern enough to handle a single data file without issue. Therefore, the objective was to restore the database as-is and then consolidate the files into a single file.

Historically, SQL Server implementations utilized multiple data files to distribute I/O across spinning disk volumes, which provided performance benefits at the time. However, with the advent of SSDs and SANs, the advantage of using multiple data files is typically smaller or negligible, and the overhead of managing multiple files can outweigh any potential benefits.

Here's the approach I used, along with a reproducible lab environment for testing.

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 additional files create unnecessary complexity for backup operations, monitoring, and restore procedures.

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

Now we populate data to ensure files are utilized. This table is designed with a wide structure to distribute pages across 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 provides sufficient data distribution across all files without requiring excessive processing time.

Determine File Usage Patterns

After restoration (or demo setup), the initial step is to analyze the file layout and actual space utilization per file.

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 environments, I perform several preparatory steps before modifying file structures:

Ensure recent backups are available and restorable.
Transition to SIMPLE recovery model if appropriate.
Schedule operations during periods of minimal I/O impact.

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

In production, I also inform stakeholders that this operation will be resource-intensive and fully logged, even in SIMPLE recovery mode. The database remains online, but EMPTYFILE operations require significant time.

Move Pages With EMPTYFILE

To consolidate files within a filegroup, we systematically migrate all pages from target files to remaining files in the group.

The core commands for a single file look like this:

USE DemoMergeFiles;
GO

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

The subsequent cleanup command is:

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. It’s fully logged and single-threaded.

Monitoring Data Page Migration Progress

EMPTYFILE operates slowly and provides minimal progress feedback in the Messages tab. To monitor operation status, I query 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 environment, this operation may complete quickly depending on row count. For extended testing, increase @TargetRows in the initial data load to provide more work for EMPTYFILE.

In one production scenario, a ~220 GB NDF required approximately three hours to complete migration. While this operation runs online, I recommend scheduling during maintenance windows to minimize performance impact.

Remove The Emptied File

Following successful EMPTYFILE completion, the target file contains no allocated pages and can be removed from the database. After file removal, verify the updated layout:

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

In production environments, repeat the "EMPTYFILE + REMOVE FILE" sequence for each secondary file scheduled for removal.

Post-Migration Validation

Following file consolidation, I perform comprehensive validation:

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 destination files does not accelerate EMPTYFILE operations. While this prevents autogrowth events, page migration remains single-threaded and fully logged.
Maintaining FULL recovery model during migration can lead to substantial log growth. In one instance involving a ~400 GB database, the transaction log expanded from ~20 GB to nearly 200 GB before I terminated the operation.
Performance improvements from file consolidation are typically not measurable in these scenarios. The primary benefit is reduced administrative overhead.

When Multiple Data Files Are Still Worth It

To clarify, this approach is not intended for universal .ndf removal:

TempDB absolutely benefits from multiple files in many environments.
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.

File consolidation requires significant time, but this overhead is typically incurred only once. The result is simplified administration with a single data file instead of multiple secondary files, reducing complexity during maintenance and restore operations.

None of this makes the server magically faster tomorrow. It just reduces operational complexity. If you want to demonstrate this for your team or capture screenshots for documentation, the DemoMergeFiles database above provides a safe way to show the entire process end-to-end without affecting production systems.

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 almost every SQL Server I work with. Manual installation works fine, but dbatools makes it much easier. If you need to install dbatools first, I have a quick guide here: <a href="https://chandlergray.com/blog/installing-dbatools/" target="_blank" rel="noopener noreferrer">Installing dbatools</a>.

Once you have dbatools, installing sp_WhoIsActive is simple:

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

For multiple servers, you can loop through them:

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

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

This is a simple way to save time and keep sp_WhoIsActive consistent across your servers. It's straightforward and doesn't add extra steps to your workflow.

Don't Outsource Your Problem

Fri, 31 Oct 2025 00:00:00 GMT

We’ve all done it. You hit an error, take one look at the message, and fire it off to someone else. Maybe you drop a screenshot in Teams with a quick “anyone seen this before?” hoping they’ll swoop in with an answer.

That’s what I call outsourcing your problem.

Asking for help is essential. In fact, it's fundamental to working in tech, but how you ask matters. When you simply forward the problem, you're asking someone else to start from scratch. They don't know your context, what changed, or what you've already investigated. They have to repeat all the discovery work you skipped.

If you want effective help, provide context. Read the error message. Try to understand what it's communicating. Even if you don't make much progress, demonstrating effort changes the dynamic completely. Compare these approaches:

“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 approach shows you've engaged with the problem. It gives others a starting point. They'll respond more quickly, and you'll gain knowledge instead of just copying a solution.

Effective troubleshooting begins with ownership. Most people don't expect you to have all the answers, but they do expect you to care enough to investigate what's happening before requesting assistance.

So before you send that screenshot, pause. Read the error. Consider what changed. Attempt to isolate the issue.

Then, if you're still stuck, ask for help with context.

I speak from experience. I've sent countless screenshots hoping someone else would save me five minutes of reading. It never worked. The most valuable solutions I've learned came from taking time to understand what the system was actually telling me. Once I stopped outsourcing my problems, I became better at solving them.

Installing dbatools

Wed, 15 Oct 2025 00:00:00 GMT

I write about SQL Server automation often, and dbatools comes up frequently. Instead of rewriting install steps in every post, I'm putting them here once so I can just link back.

The full instructions are on the official site: <a href="https://dbatools.io/download" target="_blank" rel="noopener noreferrer">dbatools.io/download</a>. If you're new to dbatools, follow those first—they're always current. You should also check out their Getting Started page: <a href="https://dbatools.io/getting-started/" target="_blank" rel="noopener noreferrer">dbatools.io/getting-started</a> while you're there since it has many great examples to give you ideas for your next automation project.

The process is simple. From an admin PowerShell session:

Install-Module dbatools -Scope CurrentUser

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

Set-PSRepository -Name PSGallery -InstallationPolicy Trusted

Check that it worked:

Get-Command -Module dbatools

Keep it updated periodically with this command:

Update-Module dbatools

Note: If you get errors about script execution policy, you may need to allow PowerShell to run downloaded modules. The simplest way is:

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
That lets you run modules you install from the Gallery while still keeping protections in place.

That's all you need for most cases. For older Windows versions or locked-down environments, see alternate installation methods on the <a href="https://dbatools.io/download" target="_blank" rel="noopener noreferrer">official download page</a>.

Setting Up an FTP Server on Ubuntu with vsftpd

Fri, 26 Sep 2025 00:00:00 GMT

I run my servers inside Proxmox, so the FTP service is set up on an Ubuntu Server VM. The same steps apply whether you're using bare metal or another hypervisor.

Create the VM

Install Ubuntu Server LTS and assign it a static LAN IP for easier access. 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, check the network adapter mode and verify the IP address is in the correct subnet.

Update the OS

Update the system before installing additional software.

sudo apt update && sudo apt upgrade -y

Install vsftpd

Install the FTP daemon package.

sudo apt install vsftpd -y

If the service doesn't appear to be running, check its status with systemctl status vsftpd.

Create an FTP User

I created a dedicated account for FTP traffic to keep it separate from system logins.

sudo adduser ftpuser

Set a password when prompted.

Login failures (530 Login incorrect) often indicate the account is disabled in /etc/ftpusers or local_enable isn't set in the configuration.

Set Up the Directory Structure

vsftpd requires that a chroot directory cannot be writable. To work around this, I created a locked root folder with a writable subdirectory for uploads.

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 incorrect. It must be owned by root and not writable.

Configure vsftpd

Open the configuration file:

sudo nano /etc/vsftpd.conf

Here's the configuration I used:

listen=YES
listen_ipv6=NO

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

If directory listings stall, the passive port range may not be open.
If the server advertises 127.0.1.1 in passive mode, add pasv_address=<your_LAN_IP> to the configuration.

Restart and Enable the Service

Restart the daemon and enable it to start at boot.

sudo systemctl restart vsftpd
sudo systemctl enable vsftpd

If it fails to start, check the logs:

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

Adjust the Firewall

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

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

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

Test Locally

Before testing with 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 configuration.
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 implemented extensive hardening for internet exposure. Network security isn't my specialty, so I stick to basic configurations. If you have suggestions for improving security, either for FTP specifically or my home lab in general, I'd appreciate hearing 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";

I used to think probability puzzles were mainly for math enthusiasts. The Monty Hall problem, in particular, seems designed to be counterintuitive. But the more time I spent analyzing SQL Server execution plans, the more familiar it became. It turns out Monty Hall and SQL Server share something important: both make you think you're getting a fair choice when the odds were actually skewed before you began.

What’s Monty Hall again?

You’re on a game show. There are three doors. Behind one: a car. Behind the other two: goats. You pick a door. Monty, the host, opens one of the remaining doors to reveal a goat. He offers you a choice: stick with your original door or switch.

Your instinct says, "It’s 50/50 now." But it’s not. The math says switching gives you a 2/3 chance of winning. Staying only gives you 1/3. It’s weird, but it’s true, they even proved it on MythBusters.

SQL Server does the same thing

The simplified version: SQL Server picks a door (an execution plan) based on what it knows at compile time. It makes a choice. Then it shows you the result: the plan it developed based on that initial information.

But the plan it picked might be based on incomplete information. Or a rare parameter. Or outdated statistics. SQL Server isn't being deceptive. It's optimizing based on the information available at that moment.

Let’s demo it.

Demo: Parameter Sniffing and Bad Optimizer Assumptions

Set up this demo in a test database.

-- 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);

<Callout type="info"> You now have a skewed table: Common shows up ~97% of the time. SQL Server will act very differently depending on which value it sees first. </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';

Now that a plan is cached for 'RareA', we’ll run it again but with 'Common'. Below is the execution plan I received.

-- Run with common value — this is the “wrong” plan reused
EXEC dbo.SniffMonty @Category = 'Common';

What's happening is that SQL Server saw 'RareA' first, built a plan that works well for a small result set, and then continued using it. When we run it again with 'Common', it reuses that same plan, even though it now needs to scan almost the entire table. This results in nested loops performing thousands of key lookups, and performance degrades significantly. The plan isn't incorrect, it's based on an outdated assumption.

SQL Server generated an execution plan that estimated only 1,000 rows, when it actually needed to return 98,000 rows.

Step 3: Re-run it 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';

<Callout type="info"> Now the plan is optimized for the common case. Running it with 'RareA' wastes resources reading way too much. </Callout>

It's not about right versus wrong. It's about how SQL Server makes its decision before you know what parameters will be used.

The optimizer's "door" isn't random, it's conditional. This is the Monty Hall connection. In the game show, Monty never opens the winning door. Up to this point I've been referring to this as luck, but it's actually knowledge. Once he opens a goat door, the odds change.

In SQL Server, the optimizer sees parameter values, statistics, and cost estimates, then selects one execution plan. What it shows you isn't a 50/50 choice. It's based on what it considers most likely. And that cached assumption persists until you force it to change.

Solutions and Strategies

Sometimes we stick with the plan and get poor performance. There isn't a perfect solution to this problem, but there are several strategies to mitigate it.

Use OPTION (RECOMPILE) to force a new plan for each execution. This approach avoids reusing a problematic plan, but it can be resource-intensive if the procedure is called frequently.

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

Other options:

Use <a href="https://learn.microsoft.com/en-us/sql/t-sql/queries/hints-transact-sql-query?view=sql-server-ver17#optimize-for-unknown" target="_blank" rel="noopener noreferrer">OPTION (OPTIMIZE FOR UNKNOWN)</a> if you want SQL Server to make a generic plan.
Use OPTIMIZE FOR ('Common') if you know most values will be skewed that way. This option does not scale well, however.
Consider splitting procedures for hot vs cold values, or use dynamic SQL to avoid plan reuse where it hurts.

Key Takeaway: Question the First Plan

The optimizer's job is to make an educated guess. Your job is to determine whether that guess is appropriate. Sometimes it isn't. Sometimes it's based on outdated statistics, parameter sniffing, or other factors.

When you encounter a poor execution plan, don't assume it's optimal for your use case. Ask what it was designed for. Ask whether the system made assumptions based on limited information. And when it does... consider switching approaches.

SELECT * in SQL Server: Payload and Throughput

Wed, 09 Jul 2025 00:00:00 GMT

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 is useful for side-by-side shape checks but not useful as a scale metric 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 does not 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
l
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 many SQL Server databases. Different teams, different eras, different ideas of what "good enough" looks like. What 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 mentioned why autogrowth matters: uncontrolled growth leads to excessive VLF counts, which hurts performance.

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

The Script

Here's 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 just makes future growth happen in predictable, healthy chunks.

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 seems to work, or does nothing. Either way, the log eventually grows back, your I/O performance suffers, and the problem returns a week later.

Shrinking your transaction log normally isn't a solution. It's a temporary fix. If you're doing it regularly, you're probably solving the wrong problem.

What DBCC SHRINKFILE Really Does

This command doesn't just cut off the end of the file and return space. SQL Server moves virtual log files (VLFs) toward the front, then releases unused space from the end of the file—but only if those VLFs are inactive.

If they're 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. It just won't shrink. And if you're in full recovery mode without frequent log backups, SQL Server can't even mark old log space as reusable.

Reproducing the Problem

Here's a simple demo 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 data safe—and that means holding onto log space.

Why Regular Shrinking Could* Make Things Worse

Shrinking isn't entirely harmless. Every time you shrink the log, you break up its internal structure. On the next autogrowth, SQL Server often creates many small VLFs to keep up—leading to slower crash recovery and worse performance.

Also, shrinking hides issues like no log backups, inefficient transaction patterns, bad autogrowth settings, or logs undersized for the workload.

How to Actually Manage Your Log File

Here's what works:

Size it correctly from the start. Look at historical peak usage and give your log file enough room.
Use fixed autogrowth sizes—avoid percentages. Percentage-based growth leads to unpredictable VLF counts.
Schedule frequent log backups (for full or bulk-logged recovery). This marks inactive VLFs as reusable.
Monitor log space properly so you know what's happening 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

Let's say you just offloaded a massive archive table or ran a one-time migration and your log grew much larger than your workload needs. In that case, a one-time shrink is fine. But after that, resize the file to something appropriate and let it grow only when necessary.

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

Wrapping Up

If your transaction log is getting too big, it's usually trying to tell you something: your recovery model, backup frequency, or workload needs attention.

Don't treat DBCC SHRINKFILE like regular maintenance. Treat it like a fire extinguisher: use it only when you absolutely have to, and figure out how to prevent the fire next time.

Migrating Your SSRS ReportServer Database

Wed, 07 May 2025 00:00:00 GMT

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

Migrating SSRS ReportServer databases often looks simple on paper: copy a .bak file, run RESTORE, and expect everything to work perfectly. But the reality is different—encryption keys, service accounts, and user mappings can create serious headaches if you don't handle them properly. I've seen migrations fail because the new database couldn't decrypt connection strings or users got locked out due to SID mismatches.

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. Use a strong password and store both file and password in a secure location.

Back Up the ReportServer Database

With the encryption key secured, perform 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 confirm that the destination instance has its own fresh ReportServer backup in case you need to roll back.

Restore the Database on the Destination

I always switch the ReportServer database to 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

Immediately check sys.databases or the SQL Server error log to ensure there were no lock or permission errors during the restore.

Reassign Database Owner and Fix Logins

SSRS requires the sa account 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';

Validate that each database user now correctly maps to its server login.

Recreate the SSRS Service Account User

The SSRS service account (usually 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, verify that a simple query against an SSRS catalog view (e.g., 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.

<Callout type="info"> The backup/restore process does not migrate shared data source definitions. After migration, you must manually recreate each shared data source in the new SSRS instance and reconfigure every report to use the appropriate data source. </Callout>

Validate the Web Portal

Finally, open your SSRS Web Portal URL in a browser. Navigate through several folders and render a few reports. If you encounter a 404, authentication failure, or rendering error, inspect the SSRS service log (ReportServerService__*.log) for clues—whether it’s database connectivity, decryption, or URL binding—and correct the underlying issue before retesting.

Conclusion

By exporting and restoring the encryption key first, verifying each database-restore step, fixing ownership and logins, recreating the SSRS service-account user, and then restoring keys, you avoid the usual surprises. I'll eventually wrap these steps into a PowerShell module, but for now the process is straightforward enough and really doesn't take that long.

How to Install SQL Server 2022 on MacOS

Tue, 29 Apr 2025 00:00:00 GMT

Microsoft is clear that SQL Server doesn't run natively on macOS. I learned this the hard way in college. I bought a Windows license, set up a VirtualBox VM on my 8GB MacBook Pro, and struggled through installing SQL Server 2016 for a database class. It was a painful experience.

If only 2015 me knew about Docker.

What is Docker?

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

Installing Docker

Macs come in two types: Intel and Apple Silicon. Docker Desktop supports both, but setup steps are a bit different. Follow the official Docker Desktop install guide and choose the version that matches your architecture.

After installing, open Docker and sign in or create a new account.

Install SQL Server

Deploying SQL Server is surprisingly easy, which is why it's better than a VM for this use case. Just open Terminal and run these commands:

docker version

If that fails with -bash: docker: command not found, Docker might 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 online for help. Once those issues are fixed, run this command to pull SQL Server 2022:

docker pull mcr.microsoft.com/mssql/server

When that finishes, run this to start SQL Server. Change the password before running:

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 should complete quickly, and when it's done, you have SQL Server 2022 running on your local machine on port 1433.

What now?

This setup isn't for production, but it's great for local testing, development, and learning. If you want to explore more, check out Docker Hub and the official Microsoft SQL Server on Linux documentation.

That's it: SQL Server on your Mac, no VM, no problem. If you made it this far, congratulations! You've bypassed 2015 me and saved yourself 4GB of RAM and some sanity.

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 optimized for SQL Server 2022. While it may work with other versions, some wait types specific to 2022 will be missing. </Callout>

Analyzing wait statistics quickly reveals where the server is experiencing performance issues. SQL Server is not particularly effective at communicating its problems, nor does it self-correct.

Memorizing all 900+ wait types in SQL Server is impractical, so filtering out irrelevant noise is valuable. By querying sys.dm_os_wait_stats and categorizing hundreds of wait types into meaningful groups, we can focus on significant waits and ignore benign background activity.

When inheriting a server, preserve existing wait statistics to understand historical performance patterns. Clear old data only when troubleshooting active incidents and requiring a fresh baseline. For live investigations, execute:

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

The Script

The script below categorizes each wait into CPU, Memory, Database Blocking, I/O, or Tempdb Contention groups while filtering noise, then uses a single GROUPING SETS query to display both detailed and aggregated results efficiently.

-- 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

After execution, rows labeled Detailed display individual wait types being tracked, while Aggregated rows provide category summaries. Use detailed output for investigation and aggregated results for a high-level overview of where SQL Server spends most time.

Avoid focusing solely on the top wait type. Total waits across categories often provide different insights than individual peaks. Analyze the aggregates, not just the maximum values.

For reference, the benign wait_types list is sourced from Glenn Berry's DMVs, query 42.

How to Configure and Tune MAXDOP

Sun, 27 Apr 2025 00:00:00 GMT

When I began learning SQL Server administration, I researched numerous articles about configuring Max Degree of Parallelism (MAXDOP). MAXDOP controls the number of logical processors a single parallel plan can utilize. A setting of 0 allows SQL Server to use all available processors (up to 64). A setting of 1 forces each query to execute on a single thread. Intermediate values allocate a predictable portion of CPU capacity to each parallel operator.

How to set MAXDOP

Despite extensive information available, conflicting recommendations about MAXDOP configuration are common. To establish clarity, I rely on Microsoft's official guidance. While this may not be universally optimal, it provides a solid foundation. Below 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

For simplified implementation, I developed a T-SQL script that provides recommendations automatically:

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 results are straightforward. Use the recommended value from the script and apply it with the following configuration:

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

Monitoring MAXDOP effectiveness requires careful observation. Since MAXDOP changes impact query performance, when should adjustments be made? My approach is to measure performance of both slow and reasonably fast queries. Apply Microsoft's recommended MAXDOP setting, then monitor overall performance over subsequent hours, days, and weeks. If queries exhibit slower performance, examine the query plans. Indicators of excessive MAXDOP include queries that previously ran efficiently with minimal threads now utilizing more threads without performance improvement, or increased execution wait times. Conversely, insufficient MAXDOP manifests as queries constrained to single threads when they would benefit from parallelism, or elevated CPU wait statistics. Adjust settings based on observed performance patterns.

Using Query OPTION (MAXDOP n)

Database administrators or developers might use the OPTION (MAXDOP n) query hint to enforce specific parallelism for individual queries. This practice is generally not recommended for production environments, but can be valuable for performance testing and troubleshooting. Here's an example of this hint:

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

Database-level MAXDOP settings may not be optimal for every query, making query-level hints necessary in some cases to meet performance requirements. However, use this approach sparingly and maintain awareness of queries using hints. When SQL Server configurations change, adjusting at the database level is more efficient than locating and modifying individual queries.

Every environment has unique characteristics. Begin with Microsoft's recommendations and adjust based on performance requirements. Continuous monitoring and measurement are essential to prevent performance issues that require emergency intervention.

Optimizing SQL Server Backup Transfers with Robocopy

Tue, 22 Apr 2025 00:00:00 GMT

I once faced a 30GB SQL Server backup through a VPN that managed about 1MB/s and dropped every 45-60 minutes. My first thought was, "If I split this into thirty 1GB pieces and copy them in parallel, maybe I can outrun 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 speeds next. At about 1MB/s per slice, copying took roughly 15-17 minutes each. 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 overall transfer time stayed about the same: moving 30GB at 1MB/s still takes about eight hours, plus some 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 few slices with various /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 about half an hour, and /MT:8 came out on top. With that insight, I started the full copy:

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

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 through the afternoon and evening. By day's end all 30 parts had arrived successfully.

Finally, to restore the original .bak file once all parts have transferred, you can unchunk them with a simple 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 SQL Server at restored-large.bak when running your RESTORE DATABASE command.

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 for use.

Today I learned that chopping a large file into pieces rarely speeds up the total transfer. Instead, tuning Robocopy's /MT setting and running multiple instances gives you a straightforward, resilient workflow. When your VPN inevitably drops, you'll appreciate that you let a tested tool handle resume logic for you.

Querying Dates in SQL Server for Performance

Tue, 31 Dec 2024 00:00:00 GMT

I often encounter scenarios where query tuning involves more than just speed. It's also about understanding how SQL Server processes data and which patterns yield the best results. Recently, I explored how different query patterns for filtering dates affect performance, using SET STATISTICS IO ON and SET STATISTICS TIME ON to measure the impact.

Setup

For this analysis, I retrieved user activity from the StackOverflow database's Users table, specifically for the year 2017 (since my database only contains data through 2018). With millions of rows in the table, this provided a good test case. There is a non-clustered index covering this query, which I've included below for reference. The LastAccessDate column is a datetime type.

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 and their results:

First, I used BETWEEN with precise timestamps. This is a common method I see in practice.

Next, I used >= and < with precise timestamps. This approach is also fairly common.

So far, the results were expected. Both queries run quickly enough for my needs and return the expected data. Let's continue.

Then I tried BETWEEN again, but without the precise timestamps. I wanted to see if using a less precise date format would make the query non-sargable.

I didn't see any significant performance degradation in terms of speed or reads, but I did get a few thousand fewer rows than in the previous tests. We'll discuss that later.

After that, I applied the same approach using >= and <. The results were similar to the previous tests.

Next, I used BETWEEN again, but this time converting the datetime value to VARCHAR to manipulate the date format.

Finally, I tried the same approach with >= and <, converting the datetime value to VARCHAR as I did in step 5.

Key Takeaways

The results show that logical reads increase when using CONVERT or similar formatting functions. This happens because they make queries non-sargable, leading to table scans instead of index seeks. Additionally, simplified date ranges using >= and < perform better than BETWEEN due to better clarity and consistency, especially when dealing with time boundaries. The fewer rows returned in Query 3 highlight the importance of precise filtering logic. Based on these results, I'll be avoiding CONVERT and BETWEEN on datetime columns going forward.

Since I'm writing this on December 31st, 2024, I want to wish everyone a happy New Year! Thank you for reading!

Using PowerShell to Automate Glenn Berry's SQL DMV Queries

Sun, 22 Sep 2024 00:00:00 GMT

I frequently use Glenn Berry's SQL Server DMV queries for performance tuning and diagnostics. Because I run these queries often, I needed a way to quickly connect to a server, collect the necessary data, and review it later when time permits. In my role, efficiency and accuracy are essential, so I automate repetitive tasks whenever possible.

While Glenn Berry's scripts are well-documented—and I recommend running them manually to understand their context and importance—I wanted to streamline the process. I developed a PowerShell script that automates these diagnostic queries, enabling faster data collection that can be reviewed when time allows. This approach is also valuable for real-time troubleshooting.

What Is dbatools?

Before diving into the script, I want to introduce dbatools, a comprehensive PowerShell module for DBAs and data professionals. This module includes numerous functions for monitoring, scripting, and management tasks. While I plan to cover dbatools in more detail in future posts, I encourage you to explore the dbatools documentation and GitHub repository to get started.

The Script

Credit goes to the maintainer of the core functionality, the Invoke-DbaDiagnosticQuery command in the dbatools repository. The PowerShell script I developed automates SQL Server diagnostic data collection using Glenn Berry's DMV queries via Invoke-DbaDiagnosticQuery. It connects to a specified SQL Server instance, runs instance-level and optional database-specific queries, exports results to CSV files, and compiles them into a single Excel workbook for analysis.

Accessing the Script

The script is available in my GitHub repository. You can download it directly, and updates will be maintained there.

Prerequisites

PowerShell Execution Policy: Ensure that your system's execution policy allows the running of scripts. You can check your current policy by running Get-ExecutionPolicy in PowerShell. For more information on execution policies and how to modify them, refer to Microsoft's official documentation.

Required Modules: The script will attempt to automatically install the necessary modules (dbatools and ImportExcel), but it's good practice to install them manually to avoid potential issues.

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

How to Use the Script

Here's a step-by-step guide to using the script:

Download the Script:
- Visit the GitHub repository
- Download the Export-SQLDiagnosticData.ps1 script to a local directory.
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 (e.g., 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 bypass most of the prompts by simply specifying them in the execution of the script. For example:

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

As always, I welcome feedback on this script. If you have suggestions for improvements, please comment below so I can consider adding them.

Identifying and Removing Duplicate Indexes in SQL Server

Fri, 13 Sep 2024 00:00:00 GMT

I've been simplifying my performance tuning approach. One method I've used is finding exact duplicate indexes. Duplicate indexes on a table are problematic because whenever you insert, update, or delete a record on that table, SQL Server needs to update the same index multiple times.

Why Duplicate Indexes Are Problematic

Duplicate indexes are indexes that have the same key columns AND the same included columns as another index on the same table.

Issues caused by duplicate indexes include:

Increased Storage Space: Each index consumes disk space. Duplicate indexes unnecessarily inflate the size of your database.
Slower Write Operations: INSERT, UPDATE, and DELETE operations become slower because the database engine must update the duplicate indexes.
Longer Maintenance Windows: Operations like index rebuilds and updates take longer, impacting maintenance tasks and system availability.

The Script

I use this SQL query to find exact duplicate indexes in a database. The query is straightforward when you run it, but I'll break it down so you can understand 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 basic information about existing indexes:

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

Retrieve Key Columns

Next, I create a comma-separated list of key columns for each index, including sort order (ASC/DESC). The STUFF function removes the leading comma and space from the concatenated string. I use a subquery to concatenate column names and their sort orders.

The FOR XML PATH('') trick is used to concatenate the results into a single string.

,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 like 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 generates the DROP INDEX statement. It doesn't help identify duplicates, but it's convenient to have.

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

Find the Duplicates in my Results

Finally, this section identifies the actual duplicates. The main query finds indexes that have duplicates based on their key columns and included columns. To do this, the query joins 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: By confirming that the index names are different (d1.IndexName <> d2.IndexName), we avoid comparing an index with itself, ensuring that we're only identifying true duplicates.
Same Schema and Table: Ensuring both d1 and d2 have the same schema and table names confirms that we're comparing indexes within the same table, keeping our focus precise.
Same Key Columns: We check if the key columns are identical (d1.KeyColumnList = d2.KeyColumnList), which helps us identify indexes that have the same structure and potentially serve the same purpose.
Same Included Columns: The query compares the included columns, handling any NULL values with the ISNULL function (ISNULL(d1.IncludeColumnList, '') = ISNULL(d2.IncludeColumnList, '')). This ensures that indexes aren't mistakenly identified as different due to missing data.

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 several things this query doesn't check for, so be careful when dropping any index. When deciding which index to drop, it's best to drop the one with fewer reads. You can find that with this query:

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;

This query also doesn't check for things like whether it's a unique index, compression, fill factor, among others.

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

How to Improve SQL Server Performance by Avoiding Key Lookups

Tue, 10 Sep 2024 00:00:00 GMT

I've been working on simplifying my performance tuning approach lately. One effective way to improve query performance is eliminating key lookups. A key lookup happens when SQL Server needs to get columns that aren't in a non-clustered index, so it has to go to the clustered index or table for the missing data. This creates extra I/O operations, which usually means slower queries and more server load.

Investigating the I/O Performance

Since I'm focused on I/O, I start with SET STATISTICS IO ON to measure logical reads for each query, and I also turn on the actual execution plan to see if the optimizer suggests any indexes.

Let's look at this I/O-heavy query:

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

The STATISTICS IO results show:

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 important number here is 320,359 logical reads. After checking, I see this table only has the clustered index on the primary key. The execution plan suggests creating this index:

CREATE NONCLUSTERED INDEX [IX_Users_DisplayName]
ON Users (DisplayName)

Adding the Index

After adding the index, I run the query again. The results already show 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. The problem is key lookups - UpVotes and DownVotes are being fetched separately because they're not in the index.

Including Columns

Since UpVotes and DownVotes aren't in the WHERE clause, I'll add them to the index's INCLUDE clause:

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

We run the query one more time and get these results:

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.

By eliminating key lookups, we cut logical reads from 320,359 to just 32. Remember that creating several small indexes like this will slow down INSERT, UPDATE, and DELETE operations, just like any index does. Use them carefully and create covering indexes where they make sense. 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 regularly releases updates to SQL Server to fix issues and improve functionality. These updates typically come as Cumulative Updates (CUs), which release about every 30 days. Here are the steps to download and install the latest CU for your SQL Server.

Download the Latest CU

To get the latest cumulative update for your SQL Server version, go to Microsoft's official release page. This page has updates for all supported SQL Server versions.

Each cumulative update works with a specific SQL Server version (like SQL Server 2019 or 2022), so check your version first by running this query in SSMS:

SELECT @@VERSION

On the release page, pick your SQL Server version and you'll go to the CU page for that specific KB. Read the CU documentation, then scroll down to the section called How to obtain or download this or the latest cumulative update package and click the link that says Download the latest cumulative update package for SQL Server 20xx now.

You'll go to another page. When it loads, download the right CU file. The file will be a .exe file named something like SQLServer20xx-KBxxxxxxx-x64.exe.

Installing the CU

Installing CUs requires downtime for your SQL Server, so schedule a maintenance window before you start. Most importantly, make sure you have a recent database backup before installing the CU. This can turn a 15-minute maintenance task into a 3-hour emergency call with your boss and angry clients. Once you're ready, find the .exe file and right-click it to Run as Administrator. This starts the SQL Server Update Installer.

The installer walks you through a few steps:

Accept License Terms: Read and accept the license agreement.
Select SQL Server Instances: The installer finds all SQL Server instances on your machine. Choose which instance(s) to update.
File Check: The installer checks that needed files aren't in use. When it finishes, click Next.
Summary: Review the information and click Update.

The update takes a few minutes depending on your system and SQL Server setup. During this time, the selected instances might be unavailable, so users will start complaining if you didn't warn them about downtime.

Make sure all operations show Successful and close the installer.

Post Installation Tasks

Some people suggest restarting SQL Server after updates, but I only do this if the installer specifically asks for it. To check that the update worked, open SSMS, connect to your instance, and run the query again:

SELECT @@VERSION

Now you should see the CU short code after the version number and the KB (for example: Microsoft SQL Server 20xx (RTM-CUxx) (KBxxxxxxx)...).

If the installation fails and you need to rollback, you can find uninstall instructions for your specific KB at the bottom of that KB article.

If you run into problems or need help, leave a comment below and I or the community can help troubleshoot.

How to Download and Install Microsoft SQL Server 2022

Sun, 08 Sep 2024 00:00:00 GMT

Installing SQL Server 2022 is straightforward when you follow the right steps. This guide shows you how to download the installation media and successfully install SQL Server 2022.

Downloading SQL Server 2022

To get the latest official version of SQL Server, go to Microsoft's SQL Server Downloads page. This page has the most current SQL Server release available for download.

If you need older or specific versions, head to the Microsoft Evaluation Center. Find the SQL Server section and select the version you need.

When downloading, you'll choose between Developer Edition and Express Edition. The Developer Edition has all features and works well for testing, while Express Edition is good for lightweight applications and development work, though it has some limitations.

I'm using Developer Edition for this guide.

Installing SQL Server 2022

After downloading, copy the SQL2022-SSEI-Dev.exe (or SQL2022-SSEI-Expr.exe for Express) to the computer where you want to install SQL Server. Start the installation by right-clicking the file and selecting "Run as Administrator."

The installer gives you three options:

Basic: A quick installation with default settings.
Custom: Provides more control over the installation process and allows for specific configurations.
Download Media: Allows you to download the full installation files for later use.

For most installations, Basic works fine. Accept the License Terms, choose where to install, and click Install. Installation usually takes a few minutes, but the time varies depending on your hardware and Windows version.

Post-Installation

When installation finishes, you'll see configuration details and confirmation that everything worked. If something goes wrong, SQL Server creates log files with more information to help troubleshoot the problem.

If you need to cancel the installation, make sure to clean up any leftover files in the installation directory and uninstall any partially installed SQL Server components. Not doing this can cause problems with future installations.

This guide only covers installation. It doesn't include security, best practices, or database configuration. You'll want to look at other resources to learn about those important topics. With installation complete, you're ready to start using SQL Server 2022 for creating databases or migrating existing ones.

If you run into issues, search for the error code before asking for help. Most installation problems have known solutions that you can find online.

You're all set!

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 managing SQL Server. SSMS is essential for Database Administrators who need to write T-SQL and analyze execution plans. Developers often use SSMS too, though there are Visual Studio Code plugins like this one. These don't provide the same experience as SSMS. I prefer SSMS over Visual Studio Code since I do more DBA work than development.

Downloading SSMS

You can always find the latest SSMS version on Microsoft's official website. To get the most current release, visit the SQL Server Management Studio download page.

Just click the Download SQL Server Management Studio (SSMS) link to start downloading the installer (SSMS-Setup-ENU.exe). This file has everything needed for installation.

Installing SSMS

When the download finishes, go to where you saved the installer. Right-click the SSMS-Setup-ENU.exe file and choose Run as Administrator to start installing. If asked, click Yes to let the program make changes to your system.

The installation wizard opens with a few simple steps:

Choose Installation Location: SSMS installs in Program Files by default, but you can change this if you want.
Click Install: After picking your location, click Install to begin.

Installation usually takes a few minutes to half an hour, depending on your computer. Be patient and let it finish.

Post-Installation

When installation is done, you'll see a message confirming SSMS installed successfully. You can now open SSMS from the Start Menu or by searching for it.

You usually don't need to restart, but if you have problems or see a restart prompt, it's best to restart your computer.

Next Steps

With SSMS installed, you can now manage SQL Server instances, run queries, and configure settings. This guide only covers installation. For connecting to remote servers, database setup, or security practices, you'll need to look at other resources.

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

Thu, 25 Jul 2024 00:00:00 GMT

Introduction

Recently I encountered a situation while migrating a database to a new SQL Server instance where the instance collation differed from the database collation, causing tempdb to become unusable. This discrepancy made tempdb unusable and caused JOIN, ORDER BY, GROUP BY, and other operations to fail. With a deadline to migrate these applications, I decided to rebuild the instance collation to match the new application databases.

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 proceeding, I backed up everything that would be lost due to the rebuild, including SQL logins, jobs, alerts, linked servers, and permissions. Ensuring recent backups of all databases is important for this process.

SQL Server Configuration

To save the current SQL Server settings, I ran the following script and saved 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 removed during the rebuild. Save the results to a folder dedicated to the rebuild process.

Script Logins and Permissions

SQL Logins need to be extracted, along with users and roles. I used the following script to create two stored procedures that help export the logins. I found these stored procedures on Microsoft's official website which explains this process.

EXEC sp_help_revlogin

I then executed the stored procedure to generate a script to create SQL Logins, which I saved to my REBUILD folder:

Script Msdb Objects

All steps in this section are optional, so only complete what you need. In my case, I needed to copy SQL Jobs, Alerts, and Operators. If you have Linked Servers, Endpoints, Extended Events, or db_mail, now would be the time to copy those configurations. I did this by expanding the SQL Server Agent in Object Explorer, selecting the Jobs folder, then pressing F7 to open Object Explorer Details. From there I highlighted the jobs I wanted and scripted them to a file in my REBUILD folder. I repeated these steps for Alerts and Operators.

Script Master Objects

Again, the following steps are optional and depend on how the SQL 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 together, to the REBUILD folder.

Rebuilding the System Databases

After completing those steps, I moved on to rebuilding the system databases. This step requires downtime. Log in to the database server and find your setup.exe file for SQL Server. I found mine in C:\Program Files\Microsoft SQL Server\160\Setup Bootstrap\SQL2022. I opened a CMD prompt and changed to that directory, then ran the following command:

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

Optionally, Microsoft has a list of additional parameters you can specify in your 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 completed, 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.