This is such a common issue because the default locations are set to C for these databases and that’s where they end up on fresh installs 99% of the time. Don’t worry! If you’re in this situation you’re not alone.

Not sure? Let’s check if you have this problem:

Source code

SELECT
 
db.name AS database_name,
 
mf.name AS logical_name,
 
mf.physical_name AS file_path,
 
LEFT(mf.physical_name, 3) AS drive,
 
mf.type_desc AS file_type,
 
CAST(mf.SIZE * 8.0 / 1024 AS DECIMAL(10,2)) AS size_mb
 
FROM sys.master_files mf
 
JOIN sys.databases db ON db.database_id = mf.database_id
 
WHERE db.database_id <= 4 -- system databases: master, tempdb, model, msdb
 
ORDER BY db.name, mf.type_desc;

The output will look something like this. As you can see, this server has all system databases on C:

So let’s go ahead and fix this.

This process can be scary the first handful of times you do it. But don’t worry! As long as we prepare properly we shouldn’t have any problems and it’ll go smooth as butter.

One very important thing to note is that fixing this will require turning off the SQL Server instance so none of your databases will be available while we do this. You’ll definitely need to do this during a maintenance window.

How to fix?

On my server I have this drive layout. Please note your specific setup.

Our starting recommendation is to have three separate drives for database files: A data drive, a log file drive and a drive for tempdb. The last one is important because tempdb is an absolute spaghetti mess internally and deals with all of the stuff on your server that the other databases don’t want to deal with. It tends to be the most busy drive so we want to separate it from our other databases. Otherwise there will be arguments, like a house full of cats.

Considering the layout I have here (in above image), I’m going to move my tempdb files to the X drive, the other .mdf (data) files are going to R and the .ldf (log) files are going to L.

SQL Account server permissions

One very important thing is to check the SQL Service account has access to the file locations that we’re moving to. Note: This is not your account, this is the SQL Account. You can check this in configuration manager or in the services app:

We want to navigate to the Windows folder and ensure that this account has full control of the folder. It’ll need to read/write and also create new database files.

If you try starting the instance and you haven’t done this, you’ll get errors like this in the log:

Skip this step at your peril!

Moving the Master

The master database is different to all other databases as you can’t move this with an ALTER DATABASE command; it has to be done in SQL Server Configuration Manager.

Once you have the config manager open, navigate to SQL Server Services -> SQL Server -> right click and choose Properties:

In here, navigate to our startup parameters. We’ll have at least three options (there may be more), and these are the three we care about for this process:

• -d: This is the master.mdf (data) file location
• -l: This is the master.ldf (log) file location
• -e: This is the SQL Server error log output location. We will not be changing this but definitely take a note of this location. If, at the end of this process, the SQL Server refuses to start up, we’ll want to dig into the log files here to find out what’s happening.

To tell SQL Server where we want to move master to, you’ll want to change the file locations to your new filepath by highlighting it and changing the file path from within the “Specify a startup parameter” window and hitting Update. Once you’ve done both file locations and they reflect the new locations in the ‘Existing Parameters’ window, we’re golden.

Once you save you’ll get this window:

This is important to understand. We haven’t moved anything yet, we’ve just told SQL Server where they will be. Remember, these are startup parameters so that’s when the check will be run for the location.

Other System Databases: msdb, model, tempdb

These ones we can do from within SSMS, so let’s take the query below, replace the parameters with your new filepaths, and hit execute. This won’t do anything other than create the scripts. You’ll have to execute them manually (don’t worry!).

Source code

DECLARE @NewDataFilepath NVARCHAR(4000) = 'R:\'
 
,@NewLogFilepath nvarchar(4000) = 'L:\'
 
,@NewTempdbFilepath nvarchar(4000) = 'X:\'
 
SELECT
 
db.name AS database_name,
 
mf.name AS logical_name,
 
mf.physical_name AS file_path,
 
mf.type_desc AS file_type,
 
CASE WHEN db.name = 'tempdb' THEN 'ALTER DATABASE [' + db.name + '] MODIFY FILE (NAME = ' + mf.name + ', FILENAME = ''' + @NewTempdbFilepath + REVERSE(LEFT(REVERSE(mf.physical_name), CHARINDEX('\', REVERSE(mf.physical_name)) - 1)) + ''' )'
 
WHEN mf.type_desc = 'ROWS' THEN 'ALTER DATABASE [' + db.name + '] MODIFY FILE (NAME = ' + mf.name + ', FILENAME = ''' + @NewDataFilepath + REVERSE(LEFT(REVERSE(mf.physical_name), CHARINDEX('\', REVERSE(mf.physical_name)) - 1)) + ''' )'
 
WHEN mf.type_desc = 'LOG' THEN 'ALTER DATABASE [' + db.name + '] MODIFY FILE (NAME = ' + mf.name + ', FILENAME = ''' + @NewLogFilepath + REVERSE(LEFT(REVERSE(mf.physical_name), CHARINDEX('\', REVERSE(mf.physical_name)) - 1)) + ''' )'
 
END AS AlterDatabaseCommand
 
FROM sys.master_files mf
 
JOIN sys.databases db ON db.database_id = mf.database_id
 
WHERE db.database_id <= 4 -- system databases: master, tempdb, model, msdb
 
AND db.name <> 'master'
 
ORDER BY db.name, mf.type_desc;

The output will look something like this:

The very important part here is to ensure the new file locations match the actual new locations exactly otherwise you’re going to take your server down and not be able to get it back online.

Once you’re sure the locations are correct, copy the AlterDatabaseCommand column into a new query window, check the new filepaths thoroughly again, and then hit execute. You’ll get a message similar to this in the messages result window:

Once we’ve done this, we’ve told SQL Server the new file locations for our system databases.

Stopping the instance and moving files

Now that we’ve told SQL the new file locations, we need to go ahead and actually move the files. To do that, we’ll need the SQL Server instance to be stopped. Otherwise, the files will be locked (and remember, these are startup parameters)

Head back into configuration manager, find the SQL Server and hit ‘Stop’:

You’ll also have to give the go ahead to stop related services:

Moving the Database Files

From this point you can actually move all of our database files to the new file locations in Windows. Go ahead and move the master, model and msdb data and log files to the new locations.

You don’t need to move any of the tempdb files. These are created automatically when the SQL instance starts up so the old ones will no longer be used. As a best practice, you should delete your old tempdb files if they still exist in order to reclaim the disk space.

Remember to enable ‘View file name extensions’ in Windows Explorer so you are sure which file you’re moving to which location.

Starting SQL Server

At this point we need to restart the service, head back to configuration manager, and start the SQL Server service:

Hopefully you’ll see this screen with the services running as planned:

Remember to manually start any services (cough SQL Server Agent cough) that we had to shut down in order to stop the SQL Server service.

As long as they all start you’re golden, you can skip down to the bottom of this article to run our final checks.

SQL Server Start Failing

If SQL won’t start, don’t worry, we can fix that!

Go to the log file location from the beginning of this process and open the ERRORLOG file:

Open this one (it’s a text file so notepad is fine) and scroll to the bottom. It tells you exactly what the problem is:

In this instance, there was an access denied error (intentional for this demo, promise 😊) which I fixed by giving permission to the SQL Server service account to those individual files. We don’t have enough space in this blog post to be able to explain every problem you may encounter, but you’re a grown up, you can work it out (or go use your Google fingers furiously like the rest of us).

Final Checks

Let’s run our original script to find the locations of our system database files (your query window will ask you to reconnect to the server, this is just because we’ve restarted it).

Happy with these file locations? Great! You have a job well done, be proud of yourself!

Now, go tell your boss how good you are at your job and go for a lay down while your heart rate returns to normal.

The post Moving System Databases: A How-To appeared first on SQL Solutions Group.

They’ve been a fully supported option for SQL Server since 2014, they work with Failover Cluster Instances and Availability Groups, and Active Directory rotates the passwords for you on a schedule you control. We use them by default on every new SQL Server build at SSG.

And yet, in a decade of Health Checks, we still rarely see them deployed. The most common reasons we hear: “I tried it once and SPNs broke,” or, “I wasn’t sure it would work with our AG.” Both are addressable. Here’s what you need to know to deploy gMSAs successfully.

Why gMSAs Win

A gMSA is an Active Directory account whose password is generated by the Key Distribution Service (KDS), rotated automatically (default every 30 days), and retrievable only by computer accounts you explicitly authorize. That gives you four things:

• Passwords you don’t know, can’t leak, and can’t forget to rotate. The password is 240 bytes of cryptographic randomness. No human ever sees it.
• No service restart on rotation. When AD rotates the password, the SQL Server service keeps running. This is the part most people don’t believe until they see it.
• Automatic SPN management. The account can register and update its own Service Principal Names, eliminating one of the most painful manual chores in Kerberos troubleshooting.
• Cluster-aware. Unlike standalone Managed Service Accounts (sMSAs), a gMSA can be used by multiple computers, which means it works for Failover Cluster Instances and Availability Group replicas.

If you’re still managing SQL Server service accounts as regular AD user accounts with a 90-day password expiry policy and a coordinated change window, you’re doing work that AD will do for you free.

Prerequisites

Before you create your first gMSA, the domain needs a KDS root key. This is a one-time, domain-wide setup step. By default, AD enforces a 10-hour wait after key creation before the key becomes usable, which is a safety mechanism to ensure replication completes across all domain controllers.

Source code

# On a domain controller (or any machine with AD module)
# Production: just run this and wait 10 hours
Add-KdsRootKey -EffectiveImmediately
 
# Lab/test only: bypass the 10-hour wait
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Verify a key exists before proceeding:

Source code

Get-KdsRootKey

You also need:

• Windows Server 2012 or higher on the SQL Server hosts (we strongly recommend 2019+)
• SQL Server 2014 or higher (every supported version qualifies)
• The RSAT Active Directory PowerShell module on whichever machine you’re using to create the accounts

Account Structure: One Per Service, Per Server (Mostly)

The pattern we deploy at SSG: a separate gMSA for each SQL Server service type (Database Engine, SQL Agent, SSRS, SSAS) on each standalone server. For clustered services — FCIs and AG replicas — we use a single gMSA shared across all nodes in that cluster.

Why separate accounts per service type? Least privilege. Your SQL Agent account often needs different rights than your Database Engine account (proxy operations, file system access for job output, etc.). Putting them on the same account means you grant the union of all permissions to both, which is exactly what we’re trying to avoid.

Why a single account across cluster nodes? Because all nodes need to authenticate as the same identity to the network. The whole point of an FCI or AG is that clients connect to a virtual name that can move; the underlying service identity must be consistent.

A naming convention that holds up over time:

Heads up: gMSA sAMAccountName is capped at 15 characters (with a $ suffix that AD adds automatically). Long server names will collide with this. Plan your naming convention before you start creating accounts. That is why the suggested naming convention above does not have a lot of extra fluff like gmsa_svc_sql_<server> or the like. Every gmsa account will have a $ at the end so that’s how it is clear that it is a service account and is a gmsa.

Creating the Account

Two-step process: create an AD security group containing the computer accounts that will use the gMSA, then create the gMSA itself referencing that group. The security group is the indirection layer that makes gMSAs cluster-friendly — adding a new node to an FCI or AG later means adding its computer account to the group, not creating a new gMSA.

Source code

# 1. Create the security group, add computer accounts
New-ADGroup -Name 'gsg_SQL_PRODAG01' \
    -GroupScope Global -GroupCategory Security \
    -Path 'OU=Service Groups,DC=contoso,DC=com'
 
Add-ADGroupMember -Identity 'gsg_SQL_PRODAG01' \
    -Members 'SQLNODE01$','SQLNODE02$','SQLNODE03$'
 
# 2. Create the gMSA
New-ADServiceAccount -Name 'SQLEng_PRODAG01' \
    -DNSHostName 'PRODAG01.contoso.com' \
    -PrincipalsAllowedToRetrieveManagedPassword 'gsg_SQL_PRODAG01' \
    -ManagedPasswordIntervalInDays 30 \
    -ServicePrincipalNames @(
        'MSSQLSvc/PRODAG01.contoso.com',
        'MSSQLSvc/PRODAG01.contoso.com:1433'
    ) \
    -Path 'OU=Service Accounts,DC=contoso,DC=com'
 
# 3. Reboot each node OR run gpupdate /force + klist purge -li 0x3e7
#    so the computer picks up its new group membership

That last step is the one most people skip and then spend an hour debugging. Computer Kerberos tickets are issued at boot. Adding a computer to a new security group requires a reboot or a TGT refresh before the computer can retrieve the gMSA password.

Then on each SQL Server host:

Source code

# Install the AD PowerShell module if not present
Install-WindowsFeature RSAT-AD-PowerShell
 
# Install and verify the gMSA on this host
Install-ADServiceAccount -Identity 'SQLEng_PRODAG01'
Test-ADServiceAccount -Identity 'SQLEng_PRODAG01'   # must return True

Test-ADServiceAccount returning True is the gate. If it returns False, do not proceed to the SQL Server side — the problem is upstream in AD or group membership.

Assigning the gMSA to SQL Server

Use SQL Server Configuration Manager. Always. Not services.msc, not Server Manager, not the Services snap-in. SQL Server Configuration Manager grants the necessary local rights (Log on as a service, Lock pages in memory, file system ACLs, registry ACLs) automatically. The other tools don’t, and you’ll spend the rest of your afternoon figuring out why SQL Server won’t start.

In Configuration Manager: right-click the SQL Server service, Properties, Log On tab, enter CONTOSO\SQLEng_PRODAG01$ in the account name field. Two things to remember:

• Always include the trailing $. This is how Windows distinguishes a managed service account from a regular user account.
• Leave the password fields blank. If you type anything in them, the dialog will reject the save.

Repeat for SQL Agent, SSRS, etc., each with its own gMSA. Then restart the services.

Availability Groups and FCIs: The Extra Step

For Always On Availability Groups, after switching the Database Engine service to a gMSA, you need to grant the new account CONNECT permission on the HADR endpoint on every replica. This is the step that breaks AGs silently — the cluster looks fine, but synchronization stops.

Source code

USE master;
 
GO
 
CREATE LOGIN [CONTOSO\svc_SQL_PRODAG01$] FROM WINDOWS;
 
GRANT CONNECT ON ENDPOINT::Hadr_endpoint TO [CONTOSO\svc_SQL_PRODAG01$];
 
GO

Run that on every replica. If you forget one, the missed replica will fall out of sync the moment its old service account credential expires.

For FCIs, no equivalent step is needed — the gMSA is just the service account, and the cluster resource picks it up.

Deploying at Scale with dbatools

If you’re rolling gMSAs across an estate, do it with dbatools. The Update-DbaServiceAccount command handles the local rights assignment correctly — same as Configuration Manager, but scriptable across many servers in a single pipeline.

Source code

# Switch the Database Engine on a list of servers to a gMSA
$instances = 'SQLNODE01','SQLNODE02','SQLNODE03'
 
Get-DbaService -ComputerName $instances -Type Engine |
    Update-DbaServiceAccount -Username 'CONTOSO\SQLEngPRODAG01$'
 
# Verify it took
Get-DbaService -ComputerName $instances -Type Engine |
    Select-Object ComputerName, ServiceName, StartName, State

Note the lack of a -Password parameter. dbatools detects the trailing $ and treats the account as a managed service account, skipping the password prompt entirely. This is the kind of small touch that makes dbatools the right tool for this job.

Common Pitfalls and How to Diagnose Them

“Cannot generate SSPI context”

This is the canonical Kerberos failure. After switching to a gMSA, clients can’t connect via Kerberos and either fall back to NTLM (slow, less secure) or fail outright. The cause is almost always SPN-related — either the SPNs didn’t transfer to the gMSA, or duplicates exist on the old account.

Diagnose:

Source code

# Check what authentication SQL is using
SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;
-- Should return KERBEROS, not NTLM
 
# Find any SPN registered for your SQL service
setspn -Q MSSQLSvc/PRODAG01.contoso.com
setspn -Q MSSQLSvc/PRODAG01.contoso.com:1433
 
# Find duplicates (these break Kerberos entirely)
setspn -X

Fix: remove SPNs from the old service account, ensure they’re on the gMSA. If you registered SPNs in the New-ADServiceAccount command, AD will refresh them automatically going forward — that’s the gMSA SPN management benefit. If you didn’t, register them manually now and let AD take it from there.

Linked servers and cross-server delegation

If your SQL Server uses linked servers configured for Windows authentication pass-through, you need Kerberos delegation set on the gMSA. In AD Users and Computers, the gMSA must be configured for constrained delegation to the target SQL Server’s MSSQLSvc SPN. This is the same requirement as for any service account — gMSAs don’t change it — but it’s worth checking before you migrate, because constrained delegation settings don’t migrate automatically when you change accounts.

Service won’t start after the switch

Almost always one of:

• The gMSA wasn’t installed on the host (skipped Install-ADServiceAccount)
• The computer account isn’t in the security group (or wasn’t rebooted after being added), or
• The account was assigned via the wrong tool and didn’t get Log on as a service.

The error in the event log is usually generic; the diagnostic order is: confirm Test-ADServiceAccount returns True, confirm group membership, redo the assignment via Configuration Manager.

When Not to Use a gMSA

Two scenarios where we don’t recommend gMSAs:

• Servers in domains where you don’t control the KDS root key. You’ll need a Domain Admin to create that one-time. If your AD team won’t, it’s a non-starter.
• Cross-forest scenarios. gMSAs do not work across AD forest boundaries. If your SQL Server needs to authenticate to resources in a different forest, you need a regular service account or a different design.

Bottom Line

gMSAs are the right default for service accounts on any domain-joined SQL Server built in the last decade. The setup overhead is real but one-time. The ongoing operational savings — no password rotations, no expiry surprises, no “who has the spreadsheet of service account passwords” conversations — pay for it many times over.

If you’re standing up a new SQL Server in 2026 and you’re not using a gMSA, you should have a specific reason why. “We’ve always done it this way” isn’t one.

Need help rolling gMSAs out across an existing estate?

SSG has done this dozens of times across customer environments — including the messy migrations from legacy service accounts on production AGs. Get in touch with us and we’d be happy to support you.

The post Group Managed Service Accounts and SQL Server: What You Actually Need to Know appeared first on SQL Solutions Group.

But here’s the reality: SQL Server 2016 has reached end of life. And that shouldn’t be ignored.

What “End of Life” Actually Means

When Microsoft ends support for a product, it’s not just a technical milestone—it’s a risk shift. The list of ‘cons’ becomes much longer than the list of  ‘pros’ when deciding if an upgrade is neccesary yet, or if you can put it off another year. 

Officially SQL Server 2016 will have:

• No more security updates

• No bug fixes or patches

• No official Microsoft support

• Increased exposure to vulnerabilities and compliance risks

Even if your system seems stable today, it’s now operating without a safety net. And in today’s environment, that’s a serious concern.

The Hidden Cost of Staying Put

Delaying an upgrade might feel like the easier (and cheaper) option—but it often comes with hidden costs such as security risks, compliance issues, performance limiations and the need for emergency migrations.

Without ongoing patches, your database becomes more vulnerable to attacks, especially ransomware targeting outdated systems. Many industries require supported software. Running end-of-life systems can put you out of compliance with security standars. Older systems miss out on years of performance improvements, optimization features, and efficiency gains. Waiting too long often leads to rushed, reactive upgrades after a failure or breach—which are far more expensive and disruptive.

What You Gain by Upgrading

Moving to a modern platform like SQL Server 2025 isn’t just about staying supported, it’s about unlocking better performance, resilience, and flexibility. Newer versions bring query optimization, smarter resource usage, and faster processing, improving overall performance. There’s also some exciting new ways to make backup recovery smarter like: 

• True full and differential backups on secondary replicas

• Improved compression with ZSTD

• Immutable backup storage options

The new upgrade also means stronger security and cloud-ready flexibility. Modern encryption, threat detection, and tighter integration with cloud security tools help protect your data. And easier integration with Azure and hybrid environments gives you more options for scaling and disaster  recoverry.

Migration Doesn’t Have to Be Overwhelming

One of the biggest reasons businesses delay upgrading is fear of disruption. Downtime, data loss, compatibility issues, etc.  But with the right strategy migrations can be smoooth, controlled, and predictable.

A well executed upgrade includes:

• A full assessment of your current environment

• Compatibility and workload analysis

• A clear migration plan with rollback options

• Testing before going live

• Minimal downtime during cutover

How We Help

We specialize in helping businesses move from outdated systems to modern, optimized environments—without the chaos.

Our approach focuses on:

✔️ Safe, secure data migration

✔️ Minimal disruption to your operations

✔️ Performance tuning post-upgrade

✔️ Modern backup and recovery setup

✔️ Long-term scalability and support

Whether you’re running a single database or a complex environment, we make the transition manageable and worth it.

Ready to Modernize Your SQL Environment?

If you’re still on SQL Server 2016, now is the time to act. Let’s build a plan to upgrade your system, migrate your data safely, and set you up with a faster, more secure, and more resilient environment.

Reach out today to start your upgrade the right way.

The post Still Running SQL Server 2016? Here’s Why It’s Time to Upgrade appeared first on SQL Solutions Group.

I will go through a couple of common scenarios that we frequently encounter and give T-SQL and PowerShell solutions.

Is Max Memory Set Appropriately?

Let’s start small: Finding max memory values and evaluating if they are appropriate.

T-SQL Script:

Source code

SELECT mem.total_physical_memory_kb / 1024 'server memory (MB)'
 
,configs.value_in_use 'max server memory (MB)'
 
FROM sys.dm_os_sys_memory mem
 
cross apply (
 
SELECT value_in_use
 
FROM sys.configurations
 
WHERE name = 'max server memory (MB)'
 
) configs

T-SQL Results:

With that information, I can make a determination if Max Memory is set appropriately. If not, I can calculate an appropriate value and go implement the change.

PowerShell Script:

Source code

Test-DbaMaxMemory -SqlInstance SSG-LT-KBURWELL

PowerShell Results:

Again, this is a basic example, and the T-SQL isn’t exactly complex, but the PowerShell is much easier and even gives you a recommendation for Max Memory.

LastFullBackup

The T-SQL for this is also rather easy, but the tricky part is running it against multiple instances and returning a single result set.

T-SQL Script:

Source code

SELECT database_name
 
,MAX(backup_start_date) latest_full
 
FROM msdb.dbo.backupset s
 
WHERE s.type = 'D'
 
GROUP BY s.database_name

T-SQL Results:

As I mentioned, this is a very simple script, but this is only for one instance. If you want to run this against multiple instances, you will need to do some additional setup, such as configuring linked servers or a Central Management Server, neither of which I will be detailing here. Instead, I will show how easy it is to query multiple instances in PowerShell.

PowerShell Script:

Source code

Get-DbaLastBackup -SqlInstance SSG-LT-KBURWELL

PowerShell Results:

One simple command and I get the same info, plus details for latest diff and log backups as well. Now let’s make a couple of changes so we can get results for multiple instances and make the output a little more friendly.

PowerShell Script:

Source code

Get-DbaLastBackup -SqlInstance SSG-LT-KBURWELL,SSG-LT-KBURWELL\MSSQLSERVER01 -ExcludeDatabase msdb,model,master | Format-Table

I made 3 minor changes to the script, but it is still a single line of code and now reads from multiple instances and formats the output as a table.

• Change 1: Added an additional SQL instance to the -SqlInstance parameter.
• Change 2: Added the -ExcludeDatabase parameter and passed in the system databases.
• Change 3: Piped the results to Format-Table

PowerShell Results:

Let’s take it one step further and generate a spreadsheet from the results.

PowerShell Script:

Source code

Get-DbaLastBackup -SqlInstance SSG-LT-KBURWELL,SSG-LT-KBURWELL\MSSQLSERVER01 -ExcludeDatabase msdb,model,master | Export-Excel -Path C:\Temp\LastBackups.xlsx

Instead of piping the results to Format-Table, I am piping the results to Export-Excel and providing a file path and name. Now I have a spreadsheet that I can share with whomever might want to see it.

Getting results from SSMS into Excel is obviously possible, it just requires extra manual steps. It’s much quicker to just have PowerShell do it for you.

“It’s easier”

When I say PowerShell is easier, I’m not just talking about the simplicity of commands. I’m also talking about how easy it is to add in functionality, such as querying multiple instances, combining the results, and exporting them to Excel.

If you are perfectly happy using T-SQL and SSMS, then by all means, continue to do so. But, I do encourage you to explore PowerShell, specifically the DBATools module. I will be following up this post with more complex Powershell examples such as copying databases between SQL instances and keeping AG objects synchronized between replicas. Stay tuned for more answers to the question “why use PowerShell?”

The post Why use PowerShell when you can use T-SQL? appeared first on SQL Solutions Group.

True Full and Differential Backups on Secondary Replicas

For years, database professionals faced a frustrating limitation. With Availability Groups, you could offload some workloads to secondary replicas—but not your real backup strategy.Yes, you could run copy-only backups on a secondary. But true full backups? Differential backups that maintain the LSN chain? Those had to run on the primary replica, until now. SQL Server 2025 introduces the ability to run true full backups and true differential backups on secondary replicas.

That means:

• You can move your entire backup workload off the primary.

• Your backup plan behaves exactly the same as if it were running on the primary.

• You potentially reduce your RPO by running backups more frequently.

This isn’t just a convenience feature—it’s a performance and resilience upgrade.

ZSTD Backup Compression

Another enhancement is the introduction of ZSTD backup compression, an algorithm originally developed at Facebook. Until now, SQL Server used MSXpress as the default compression method. ZSTD brings:

• Slightly better compression ratios

• Faster compression in many cases

• Less CPU overhead during decompression

• Potentially faster restores

In Randy’s testing—and in benchmarking done by Aaron Bertrand on an 8TB Stack Overflow database—backup sizes weren’t dramatically smaller. A 50GB database might shrink from 15GB to 14.5GB. That doesn’t sound revolutionary, but at scale it really adds up!

If you’re backing up multi-terabyte databases with long retention periods, even small savings compound quickly. Smaller backups also mean improved storage efficiency and potential restore performance gains. It’s not flashy—but it’s practical, which matters. 

Immutable Backups in Azure Blob Storage

Backing up directly to Azure Blob Storage isn’t new. But SQL Server 2025 now supports backups to immutable Azure Blob storage accounts.This enhancement strengthens ransomware protection. Immutable storage ensures that once a backup is written, it cannot be modified. The only permitted action is deletion under defined rules. While not truly air-gapped, this approach creates a powerful safeguard against backup tampering. In a world where ransomware targets backups first, this feature significantly improves recovery confidence.

Why These Enhancements Matter

SQL Server 2025 doesn’t reinvent backup strategy—it strengthens it.

• Offload backup workloads to secondary replicas

• Improve compression efficiency at scale

• Harden backup security against ransomware

Individually, these updates are incremental. Together, they represent a meaningful evolution in database resilience and performance. For organizations running mission-critical systems, that’s an especially big deal.

The post Backup Just Got Smarter: What’s New in Microsoft SQL Server 2025 appeared first on SQL Solutions Group.

Problem Statement

The client noticed the D (data) drive was running out of free space and they asked us to investigate. We found that the SQL Logs folder was much larger than we’d expect. A considerable amount of this data was not database files (.mdf, .ldf, .ndf), but rather log files (.log and anything with a .Number file extension):

Upon further investigation we could see that there were a large number of files starting with SQLFT%. These are full text error files:

At this point we knew the culprit and had to dig into our full text indexes.

Investigation

SQL Error Log

If you also check your SQL Error log in SSMS, you will likely see a constant stop and restart of the Full-Text process:

If we want specific details around which table/index is causing issues, we will have to check the Full-Text error log directly.

Reading Your Full-Text Error Log

There’s no GUI way of reading the Full-Text error log in SSMS. To do that, you’ll have to read the file off disk directly. And for that, you’ll need xp_cmdshell enabled, as follows:

Source code

EXEC SP_CONFIGURE 'show advanced options', 1;
RECONFIGURE;
EXEC SP_CONFIGURE 'xp_cmdshell', 1;
RECONFIGURE;

You can then read this file (and any others) using the query below:

Source code

EXEC xp_cmdshell 'type "D:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Log\FDLAUNCHERRORLOG"';

The potential challenge here is: if you’ve got an issue with Full-Text then this file has the potential to be very large (in this scenario, it was 2.4GB). A file of that size may well make this approach prohibitive.

Manually Reading the Error Log

You won’t be able to open the FDLAUNCHERRORLOG file directly if it’s in use with SQL Server so in this case you will have to take a copy of the file and read the copy. However, there are file size limitations with tools such as Notepad. You will need to use an application that can deal with these large files (VScode, Notepad++, etc.) or something that’s specifically designed to open large text files (Large Text File Viewer, KLOGG, etc).

If you need to copy this text file to a different server, I highly recommend zipping the file first. The files are often multiple GB but because it’s a lot of repeated data, they compress really well. It’ll save you a bunch of time in data transfer over your network.

Error Log Output

Once you’re able to read the error log, you will see an output like this which gives you the specific table or indexed view which is the issue here:

This is where (at least one) of our issues are. It’s worth noting that there may well be more than one object involved here. We’re looking for the largest culprit, but once we that one we may well have others that will require our attention. We’ll deal with that when we come to it, though.

Remediation

Rebuilding Full-Text Catalogue

The first thing we want to do is to rebuild our Full-Text catalogue for the affected database. You can easily do this in SSMS:

A rebuild should fix the issue. But if not, you’ll have to go to the next step.

Rebuilding Indexes

Luckily, in our scenario the table involved was small so this wasn’t a concern. However, rebuilding indexes comes with the dual caveats that, in larger environments, it can take a long time to complete a rebuild, and it will also consume resources and may potentially cause blocking. In this scenario, you’ll want to do this out of hours or inside a maintenance window.

An important note here: We’d recommend just rebuilding the clustered index if you have one. By doing this, the system will automatically rebuild all other indexes on the table. You can do this using the GUI:

If you’re more comfortable working with code, then you can perform this manually too:

Source code

ALTER INDEX [IndexName] ON [dbo].[TableName] REBUILD

Once this is rebuilt (and assuming it returns without errors), you should be golden. You then want to follow the process below to allow you to cycle the log files.

Cycling your Full-Text Log Files

There is an undocumented stored procedure that lets you cycle your Full-Text log files the same way you are (hopefully) cycling your SQL Error Logs:

Source code

EXEC sp_fulltext_recycle_crawl_log @ftcat = ‘FullText CATALOG Name;

This will deallocate the old log files and create new ones. At this point you’re free to delete or move these log files that are filling the drive to free up the disk space. And don’t worry: If you try to delete a file that’s currently in use by SQL Server (the current log files, for example) you won’t be able to.

Cycling your Full-Text master error log

There is no way of doing this within SSMS. You can do it with this command:

Source code

EXEC sp_fulltext_service 'cycle_errorlog';

This will allow you to cycle out this error log, too, if you need to delete the file to free up space.

At this point, we have fixed the full text indexes on this database. We may, however, have issues with multiple databases. If we check the SQL Error log and see new errors appearing, then we haven’t quite fixed the whole problem. We will want to go through this process again (check the logs, rebuild indexes, cycle error log files) until we’ve fixed all our problems.

DBCC CHECKTABLE

Once we’ve fixed all the issues with Full-Text search it’s a great idea to perform a DBCC CHECKTABLE on the affected tables to ensure we’re not dealing with a corruption issue. CHECKTABLE is much lighter than a full CHECKDB, but it still does read the entire table  to perform the check. Yes, this is another process that we would want to be careful and perform outside of working hours if at all possible if the table we’re dealing with is large in our environment.

Source code

USE [DBName]
 
GO
 
DBCC CHECKTABLE (‘TableName’) WITH WITH ALL_ERRORMSGS, NO_INFOMSGS

This will return any errors encountered while also avoiding any noise from informational messages.

You can see the output in the error log:

Final Thoughts

If you discover corruption, review this post I wrote on the topic. If you don’t, you should be good to go — and give yourself a pat on your back for a job well done!

And, if you find you can’t solve a Full-Text index issue yourself, we’re always standing by to assist you.

The post Fixing Full-Text Index Issues appeared first on SQL Solutions Group.

SQL Server 2025 continues Microsoft’s steady focus on performance, reliability, and intelligent automation. Rather than introducing one dramatic overhaul, this release delivers a collection of meaningful, incremental improvements that—when combined—can result in noticeable gains for many workloads.

During a recent discussion, Rich and Kyle walked through several of the most impactful enhancements, focusing on Intelligent Query Processing, concurrency improvements, columnstore indexes, and long-awaited TempDB upgrades.

Smarter Query Performance with Intelligent Query Processing (IQP)

Intelligent Query Processing isn’t new, but SQL Server 2025 refines it further. IQP is an umbrella term covering a set of features designed to make the query optimizer more adaptive and accurate over time.

One key area of improvement is cardinality estimation—the process SQL Server uses to estimate how many rows will flow through each step of a query plan. Anyone who has tuned performance knows how damaging a mismatch between estimated and actual rows can be. SQL Server 2025 introduces incremental enhancements to these estimations, which, in most cases, translate to better execution plans and improved default performance without any code changes.

As with any optimizer change, edge cases still exist. Large jumps in behavior—such as the one between SQL Server 2014 and 2016—sometimes caused regressions in specific workloads. While the changes in 2025 are far less dramatic, testing remains essential when upgrading.

Another IQP enhancement is parameter-sensitive optimization, which addresses long-standing issues related to parameter sniffing. When query parameters vary significantly between executions, SQL Server can now better recognize those differences and adjust execution strategies accordingly, reducing performance instability.

Degree of parallelism (DOP) feedback also continues to evolve. Rather than making a one-time decision based solely on cost thresholds and configuration values, SQL Server now evaluates how well a query performs when running in parallel and adjusts its behavior over time. This allows the engine to fine-tune parallelism instead of blindly running at maximum settings. While powerful, it does require familiarity with execution plans to fully understand how SQL Server is adapting behind the scenes.

Adaptive Joins That Adjust on the Fly

Adaptive joins build on SQL Server’s ability to recover from imperfect statistics. Traditionally, SQL Server commits to a join strategy—such as nested loops or hash joins—based on cardinality estimates. If those estimates are wrong, the query can suffer dramatically.

With adaptive joins, SQL Server can change its mind mid-execution. If a join starts as a loop join but processes far more rows than expected, the engine can switch to a more appropriate join type, such as a hash join, while the query is still running.

SQL Server 2025 improves adaptive joins further, especially in complex scenarios involving multiple joins. This makes the engine more resilient in real-world environments where statistics are rarely perfect.

Improved Concurrency Through Smarter Locking

Concurrency is another area receiving meaningful attention. SQL Server has long relied on various lock types—row, key, page, range, and table locks—with relatively rigid thresholds for escalation.

Historically, modifying a few thousand rows could trigger escalation to a full table lock, leading many teams to design batch operations around that behavior. SQL Server 2025 is more nuanced. It can now hold thousands of locks without immediately escalating to a table lock when doing so would be unnecessary or harmful.

These optimized locking improvements, especially when combined with accelerated database recovery, have already shown dramatic reductions in blocking in real-world workloads. The engine is simply making better decisions about how much data truly needs to be locked.

Faster and More Efficient Columnstore Indexes

For organizations using columnstore indexes—particularly in data warehouse and analytics workloads—SQL Server 2025 brings performance gains across the board.

Compression is faster, index rebuilds complete more quickly, and the engine handles delta stores more efficiently. Delta stores, which temporarily hold newly inserted uncompressed data before it’s merged into compressed columnstore segments, are now managed more intelligently. This improves both data ingestion and query performance.

Reading from columnstore indexes has also been optimized, meaning analytics queries can run faster with no changes required at the application level.

TempDB Enhancements That DBAs Will Appreciate

TempDB has long been one of SQL Server’s most critical—and fragile—components. SQL Server 2025 introduces several enhancements that directly address common pain points.

One of the most significant changes is the ability to govern TempDB usage using Resource Governor. DBAs can now set quotas that prevent individual queries or workloads from consuming excessive TempDB space. When a query exceeds its limit, SQL Server cancels it before TempDB fills up, preventing server-wide outages.

This is especially valuable in environments where large reports or unfiltered queries can consume hundreds of gigabytes and bring systems to a halt—often in the middle of the night.

SQL Server 2025 also brings accelerated database recovery (ADR) to TempDB. Large rollbacks that previously took minutes can now complete almost instantly, reducing downtime and improving system responsiveness during heavy workloads.

To support monitoring and alerting, new DMV columns expose detailed TempDB usage metrics, including current usage, peak usage, and the number of TempDB limit violations. These additions make it far easier for DBAs and monitoring tools to detect issues before they escalate into outages.

A Practical Step Forward

Rather than reinventing SQL Server, the 2025 release refines the engine’s intelligence. Query plans adapt more effectively, locking decisions are smarter, analytics workloads run faster, and TempDB becomes far more manageable.

For teams considering an upgrade, SQL Server 2025 offers tangible performance and reliability improvements—especially for environments that struggle with concurrency, large analytical workloads, or TempDB pressure. As always, thorough testing is key, but for many workloads, the benefits will be felt immediately.

The post SQL Server 2025 Performance Enhancements: What Developers and DBAs Need to Know appeared first on SQL Solutions Group.

TempDB Space Governance

This is the big one. We’re going to do extensive testing on this, but it looks extremely promising. In SQL Server 2025, Resource Governor can now limit how much TempDB space a workload is allowed to use. That means:

• One bad report can’t eat all of TempDB
• ETL jobs can’t bully OLTP workloads
• You can finally put hard limits on temp space usage

Why this matters

You may have run into the issue where TempDB gets filled by somebody running a huge reporting query. This fills the TempDB drive and brings down the production server. Sometimes you can’t help users from being users. This is usually compounded in virtualised environments if you’re using something like the AWS Instance Store when you can’t increase the size of this drive other than increasing your instance size (and cost).

Before 2025, Resource Governor could manage CPU and memory, but TempDB was the Wild West. Now it’s fenced in.

If a workload hits its TempDB limit:

• The request fails
• TempDB stays healthy
• The rest of the server keeps working

Example: Limit TempDB usage for a workload group

Note: There are some requirements for your TempDB configuration:

Source code

-- Enable Resource Governor
 
ALTER RESOURCE GOVERNOR RECONFIGURE
 
GO
 
-- Create a workload group with a TempDB limit of 25%
 
CREATE WORKLOAD GROUP ReportingGroup
 
WITH (GROUP_MAX_TEMPDB_DATA_PERCENT = 25)
 
GO
 
ALTER RESOURCE GOVERNOR RECONFIGURE
 
GO

By doing this you prevent the new workload group we created for using more than 25% of the TempDB space.

Accelerated Database Recovery (ADR) in TempDB

ADR has been around for a while in user databases, but the fact that we can now use it on TempDB comes with some promising opportunities, but what is ADR exactly?

ADR is basically SQL Server’s way of cleaning up messes way faster. Instead of doing long painful rollbacks that make you stare at “rolling back transaction…” like it’s judging your life choices, ADR keeps a lightweight version store so SQL Server can undo work almost instantly.

That means cancelled queries don’t hang around forever, crash recovery is dramatically quicker, and the transaction log doesn’t balloon while SQL Server cleans up after a bad decision. Think of ADR as giving SQL Server an “undo” button that actually works.

What changes with ADR on TempDB?

• Cancelled queries clean up fast
• TempDB log truncates more aggressively
• Less waiting around for rollback to finish

If you’ve ever cancelled a big query and watched TempDB sit there bloated for minutes… yeah, this helps.

Enabling ADR for TempDB

It’s a simple command to enable ADR for any database:

Source code

ALTER DATABASE [tempdb]
 
SET ACCELERATED_DATABASE_RECOVERY = ON
 
GO

For tempdb, you’ll have to restart the SQL Service for this to take effect (because tempdb is recreated from scratch when you restart the SQL Service).

You can check whether ADR is enabled for tempdb by looking at sys.databases:

Source code

SELECT name, is_accelerated_database_recovery_on FROM sys.databases WHERE name = 'tempdb'

Why you should turn this on

TempDB is famously described as the public toilet of SQL Server, and this setting makes clean up a whole lot easier!

Fewer TempDB Headaches

SQL Server 2025 also brings a bunch of quieter improvements that indirectly help TempDB:

• Better memory grant feedback → fewer spills
• Smarter throttling for runaway queries
• Reduced contention under high concurrency

None of these are “headline features,” but together they mean:

• Less TempDB churn
• Fewer surprises
• Smoother performance under load

Final Thoughts

These are enhancements to TempDB in SQL Server 2025, rather than re-writes of the fundamentals.  Honestly, that’s a good thing. It gives you, as the DBA, extra control over tempdb on your servers and gives an overall better performing system. Definitely test these things in your test environment first though!

The post Enhancements to TempDB in SQL Server 2025 appeared first on SQL Solutions Group.

Does the integrity of your SQL Server databases keep you up at night? Is an outage of your system a matter of when and not if? Do you dread a call from the C-suite asking why everything is down? If your heart rate went up just reading those scenarios, you can see why an SSG SQL Server Health  isn’t a luxury but a necessity. Don’t leave your business continuity up to chance.

Everything Runs on Data

Data is the currency of business, and unplanned database outages don’t just disrupt IT.

Industry reports from Gartner, ITIC, and others show that the financial impact of IT and database outages has reached historic highs, with costs for large enterprises often exceeding $1 million per hour. Gartner’s historical baseline of $5,600 per minute (~$336,000 per hour) remains a widely cited metric, but 2025-2026 data shows this has escalated to approximately $9,000 per minute for many firms. U.S. companies suffer an average of one unplanned downtime incident per month.

These days, database failure is likely to halt operations, impact customers, interrupt sales, and put revenue at risk. It could also get someone fired.

Our SQL Server Health Check

Be proactive and find problems in your SQL Server instances before they blow up. A Health Check from SQL Solutions Group helps you identify risks and how to fix issues, as we test everything from hardware to hypervisor/cloud configuration to OS to your SQL Server installation itself. Once we complete a Health Check on your instances, you receive:

• A comprehensive, executive-ready risk report
• Prioritized remediation roadmap
• Practical recommendations aligned to your business goals

Health Check Take-aways

In other words, you’ll have a clear plan for getting your instances as healthy as possible. You can do that work yourself, or you can leverage our expertise to get it done. Our goal with each SQL Server Health Check is to:

• Restore confidence in your databases
• Reduce downtime
• Improve resilience
• Support uninterrupted business operations
• Reduce your stress
• Give you peace of mind

If SQL Server supports your core systems, a proactive health check is so much more than a useful technical exercise. It’s a risk-management and ROI decision. You can’t afford the risk to your databases because the problems won’t go away if you ignore them. Address your ticking timebombs before your phone rings when you least want it to with a Health Check from SQL Solutions Group.

The post Why a SQL Server Health Check isn’t a Luxury appeared first on SQL Solutions Group.

Getting Started

If you haven’t already, make sure you have DBATools installed. We are going to be using a command called Get-DbaDbFile to gather the information for us. This command only requires one parameter, -SqlInstance. Here is a snippet of what I get when I run it against my local dev instance:

This is a bit more information than we really need right now, so let’s trim it down and get some parameters added. For this script, we really only need SqlInstance, Database, TypeDescription, LogicalName, PhysicalName, Size, UsedSpace, and AvailableSpace. We can also exclude system databases from the result set. For readability, I am going to use Format-Table. I will also start to add in some parameters:

Source code

$SqlInstance = "SSG-LT-KBURWELL"
 
Get-DbaDbFile -SqlInstance $SqlInstance
 
Get-DbaDbFile -SqlInstance $SqlInstance -ExcludeDatabase master,model,msdb,tempdb |
 
    Select-Object SqlInstance, Database, TypeDescription, LogicalName, PhysicalName, Size, UsedSpace, AvailableSpace | Format-Table

Using Custom Objects

This will be much easier to work with, but it is important to be aware that the columns related to file size have GB, MB, and KB values, depending on what is most appropriate for that file size. This is great when just looking at the data like this, but can be a bit problematic for mathematical comparisons, which we will be doing later. To get around this, we can just use some custom objects:

Source code

$SqlInstance = "SSG-LT-KBURWELL"
 
Get-DbaDbFile -SqlInstance $SqlInstance -ExcludeDatabase master,model,msdb,tempdb |
 
    Select-Object SqlInstance, TypeDescription, LogicalName, PhysicalName,
 
     @{Name='DatabaseName'; Expression={$_.Database}},
 
     @{Name='SizeMB'; Expression={ [math]::Round($_.Size / 1MB, 2) }},
 
     @{Name='UsedSpaceMB'; Expression={ [math]::Round($_.UsedSpace / 1MB, 2) }},
 
     @{Name='AvailableSpaceMB'; Expression={ [math]::Round($_.AvailableSpace / 1MB, 2) }},
 
     @{Name='FreeSpacePercent'; Expression={
 
    if ($_.Size -gt 0) {
 
        $sizeMB = [math]::Round($_.Size / 1MB, 2)
 
        $availMB = [math]::Round($_.AvailableSpace / 1MB, 2)
 
        [math]::Round(($availMB / $sizeMB) * 100, 2)
 
        } else { 0 }
 
    }},
 
    @{Name='CaptureTimestamp'; Expression={ Get-Date -Format "yyyy-MM-dd HH:mm:ss" }}
 
    | Format-Table

This converts all sizes to MB, which will make any mathematical operations much easier. I also included a custom object for DatabaseName, FileSpacePercent, and CaptureTimestamp. DatabaseName really just acts as a custom column name, which is necessary when loading the data into SQL.

On To The Comparisons

Now that we are getting only the data we need, we need to save it to a table so we can do point in time comparisons. As with everything else, DBATools makes this ridiculously easy. We just need to point it to an instance and a database, it will take care of the rest. Instead of piping our results to Format-Table, I am going to pipe them to a command that will build and load a SQL table:

Source code

$SqlInstance = "SSG-LT-KBURWELL"
 
$WriteInstance = "SSG-LT-KBURWELL"
 
$WriteDB = "DBA"
 
$WriteTable = "FileSizesAndUsage"
 
Get-DbaDbFile -SqlInstance $SqlInstance -ExcludeDatabase master,model,msdb,tempdb |
 
    Select-Object SqlInstance, TypeDescription, LogicalName, PhysicalName,
 
     @{Name='DatabaseName'; Expression={$_.Database}},
 
     @{Name='SizeMB'; Expression={ [math]::Round($_.Size / 1MB, 2) }},
 
     @{Name='UsedSpaceMB'; Expression={ [math]::Round($_.UsedSpace / 1MB, 2) }},
 
     @{Name='AvailableSpaceMB'; Expression={ [math]::Round($_.AvailableSpace / 1MB, 2) }},
 
     @{Name='FreeSpacePercent'; Expression={
 
    if ($_.Size -gt 0) {
 
        $sizeMB = [math]::Round($_.Size / 1MB, 2)
 
        $availMB = [math]::Round($_.AvailableSpace / 1MB, 2)
 
        [math]::Round(($availMB / $sizeMB) * 100, 2)
 
        } else { 0 }
 
    }},
 
    @{Name='CaptureTimestamp'; Expression={ Get-Date -Format "yyyy-MM-dd HH:mm:ss" }}
 
    | Write-DbaDbTableData -SqlInstance $WriteInstance -Database $WriteDB -Table $WriteTable -AutoCreateTable

Now I have the data in SQL Server:

With this information being collected regularly, via scheduled task or agent job, we can easily trend out how much our database files are growing. It will also make potential misconfigurations stand out, such as a 1TB mdf with 99% free space. Personally, I use it in client environments to find over-allocated files that can be shrunk to reclaim some space. I know, “shrink bad”, but sometimes you just need to do it. As you can see, it’s quite straightforward and rather easy to track database file sizes with Powershell!

The post Track Database File Sizes with PowerShell: A Quick Guide for DBAs appeared first on SQL Solutions Group.