Why use Full-Text Indexes?

The Full-Text Engine manages full-text indexes. The engine splits your text columns into individual terms and builds an inverted index, mapping each term back to the rows in which it appears. Unlike a standard B-tree index, the structure lives outside the normal index internals and is maintained asynchronously via a background process called a crawl. Effectively, each word in your text string ends up indexed, rather than the string as a whole. This makes certain types of searches much more efficient (you need to use search terms like CONTAINS() to utilize full text indexes).

If you have to search strings like this then full-text indexes can be very effective. String searching isn’t great in SQL Server, but this is definitely a tool in your belt if you have a requirement that makes it useful.

Full-Text Indexes in SQL Server 2025

Microsoft publishes lists of breaking changes (if there are any) as well as deprecated features for each release of SQL Server. The 2025 edition is no different:

One of the important changes to make a note of is that, after upgrading, your full text indexes will be broken unless we make one of two changes. If you don’t take action, you will begin to see errors like this in your error log:

 2026-01-01 00:00:00.00 spid67s Error ‘0x80070002’ occurred during full-text index population for table or indexed view ‘[TableName].[SchemaName].[ObjectName]’ (table or indexed view ID ‘132456789’, database ID ’67’), full-text key value ‘1324567890’. Attempt will be made to reindex it. If recently performed in-place upgrade to SQL2025, For help please see https://aka.ms/sqlfulltext.

Why? Microsoft changed the architecture of how full-text indexes are stored behind the scenes. Because this is a significant change, there are now two versions of full text searches we can use. To see which one you’re on, you can run the query below: 

Source code

SELECT *
FROM sys.database_scoped_configurations
WHERE [name] = 'FULLTEXT_INDEX_VERSION';

If you’re showing version 1, then this is the pre-2025 legacy setting; version 2 is the 2025 and beyond setting.

Legacy Full Text Setting

The previous version is now marked as legacy and you must explicitly enabled it if you want to continue using it, as follows:

Source code

ALTER DATABASE SCOPED CONFIGURATION
SET FULLTEXT_INDEX_VERSION = 1;

As per the documentation, you’ll then need to copy your legacy word breaker and filter binaries from your original instance.

We would only suggest using this legacy option if you have a specific need to use it (e.g. a vendor app requirement or similar), just as we would with other deprecated or legacy features of SQL Server.

Upgrade Full-Text to 2025

The more future-proof way of ensuring your full text indexes work after an upgrade is to rebuild your catalogs manually. This kicks off a new crawl and upgrades your full-text indexes to work with the more modern version of the engine.

Source code

ALTER FULLTEXT CATALOG [FtCatalog] REBUILD;

The full text crawl will happen behind the scenes. If you want to investigate other issues you may have with full-text indexes, check out our Fixing Full-Text Indexes blog post.

If you are a control freak (like a lot of us), you can use the script below to check the status of your full-text crawls at a table level for all databases and tables on your server. 

Source code

USE master;
GO
IF OBJECT_ID('tempdb..#FullTextTables') IS NOT NULL
DROP TABLE #FullTextTables;
CREATE TABLE #FullTextTables
(
database_name sysname,
schema_name sysname,
table_name sysname,
fulltext_catalog sysname,
is_enabled BIT,
change_tracking_state_desc NVARCHAR(60),
has_crawl_completed BIT
);
DECLARE @db sysname;
DECLARE @SQL NVARCHAR(MAX);
DECLARE dbs CURSOR FAST_FORWARD FOR
SELECT d.name
FROM sys.databases AS d
WHERE d.state_desc = 'ONLINE'
AND d.database_id > 4; -- skip master, tempdb, model, msdb
OPEN dbs;
FETCH NEXT FROM dbs INTO @db;
WHILE @@FETCH_STATUS = 0
BEGIN
SET @SQL = N'
BEGIN TRY
USE ' + QUOTENAME(@db) + N';
INSERT INTO #FullTextTables
(
database_name,
schema_name,
table_name,
fulltext_catalog,
is_enabled,
change_tracking_state_desc,
has_crawl_completed
)
SELECT
DB_NAME() AS database_name,
s.name AS schema_name,
t.name AS table_name,
c.name AS fulltext_catalog,
fi.is_enabled,
fi.change_tracking_state_desc,
fi.has_crawl_completed
FROM sys.fulltext_indexes AS fi
INNER JOIN sys.tables AS t
ON t.object_id = fi.object_id
INNER JOIN sys.schemas AS s
ON s.schema_id = t.schema_id
INNER JOIN sys.fulltext_index_catalog_usages AS ficu
ON ficu.object_id = fi.object_id
INNER JOIN sys.fulltext_catalogs AS c
ON c.fulltext_catalog_id = ficu.fulltext_catalog_id;
END TRY
BEGIN CATCH
-- ignore databases you cannot access
END CATCH;';
EXEC sys.SP_EXECUTESQL @SQL;
FETCH NEXT FROM dbs INTO @db;
END
CLOSE dbs;
DEALLOCATE dbs;
DELETE #FullTextTables WHERE has_crawl_completed = 1
SELECT
database_name,
schema_name,
table_name,
fulltext_catalog,
is_enabled,
change_tracking_state_desc,
has_crawl_completed
FROM #FullTextTables
ORDER BY database_name, fulltext_catalog, schema_name, table_name;
DROP TABLE #FullTextTables

Conclusion

If you’re concerned about breaking changes like this, we at SSG perform upgrades all the time. We can assist and guide you safely through your next SQL Server upgrade. Reach out and we’d be happy to have a chat.

The post Full-Text Index Breaking Change in SQL Server 2025 appeared first on SQL Solutions Group.

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.

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.

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.

What’s an Availability Group?

In short, Availability Groups (AGs) are a SQL Server feature that enables you to connect multiple servers together (at least two, limits depend upon your edition) so they can share databases. One server runs as the primary node and the others act as secondary nodes. In this example we’re going to assume we’re in a two-node AG with one primary node and one secondary node. We’re also going to assume we have a synchronous AG here.

In this setup, the nodes share the databases and sync with each other.  The primary server holds the primary copy of the database and the secondary server holds a read only copy of the same database. The idea is that if we lose the primary node for whatever reason, the AG will fail over and make the other node the primary node. This removes any downtime concerns and allows for things like patching to take place without making the database inaccessible while this happens.

The main issue people have is that while databases are shared between the two servers, we (as DBAs) have to keep all non-databases objects synchronized across both nodes — things like user logins, SQL Agent jobs and server level settings. We can do this with tools like the dbatools powershell modules. But, Microsoft decided that they wanted to make this process slightly easier for us.

How is a contained Availability Group different?

Contained AGs add a third server category, the Listener. This is what users will usually see and connect to; they won’t connect to the nodes separately. This listener also contains all of the server level objects, so you no longer have to do things like sync your agent jobs and logins across your nodes manually.

There are some things to consider. Such as, agent jobs will only run on the primary node at all times. If you want them to run on the secondary then you will have to install it on the nodes directly and avoid the contained AG.

The Bug: Transaction Log Shipping

The reason for this blog post is the bug that was mentioned at the beginning. In this scenario, we have a customer with a contained AG that has log shipping involved.

To quickly summarize: log shipping is the act of taking transaction log backups on a server and restoring them elsewhere to make a read-only copy of the original database. In this scenario, the logs are shipped to a server that processes reporting workloads so that this workload does not happen on the main production servers.

Once we set up transaction log shipping in place, we will have three Agent jobs:

• LSBackup_DatabaseName: This will happen on the primary node (or the listener in the case of a contained AG) and performs the transaction log backup.
• LSCopy_DatabaseName: This is installed on the recipient of the log shipped data; in this scenario, the reporting server. This finds all of the log backups that have happened within LSBackup and copies them over to the target server.
• LSRestore_DatabaseName: This uses the local log backups and restores them to the local copy of the database.

Contained AGs absolutely support transaction log shipping. It works much better as you don’t have to manage the primary/secondary server relationship at all. However, we wouldn’t all be here if it was all butterflies and roses, would we?

When you set up log shipping using the GUI you will need several pieces of information to get to the right place. This includes things like backup paths for shared folders, server names, etc. Our specific bug is all about the server names.

The problem occurred when, for patching, a planned failover of the AG happened. This caused the LSBackup job to begin failing. This meant that there were no files to copy over, and therefore the reporting database began falling behind with data. With no backups, it also caused the transaction log to increase in size.

The specific error we began getting was this (GUID is a placeholder for an actual GUID):

Error: Could not retrieve backup settings for primary ID ‘GUID’

Which is odd in a contained AG, as technically the primary node never changes (it’s always the listener).

We then see, upon the built-in retry logic, the following error:

Error: Failed to connect to server “SECONDARY NODE”

Which it shouldn’t be trying to do at all.

I scripted out the log shipping configuration and the only server names involved were the listener and the reporting server. I didn’t see any reference to a specific node, so I went digging.

By looking at the LSBackup agent job, we could see that, for some reason, it had been generated with the server name of the primary node at the point of the log shipping being set up:

This was the source of the issue. It was trying to read backup information from a secondary database, which it was unable to do. It was therefore failing on log backups. I have no idea why it would have chosen this server. This is now something we’re going to build into all of our checks moving forward.

Fixing the Bug

The fix is simple: Change this job manually to look at the listener and execute the agent job. It will likely take a lot longer than it usually would as it’s backing up a lot more data than normal. However, once complete, the LSCopy and LSRestore jobs will do their job and get the target database up to date.

Hopefully this helps anybody in a similar situation, feel free to reach out if you have any specific questions at all around any of this. I’d be more than happy to have a chat about log shipping in contained availability groups.

The post A Bug: Log Shipping in Contained Availability Groups appeared first on SQL Solutions Group.

For the demos below I’m using the Stack Overflow database, you can go grab a copy here. It comes in various sizes, and a small one is perfectly acceptable for this test. We’re only going to deal with 100k rows of data. Once we have the database available and attached to a test instance of SQL Server, we have a few things to do.

Setting Up A Memory-Optimized Table

First, we’re going to create a filegroup for memory-optimized data. Then, create a file within that filegroup (the location below is for my test machine, yours will likely need to be different). Then, set memory-optimized to snapshot (which is best practice).

Source code

USE [StackOverflow];
 
GO
 
ALTER DATABASE [StackOverflow]
 
ADD FILEGROUP [StackOverflow_mod_fg] CONTAINS MEMORY_OPTIMIZED_DATA;
 
GO
 
ALTER DATABASE [StackOverflow]
 
ADD FILE (NAME = N'StackOverflow_mod', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL15.SQL2019\MSSQL\DATA\StackOverflow_mod')
 
TO FILEGROUP [StackOverflow_mod_fg];
 
GO
 
ALTER DATABASE [StackOverflow] SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;
 
GO
 
NEXT we’re going TO make a standard ON DISK TABLE so we can USE it FOR comparison purposes vs the in memory TABLE we’re going TO CREATE.
 
IF OBJECT_ID('dbo.Posts_Disk') IS NOT NULL DROP TABLE dbo.Posts_Disk;
 
GO
 
SELECT TOP (100000) -- keep this modest; raise as your RAM allows
 
p.Id,
 
p.CreationDate,
 
p.Score,
 
p.OwnerUserId,
 
p.PostTypeId,
 
p.Title
 
INTO dbo.Posts_Disk
 
FROM dbo.Posts AS p
 
WHERE p.PostTypeId IN (1,2) -- questions & answers, typical subset
 
ORDER BY p.Id;
 
GO
 
CREATE CLUSTERED INDEX CX_Posts_Disk_Id ON dbo.Posts_Disk(Id);
 
CREATE INDEX IX_Posts_Disk_CreationDate ON dbo.Posts_Disk(CreationDate);
 
GO

Now we’ll make an in memory version of this table.

Source code

IF OBJECT_ID('dbo.Posts_InMem') IS NOT NULL DROP TABLE dbo.Posts_InMem;
 
GO
 
CREATE TABLE dbo.Posts_InMem
 
(
 
Id INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1048576),
 
CreationDate DATETIME2 NOT NULL INDEX IX_InMem_CreationDate NONCLUSTERED,
 
Score INT NOT NULL,
 
OwnerUserId INT NULL,
 
PostTypeId INT NOT NULL,
 
Title NVARCHAR(250) NULL
 
)
 
WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);
 
GO
 
And we’re going TO take the same DATA FROM our ON DISK TABLE and INSERT INTO our NEW in-memory TABLE;
 
INSERT dbo.Posts_InMem (Id, CreationDate, Score, OwnerUserId, PostTypeId, Title)
 
SELECT Id, CreationDate, Score, OwnerUserId, PostTypeId, Title
 
FROM dbo.Posts_Disk
 
GO

Let’s do a comparison between our on disk table and our in-memory table. The first comparison we’ll do is to return one record from each table and check the statistics. I wanted an Id that’s roughly in the middle of my tables so that it would be a meaningful comparison. Id 88,011 appears on row 50,000 of my table so I’m using that in the queries below. This may be different in your version of the database.

Source code

SET STATISTICS TIME,IO ON;
 
SELECT * FROM dbo.Posts_Disk WHERE Id = 88011;
 
SELECT * FROM dbo.Posts_InMem WHERE Id = 88011;

If we copy the statistics from the messages tab output in SSMS and paste into statisticsparser.com (to make it readable), you’ll notice we perform 3 logical page reads on the Posts_Disk table, but zero reads on Posts_InMem.

Now, let’s do a date range comparison. For the parameters used below, I have taken the values from row 30,000 and 70,000 as my two dates so we return a decent amount of the sample data.

Source code

SET STATISTICS TIME,IO ON;
 
DECLARE @d1 DATETIME2 = '2008-09-08 23:48:24.2570000';
 
DECLARE @d2 DATETIME2 = '2008-09-22 22:38:47.5570000';
 
SELECT COUNT(*)
 
FROM dbo.Posts_Disk
 
WHERE CreationDate >= @d1 AND CreationDate < @d2;
 
SELECT COUNT(*)
 
FROM dbo.Posts_InMem
 
WHERE CreationDate >= @d1 AND CreationDate < @d2;
 
GO

If we put the stats into statisticsparser.com again, you’ll see that on the Posts_Disk table we have 96 logical reads and an execution time of 38ms.

And for our in-memory table we show zero logical reads and an execution time of 9ms.

Things get interesting when we compare execution plans.

The query plan at the top is a lot more complicated. It shows the worktables that are being created behind the scenes, but it reports only 15% of the overall estimated query cost. In contrast, the query below is showing as more expensive but from the statistics we can prove that it produces its results much quicker than the on-disk table. This gives us caution when comparing execution plans as they can have bad estimates and provide misleading data.

What Have We Found?

From all this, we’ve proven that in-memory tables can perform much better than classic on-disk tables. However, that’s not saying there aren’t significant considerations to evaluate when it comes to using these tables. The list below is far from exhaustive, but rather what we consider the most restrictive or problematic points to consider.

Architectural Issues

• All data must fit into memory.
• Very large tables are impractical unless we have loads of memory to spare (spoiler: not many people have memory to spare when it comes to SQL Servers)
• Compression is not supported for in-memory tables, this gives these objects an even higher memory footprint.

Indexing

• The following index types are not supported
  • Clustered Indexes
  • Filtered Indexes
  • Non-clustered indexes that have included columns
• You must also be very considerate of your hash index bucket sizes.
  • Too few: Bad performance from long chains and collisions
  • Too many: Wasted memory (buckets are allocated up front and never shrink)
• Index rebuilds and reorganize operations are not supported, only drop/create to achieve the same goal

T-SQL Limitations

• No check constraints
• No foreign key cascades
• No foreign keys referencing disk based tables from in-memory tables
• There are unsupported data types depending upon your SQL Server version
• No IDENTITY columns
• No Merge statement (not a bad thing in one DBA’s opinion, at least)

Should You Use Memory-Optimized Tables in SQL Server?

Ultimately, if you’re considering using in-memory tables, I would recommend researching the advantages and disadvantages extensively. You would be well advised to test on a large dataset (a copy of production is ideal, because you’re not testing in production, right?) to see how your specific workload would react to using in-memory tables.

Have you implemented in-memory tables and are they working well for you? We’d love to hear about your experiences, so share your story in the comments below.

The post An introduction to Memory-Optimized Tables in SQL Server appeared first on SQL Solutions Group.

OK, now we have that out of the way, we’re going to proceed with the assumption that you’re working in some sort of development environment. That can be a specific server or even just a database on a developer’s laptop. It doesn’t matter where it is.

The main issue we see in dev environments is that people take a nice little version of their database, a few hundred rows of data per table, and develop on that. This is great for checking that your logic is correct, but not good when it comes to actually deploying the code to production. Suddenly, your nice, pretty code has to deal with millions of rows of data and grinds to a halt because you didn’t write it for big data sets. No, you wrote it for your development system, and it was fast on your machine. We see this a lot.

What to do?

The obvious fix for this is to take a copy of your production database (most people grab the last full backup) and restore onto a similarly sized server to use for testing. This way you’re testing as close as you can to the production database size. This is an excellent idea, especially if you have a team or process that can run a workload against this development machine to simulate a real workload.

If you choose to do this, you’ll often hit the problem of using real people’s personally identifiable information (PII). In certain environments (e.g. healthcare, banking), we don’t want people to have access to this customer data. We still want the data size but we have to sanitize this data before it’s safe to test with. This post walks you through the process.

Removing Personally Identifiable Information

We’re focusing on a couple different data types here — names and phone numbers. There are a lot more data types that qualify as PII, but you don’t want to read a 20 page essay. What we’ll do here is to show you the principle. You can then modify these scripts to meet your specific needs and/or data types.

Phone Numbers

We’ll start by anonymizing phone numbers. This data is much simpler to change than names, and numbers are also easier to deal with than people (hey, we’re not in this career path because we like dealing with people 😂).

OK, let’s make a temporary table with some totally real phone numbers for our testing;

Source code

IF OBJECT_ID('tempdb..#PhoneNumbers') IS NOT NULL DROP TABLE #PhoneNumbers;
 
CREATE TABLE #PhoneNumbers (PhoneNumbers VARCHAR(20))
 
INSERT INTO #PhoneNumbers
 
VALUES
 
('(111) 111 1111')
 
,('(222) 222 2222')
 
,('(333) 333 3333')
 
,('(444) 444 4444')
 
,('(555) 555 5555')

Yes, this is very simple, but it’ll work just fine for this test.

Now we’re going to want to follow whatever format our phone numbers are in. I’ve included brackets and spaces just because I’m a bit of a masochist. Adapt this for whatever format your tables use.

Right: The reason we’ve started with phone numbers is because SQL Server is pretty good at just generating numbers out of thin air. We’re going to use the CRYPT_GEN_RANDOM function to generate our random values. We’ll then convert this to an INT to give us a random string of at least 4 integer values.

Source code

SELECT CONVERT(INT,CRYPT_GEN_RANDOM(2))

Run this a bunch of times. You’ll see that it’s going to randomise numbers for us. We can do a bit of messing about and get this in the format we want;

Source code

SELECT
 
'(' + LEFT(CONVERT(VARCHAR,CONVERT(INT,CRYPT_GEN_RANDOM(2))),3) + ')'
 
+ ' '
 
+ LEFT(CONVERT(VARCHAR,CONVERT(INT,CRYPT_GEN_RANDOM(2))),3)
 
+ ' '
 
+ LEFT(CONVERT(VARCHAR,CONVERT(INT,CRYPT_GEN_RANDOM(2))),4)

We’ve added the brackets and spaces where we need for our format. Modify this as needed.

Now, we can use this function and update our temp table;

Source code

UPDATE #PhoneNumbers
 
SET PhoneNumbers = '(' + LEFT(CONVERT(VARCHAR,CONVERT(INT,CRYPT_GEN_RANDOM(2))),3) + ')'
 
+ ' '
 
+ LEFT(CONVERT(VARCHAR,CONVERT(INT,CRYPT_GEN_RANDOM(2))),3)
 
+ ' '
 
+ LEFT(CONVERT(VARCHAR,CONVERT(INT,CRYPT_GEN_RANDOM(2))),4)

The results in my test look like this;

This method can be used for any data that contains only values that are integers. It won’t work for randomly generating names or other text-based data. We’ll need a different approach for these.

Generating Names

First of all, test data:

Source code

IF OBJECT_ID('tempdb..#TotallyRealNames') IS NOT NULL DROP TABLE #TotallyRealNames;
 
CREATE TABLE #TotallyRealNames
 
(
 
ARealPersonsName VARCHAR(20)
 
)
 
INSERT INTO #TotallyRealNames (ARealPersonsName)
 
VALUES
 
('Aaron'),('Abron'),('Acron'),('Adron'),('Aeron')

We can’t just randomly generate data (well, we could, but: the names would just be random strings of letters and wouldn’t be very nice to work with). So, instead, let’s go grab some names.

For this data here, I went to data.gov and got the top 100 baby names from a CSV list. The test data below is not the full 100 names, but you can grab a list of names from any publicly available list on the net (please check any applicable licences).

Source code

CREATE TABLE #FirstNames
 
(
 
ID INT IDENTITY(1,1)
 
,FirstName VARCHAR(100)
 
)
 
INSERT INTO #FirstNames (FirstName)
 
VALUES ('GERALDINE'),('GIA'),('GIANNA'),('GISELLE'),('GRACE'),('GUADALUPE'),('HAILEY'),('HALEY'),('HANNAH'),('HAYLEE')

We now have a list of 10 names that we can apply to our main table and replace. The issue here is that we want to apply only one name to each row of data in the main table. We’re going to have to use some sort of TOP (1) statement here, however, if we were to do a simple join like this …

Source code

UPDATE #TotallyRealNames
 
SET ARealPersonsName = (SELECT TOP (1) FirstName FROM #FirstNames)

… we’re going to have a problem:

Just one name has been used to replace all of our original data. That’s no fun. To fix this, we’ll have to do some funky nonsense to get us a random selection of names in here.

Source code

Funky Nonsense;
 
;WITH OriginalData_CTE AS
 
(
 
SELECT
 
trn.ARealPersonsName
 
,LEFT(1 + 200 * (CAST(CRYPT_GEN_RANDOM(4) AS INT) / 4294967295.0 + 0.5),1) AS random_number
 
FROM #TotallyRealNames AS trn
 
)
 
,UpdateData_CTE AS
 
(
 
SELECT
 
od.ARealPersonsName
 
,NEW.FirstName
 
FROM
 
OriginalData_CTE od
 
OUTER APPLY
 
(
 
SELECT fn.FirstName
 
FROM #FirstNames AS fn
 
WHERE fn.ID = CAST(od.random_number AS INT)
 
) AS NEW
 
)
 
UPDATE UpdateData_CTE
 
SET ARealPersonsName = FirstName

I did warn you… OK, let’s break down what this code does.

The first CTE uses our friend CRYPT_GEN_RANDOM to generate a random int value for each row of our table. Because we only have 10 rows of data in our list of names, I have included the LEFT(,1) statement so we only return one digit. Because of this, you’re likely to see duplicates in our output data. However, if you have a sensible amount of names in your replacement list (e.g. 3 or 4 digits worth), then you won’t see these.

Source code

;WITH OriginalData_CTE AS
 
(
 
SELECT
 
trn.ARealPersonsName
 
,LEFT(1 + 200 * (CAST(CRYPT_GEN_RANDOM(4) AS INT) / 4294967295.0 + 0.5),1) AS random_number
 
FROM #TotallyRealNames AS trn
 
)

The second CTE joins this random number to the ID value of the data in our replacement data:

Source code

,UpdateData_CTE AS
 
(
 
SELECT
 
od.ARealPersonsName
 
,NEW.FirstName
 
FROM
 
OriginalData_CTE od
 
OUTER APPLY
 
(
 
SELECT fn.FirstName
 
FROM #FirstNames AS fn
 
WHERE fn.ID = CAST(od.random_number AS INT)
 
) AS NEW
 
)

This output will allow the update to happen and actually update our table. At this point, your data should look something like this;

You’ll see the duplicate in the output, but that’ll happen with such small data sets.

What Have We Achieved?

At this point, you’ve got customer data that’s PII phone numbers and names replaced with sensible-looking but completely anonymous data, ready for development to safely test against.

There’s a lot more you can do with this approach if needed. The obvious next steps are to use the phone number script for fax numbers and cell numbers, but you can use the text replacement to also do full names, email addresses and anything else that uses a person’s name.

At this point, the only thing left is to go through every column of data in your database and identify exactly which columns are PII, I’ll leave that particular part of this process to you and your expert knowledge of your own environment.

Good Luck!

The post Removing Personally Identifiable Information in Development Environments appeared first on SQL Solutions Group.

The tables in use here are partitioned. The partition field is based upon a date field and we have a partition per month. There is a monthly maintenance job which creates our new partitions. The job should also delete the oldest partitions. This job has been failing to delete an old partition as the data file contained within is not empty. It’s stubborn!

If we try to remove this file we get the error “The File cannot be removed because it is not empty,” as you can see:

This is the file in question (I removed file names):

We can use the T-SQL query below to find all objects that believe they exist within our partition.

Source code

SELECT
 
OBJECT_NAME(p.OBJECT_ID) AS TableName
 
,p.partition_number AS PartitionNo
 
,FILEGROUP_NAME(a.data_space_id) AS FileGroup
 
,i.name AS IndexName
 
, *
 
FROM sys.allocation_units a
 
INNER JOIN sys.partitions p ON a.container_id = CASE WHEN a.type in(1,3) THEN p.hobt_id ELSE p.partition_id END AND p.OBJECT_ID > 1024
 
LEFT JOIN sys.indexes i ON i.OBJECT_ID = p.OBJECT_ID AND i.index_id = p.index_id
 
WHERE FILEGROUP_NAME(a.data_space_id) = 'FileGroupName'
 
ORDER BY FileGroup, TableName, p.partition_number

 When run, you’ll get a list of all of the tables that believe they exist within this filegroup and how many data pages exist.

In our example, we have seven data pages that believe they exist in our partition. This is definitely a bug, because when we use our partition column and search our tables, we can see that no data exists.

Source code

SELECT * FROM TableName WHERE PartitionField BETWEEN ‘StartDate’ AND ‘EndDate’

This is a bug in SQL Server and sensible human beings like us can’t resolve it. So, we’ll have to get creative.

Getting Creative: The Nuclear Option

From my experience, the only way to get rid of these rogue data pages is to truncate a table. By definition, truncating a table will deallocate all data pages associated with that table so we can get rid of these pesky hangers on. The big drawback is that you can’t put any sort of WHERE clause on a truncate, because you lose everything. It’s definitely the nuclear option when it comes to emptying out a table. We can’t do that to production tables in which we actually care about the data, obviously. We will have to perform a magic trick here to get this to work for us.

One of the great things about SQL Server partitioning is the ability to switch partitions between tables in the same filegroup. This consists of a metadata change only, rather than actually moving data.

Let’s combine both of these features to fix this pesky old filegroup.

From the first query above, we have our list of tables that are hanging around. For each of these we’re going to make a copy of the table structure (with a new name, something inventive like TableName_PartitioningTemp) along with all of the indexes that appear in our original table. We can then switch our partition over to the new table, truncate the new table, and then delete it (because we’re good children and tidy up after ourselves).

Our process will look like this:

1. Create a copy of our table structure on the same partition
2. Create all indexes required
3. Switch our partition
4. Truncate our new table
5. Delete our new table

To create a copy of our table, we’ll just let SQL Server do the hard work by right clicking on our table and scripting it to a new query editor window.

One very important thing to note is that this will usually default to the PRIMARY filegroup. Be sure to change this to the correct filegroup:

We can then do the exact same and script out the necessary indexes. We’ll end up with a script looking something like this. REMEMBER, we’ll need to change the table name to something different than our live table.

This gives us our object ready to switch our partition into. Let’s do that by switching our partition to the new table. Make sure that your partition number is correct here.

Once this is done, we can then truncate our new _Partitioned table and delete it:

Our final script will look something like this;

Source code

CREATE TABLE [dbo].[Employees_Partitioned](
 
[EmployeeID] [INT] IDENTITY(1,1) NOT NULL,
 
[EmployeeName] [VARCHAR](100) NULL,
 
[EmployeeAddress] [VARCHAR](100) NULL,
 
[EmployeeDeptID] [INT] NULL
 
) ON [NewFileGroup]
 
GO
 
CREATE CLUSTERED COLUMNSTORE INDEX [IX_CS_Employee] ON [dbo].[Employees_Partitioned]
 
WITH (DROP_EXISTING = OFF, COMPRESSION_DELAY = 0) ON [NewFileGroup]
 
GO
 
ALTER TABLE [Employees] SWITCH PARTITION 1 TO [Employees_Partitioned]
 
TRUNCATE TABLE [Employees_Partitioned]
 
DROP TABLE [Employees_Partitioned]

If you get any error messages, it may be that you’ve missed an index that’s required for the switch. Simply script it out and add it to your script.

Once you have completed this step, run the original script and you will remove this table from the list:

Source code

SELECT
 
OBJECT_NAME(p.OBJECT_ID) AS TableName
 
,p.partition_number AS PartitionNo
 
,FILEGROUP_NAME(a.data_space_id) AS FileGroup
 
,i.name AS IndexName
 
, *
 
FROM sys.allocation_units a
 
INNER JOIN sys.partitions p ON a.container_id = CASE WHEN a.type in(1,3) THEN p.hobt_id ELSE p.partition_id END AND p.OBJECT_ID > 1024
 
LEFT JOIN sys.indexes i ON i.OBJECT_ID = p.OBJECT_ID AND i.index_id = p.index_id
 
WHERE FILEGROUP_NAME(a.data_space_id) = 'FileGroupName'
 
ORDER BY FileGroup, TableName, p.partition_number

If you have more than one table involved then you’ll have to do each one individually. Hopefully you don’t have too many, but this is definitely worth doing. Otherwise, you’ll never get rid of that filegroup.

Once the script runs and and the result of the script above is zero rows, you’re almost there. You need to check that the filegroup is not referenced by our partition scheme and function before we can finally delete it. We’d do this with a merge of the partition if it still exists.

ALTER PARTITION FUNCTION [FunctionName] () MERGE RANGE (N’2025-03-01’)

Then we can finally remove the file

ALTER DATABASE [DBName] REMOVE FILE [FileName]

That’s it! You’ve addressed stubborn partitions in SQL Server and removed what you don’t need.

The post Removing Stubborn Partitions in SQL Server appeared first on SQL Solutions Group.

Row Numbers

By default, SSMS does not show row numbers next to your code. That’s not a huge issue when working with smaller blocks of T-SQL. However, when working with larger problems and/or collaborating with colleagues, being able to refer to a row number is invaluable. This is especially important for us here at SQL Solutions Group when we’re in meetings and looking at code. Being able to refer to a line number on somebody else’s screen makes the world so much easier and less confusing.

By default, if you script out a stored procedure (this is sp_WhoIsActive) you’ll see something like this:

Which is fine. However, when you turn on row numbers, you’ll see something like this:

Which makes it much easier to read. To change this setting, go into Tools -> Options -> Text Editor -> Transact-SQL and enable Line Numbers:

Scroll Bar

By default in most versions of SSMS, the scroll bar is just a scroll bar. It looks something like this:

That’s OK, it does its job. However, if you’re working with a larger procedure it’s not actually very useful. Instead, enabling map mode for your scroll bar will give you something like this:

Which, when you’re moving around your code, gives you much more control on where you’re going or want to go. The setting for this is also in Tools -> Options and can be found in the menu below:

There are a few different options for source overview, so have a play and see which ones you prefer.

Tab Management

One of the most frustrating things when working in SSMS is losing the tab you were looking for. They’re never where you expect them, and finding that one tab is always a nightmare. You can already pin tabs; however, it doesn’t take long to run out of screen real estate.

One trick you can do is to pin tabs to a separate row. This separates them from the noise and makes them much easier to find.

The first tab here is pinned, but it doesn’t really stick out vs the rest of the tabs

Whereas, there’s a handy little setting to show pinned tabs on a separate row, which looks something like this:

This can be found (surprise, surprise) in Tools -> Options:

A very helpful feature that’s new in SSMS 21 is the ability to show multiple rows of tabs at once. This is great because rather than dealing with that damned menu to select your tabs …

… you can see them all at once, which ends up looking something like this:

In Tools -> Options, you’ll want this setting;

Vertical Tabs

This is another feature that’s new in SSMS 21, but we now have the choice where our tabs are located. We have the traditional Top as an option, but we can now have them on the left or the right of our screen.

Here’s an example of me snapping my tabs to the right of the screen:

This is likely to take a while to get used to but, it’s enormously beneficial when dealing with an investigation or similar task where multiple tabs are just an unavoidable fact of life.

One feature I like in particular here is that pinned tabs persist when used with the ‘show pinned tabs in a separate row’ setting and stay in their own section at the top of the screen.

Yep … find it in Tools -> Options:

Themes

Last, but not least, we now have themes available in SSMS. This is both much nicer on the eyes (hello, dark mode) but also gives a lot of accessibility options.

Themes have their own menu in Tools:

The dark theme is a particular favourite and, I suspect, going to be very popular:

There’s also a bunch of Accessibility choices in Tools -> Options where you can customize fonts and so you can set it exactly how you need/want.

Now go have fun with these SSMS essential settings, you crazy cat!

The post SSMS Essential Settings appeared first on SQL Solutions Group.

What’s New in SSMS 21?

1. 64-bit compatibility

This one is huge. SSMS has always been a 32-bit application, which can cause all sorts of issues from general slowness to out of memory exceptions. SSMS 21 is now based on a Visual Studio shell. This means that it’s fully 64-bit compatible and gets some funky new features like different accessibility modes (hello dark mode), as well as all the other improvements you’d expect from a modern 64-bit application.

Doesn’t this look funky?

2. Code and feature search

Along with the interface makeover, we’ve now got code and feature search capabilities. This gives us a native way to find the code we care about as well as searching and enabling the new features baked into SSMS.

Want to know more about Git integration? Hit the search icon and go to feature search.

Type “Git” and you’ll see several settings pages as well as some handy how-to guides for these features.

This is excellent for newer users finding out features as well as us old people who can never remember which menu something is buried in!

3. Copilot/AI

This was the part of the product that Microsoft were most excited about in the PASS Summit keynote. We were shown a number of features, including inbuilt Copilot as well as native support for Vector data types and integration with various AI products.

Unfortunately, I can’t show you these features as they’re not currently included in the public preview, but when it’s available we’ll take a deep dive into it.

4. Query Store Enhancements

The main new feature for me here is the addition of the replica drop down in the query store reports. This allows you to read data from the various replicas you may have in your environment.

This goes hand in hand with the upcoming feature of running a separate Query Store on secondary replicas. Which is going to be great for people who offload read queries onto their secondaries but would like to be able to do funky stuff like forcing plans on the secondary only. Really looking forward to this feature.

4. Improved Performance Dashboard

The performance dashboard has been around for a while, and I suspect it’s not a highly used feature. It gives some basic information about server performance as well as the ability to drill down into it. I would bet that most people are using external tools to monitor their servers, but for situations where this isn’t available, I’d definitely get used to using this.

How to Get Started

As SSMS is in public preview, you can download it from Microsoft directly. Remember that this is still in preview, so go have fun, but beware it can be buggy (I’ve personally had issues with the search being a little flaky). Keep it away from production environments!

Don’t let me stop you though. Go have fun and dig in, learn by doing and see if you can find some fun new features that we haven’t covered here!

The post Exploring SSMS 21 appeared first on SQL Solutions Group.