What is the resource_semaphore wait?

A wait type of resource_semaphore means that there isn’t enough available memory to grant for queries to run. At a high level, here is what is happening. A query is submitted to the SQL Server engine for execution. As part of the pre-execution phase, SQL Server estimates how much memory it thinks a query will need to run. Several factors influence this memory estimation. Assuming there is free memory to grant to the query, then the query moves along the execution phases and starts running.

But let’s say you have a server with 128 GB of RAM allocated to SQL Server. A series of queries are submitted to the SQL Server database engine that are each granted 15 GB of RAM. At most, SQL Server can handle 8 of those queries before it runs out of memory to allocate. The next query that comes along and needs another 15 GB of RAM is prevented from starting its execution because 8 X 15 = 120 GB of RAM. This 9th query, if granted memory, would cause a total of 135 GB to be allocated. The server doesn’t have that much RAM allocated for queries. So, it has to wait.

As other queries are submitted, they wait behind this 9th query that needs the additional 15 GB of RAM. If the other 8 queries that are already executing are long-running queries, it might be several minutes, or longer, before memory is available. Queries start stacking up behind each other. Users start noticing that the app is slow, pages aren’t refreshing, and reports aren’t completing. Soon, everyone is hitting F5 on the web app to resubmit queries because nothing is happening. Immediately following this, your phone or your Slack messages start blowing up!

How to find queries with large memory grants

First, you can use sp_whoisactive to find the queries and the offending wait in real-time. This is very useful for the scenario above, where users feel the pain and start entering tickets and messaging people for help.

However, let’s say, for example, that your server is just teetering on the edge with the memory allocation. Memory grants are occasionally high enough that SQL Server is registering the resource_semaphore wait, but it isn’t happening for long enough, or frequently enough, that users really notice and start complaining. Your SQL Server is experiencing slowness, at times, it’s just not causing excruciating pain. This may show up by this wait appearing low in the result set from Paul Randall’s wait stats query. Maybe it’s only causing a few seconds of wait, on average, when it happens. Users might notice this because their report or application screen completes after a brief wait, so they assume this is “normal.” Consequently, they don’t report it. This doesn’t mean you can or should ignore what the wait stats information is telling you. Act now before this becomes a full-blown emergency.

Second, in the above scenario, you can use Extended Events to find queries with large memory grants. Extended Events are light-weight trace objects that allow for the capture of far more events than Profiler or a server-side trace. They also work differently by only firing and capturing when an event defined in the session happens, versus capturing everything and then filtering like Profiler does.

Setting Up The Extended Events Session

After some poking around and some experimenting, I was able to arrive at the T-SQL below to create the extended event session. This code will capture any query with a memory grant greater than 1 GB. Adjust this higher or lower as makes sense for your environment. The session stores the database ID, plan handle, session ID, and the T-SQL text for the offending query in a file. It will write to as many as 5 files, each 1 GB in size. When the 5th file is full, it will delete the oldest files and start writing a new file.

One thing to be aware of is the path for the file that will hold the data. That path must exist first. I’m using C:\XE\NameofExtendedEventSession.xel. Be sure to update that path to a location that your SQL Server instance can access.

CREATE EVENT SESSION [TrackHighMemoryGrants] ON SERVER 
ADD EVENT sqlserver.query_memory_grant_usage(
ACTION(sqlserver.database_id,sqlserver.plan_handle,sqlserver.session_id,sqlserver.sql_text)
    WHERE ([granted_memory_kb]>(1024000))),
ADD EVENT sqlserver.query_memory_grant_wait_end(
    ACTION(sqlserver.database_id,sqlserver.session_id,sqlserver.sql_text)
    WHERE ([sqlserver].[database_id]=(8) AND [granted_memory_kb]>(1024000)))
ADD TARGET package0.event_file(SET filename=N'C:\XE\HighMemoryGrants.xel',max_file_size=(1024),max_rollover_files=(5))
WITH (MAX_MEMORY=51200 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=5 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=ON,STARTUP_STATE=OFF)
GO

To start the Extended Events session, run the following T-SQL:

ALTER EVENT SESSION [TrackingHighMemoryGrants]
ON SERVER
STATE = START;

This can also be done from SSMS. Traverse the UI under the SQL instance name to Management > Extended Events > “TrackingHighMemoryGrants”, right click and select the “Start Session” option.

How to query Extended Events files

The extended event is gathering data. The query below can parse the collected files to show which queries have the highest memory grants on average.

WITH ParsedEvents AS (
SELECT 
event_data.value('(event/action[@name="sql_text"]/value)[1]', 'nvarchar(max)') AS sql_text,
event_data.value('(event/data[@name="granted_memory_kb"]/value)[1]', 'bigint') / 1024.0 AS granted_mb
FROM (
    SELECT CAST(event_data AS XML) AS event_data
    FROM sys.fn_xe_file_target_read_file('C:\XE\HighMemoryGrants*.xel', NULL, NULL, NULL)
    ) AS x
)

SELECT 
sql_text,
COUNT(*) AS execution_count,
AVG(granted_mb) AS avg_granted_mb,
MAX(granted_mb) AS max_granted_mb,
MIN(granted_mb) AS min_granted_mb
FROM ParsedEvents
GROUP BY sql_text
ORDER BY avg_granted_mb DESC;

Now you can start dealing with the queries involved in that pesky wait before the problem brings your server to a screeching halt! By the way, the queries may lead you to a design problem in your tables that can cause high memory grants. More about that in a future post!

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post How to Find Queries Causing RESOURCE_SEMAPHORE Waits in SQL Server appeared first on The SERO Group.

As I sat there, I ended up reflecting back on 2025. I found myself gravitating to these three questions:

• What went well this year?
• What did I learn?
• What should I focus on next year?

If you’re a leader, I’m guessing you rarely get this kind of thinking time during your workday. I know I don’t. Our calendars are packed with calls, team meetings, and those “quick questions” that turn into two-hour troubleshooting sessions.

But here’s what I’ve learned: the quality of your strategic decisions is directly tied to the quality of your thinking time.

And thinking time doesn’t happen by accident. You have to protect it.

What Went Well This Year?

When I asked myself this question, I didn’t think about our biggest projects or flashiest achievements. I didn’t think about when we migrated almost 2,000 databases as part of an upgrade project. Or the performance tuning we did that resulted in a $36,000 reduction in annual Azure spend for a client.

Instead, I thought about the relationships we strengthened. The trust we built with clients. The problems we solved before they became crises.

For you, this might look like:

• The audit that went smoothly because your security documentation was solid
• The successful disaster recovery test that was possible because you kept refining the process
• The team member you mentored who’s now ready for more responsibility
• The support resources you provided your team through a trusted partner

These aren’t always the things that make it into board reports. But they’re the foundation that everything else is built on.

What Did I Learn?

This year reminded me of something Eisenhower once said: “Plans are worthless, but planning is everything.”

The need for planning cannot be overstated. It’s critical. Even if the plan doesn’t always work out the way you intended.

The plan itself wasn’t the point. The thinking I did while creating the plan was the point.

Because I’d thought through our capacity, our ideal client profile, and our service delivery model, I could adjust quickly when reality didn’t match my spreadsheet. I knew which opportunities were a good fit for us and which ones to let go. Because we’ve intentionally built a small but incredibly talented team that genuinely wants to see our clients succeed, we were able to identify and create ways to help them.

I watched the same dynamic play out with clients. The institutions that had documented their SQL Server environments, tested their disaster recovery plans, and mapped their compliance requirements adapted quickly when needed. They were positioned for success even when the unexpected happened.

Planning isn’t about predicting the future. It’s about building the muscle memory to respond when the future surprises you.

What did you learn this year about planning and adapting? Maybe it was:

• That your three-year technology roadmap needs quarterly reviews, not just annual ones
• That the disaster recovery plan sitting in a SharePoint folder isn’t the same as a tested DR plan
• That “we’ll address that next quarter” eventually becomes “why didn’t we address this sooner?”
• That having an expert on call beats having a plan to find an expert when something breaks

These lessons matter. Write them down. They’re not just hindsight—they’re your blueprint for better decisions ahead.

What Should I Focus On Next Year?

For me, the answer was clear: I need to help more financial institutions and healthcare organizations understand that they have options. Most CIOs think they have two choices for database management: hire a full-time DBA (expensive and hard to find) or make do with whoever can “figure it out” (risky and unsustainable).

There’s a third option: fractional DBA services that give you expert oversight without the full-time price tag.

For you, your focus might be different. Maybe it’s:

• Finally getting your SQL Server environment documented and audit-ready
• Building a disaster recovery plan that you’ve actually tested
• Move a little further along the SQL Server Maturity Curve
• Finding a partner who understands banking compliance, not just databases

Whatever it is, the key is to actually choose something. Not everything. Something. And move toward it. Make progress.

The Power of Quiet Reflection

Here’s the thing about those early Saturday morning moments: they’re rare. And precious.

During the week, we’re in execution mode. We’re responding, reacting, solving, and fixing. That’s necessary work. But it’s not strategic work.

Strategic work requires space. It requires stepping back from the urgent to focus on the important.

So, here’s my challenge to you as we wind down 2025 and usher in the new year:

Block Off Time Just to Think, Then Protect It

Maybe it’s Saturday mornings before your family wakes up. Maybe it’s a long walk at lunch. Maybe it’s 90 minutes with your calendar blocked and your office door closed.

Whatever it is, protect it. The decisions you make during that quiet time about where to focus, what risks to address, and which partnerships to invest in will help shape your entire year.

Your Turn

As you think about the year ahead, I’d encourage you to ask yourself those three questions:

1. What went well this year? Celebrate it. Learn from it.
2. What did I learn? Write it down. It’s wisdom you paid for.
3. What should I focus on next year? Pick one or two things. Not everything.

And if one of those focus areas is “finally get our SQL Server environment to a place where I’m confident, not just hopeful,” let’s talk. That’s exactly what we help institutions do.

If you’re a CIO wondering whether your SQL Server environment is as healthy and secure as it should be, I’d be happy to have a conversation. No sales pitch. Just two people talking candidly about database management. Schedule a time here.

The post Why Quiet Reflection Leads to Better IT Strategy Decisions appeared first on The SERO Group.

One thing to point out is that in SQL Server 2022 and above, when creating a new database from the SSMS GUI or by simply using the CREATE DATABASE MyNewDB syntax, the Query Store option will be on by default. For databases restored to SQL Server 2016 or later, the Query Store’s status from the original system will remain unchanged when the database is restored on the new instance.

Let’s go through the three ways to enable Query Store.

1. Manually in SQL Server Management Studio
2. Using T-SQL
3. Using PowerShell

1. Enabling Query Store using SQL Server Management Studio:

Since you’re likely already comfortable using SQL Server Management Studio for queries and database maintenance, SMSS does offer a convenient, familiar method for getting started with Query Store.

Steps to Enable Query Store using SSMS

1. Connect to a SQL Server instance running SQL Server 2016 or higher.
2. Click the ‘+’ sign next to the Databases folder to expand and see the list of databases.
3. Right-click on the database name and select “Properties.”
4. Left-click the “Query Store” option on the left-hand side of the GUI.
5. Change the Operation Mode(Requested) option from “Off” to “Read write.”
6. Click OK to apply the change and enable Query Store.

Further Details

Here is what you will see after step 3. The Query Store option mentioned in step 4 is at the bottom of the list of options, like the below.

Left-clicking that Query Store option will cause the below to show up on the right of the SSMS GUI.

What you see when you do that are the existing defaults on 2019 and above. If you are enabling Query Store on versions 2016 or 2017, you will want to adjust additional defaults. Prior to 2019, the default for “Query Store Capture Mode” was “All.” Change this option to “Auto” instead.

Furthermore, the default for Max_Storage_Size_MB was far too low in 2016 and 2017 and could be better in 2019 as well. This value represents the maximum amount of space that Query Store data will occupy in the database in which it was enabled. A good default value to start with is 2048 MB. It may be necessary to adjust that to 4096 MB at the high end in order to capture queries for the entire length of the “Stale Query Threshold (Days)” value.

The “Stale Query Threshold (Days)” option controls how many days of Query Store data will be kept. If the max storage size is set too low for a retention value of 30 days, then Query Store will start deleting collected data in the system tables to keep Query Store below the max storage size. This could result in having less data available than you intend for troubleshooting.

The rest of the defaults are acceptable and so could be left alone without concern.

2. Enabling Query Store using T-SQL

The T-SQL language is, of course, the language of SQL Server. It is often more flexible than the SSMS GUI. Notice in the screenshot up above that there is a “Script” button. If you click that instead of clicking “ok” in the UI, then SQL Server will script out the options in the GUI into a query window. This will allow you to see what the GUI does. Using T-SQL, it is easier to enable Query Store on multiple databases. You can use a construct like sp_msforeachdb to enable Query Store for multiple databases at once.

USE [master]
GO
ALTER DATABASE [MyDB] SET QUERY_STORE = ON
GO
ALTER DATABASE [MyDB] SET QUERY_STORE (OPERATION_MODE = READ_WRITE, MAX_STORAGE_SIZE_MB = 2048)
GO

3. Enabling Query Store using PowerShell

Many accidental DBAs, those folks who were “voluntold” to start managing SQL Server, are network engineers, sysadmins, or cloud admins. Automation is often music to their ears, and in the Windows universe, PowerShell is a go-to method for automating tasks. Consequently, using PowerShell to automate the enabling of Query Store may feel natural to accidental DBAs. For the below command, the DBATools module will be needed in your environment.

Below is how Query Store could be enabled on all user databases on an instance of SQL Server. If you only want to enable Query Store on a few select databases on an instance, then add the -Database parameter with a comma-separated list of databases.

Set-DbaDbQueryStoreOption -SqlInstance ServerA -State ReadWrite ​

-FlushInterval 900 -CollectionInterval 60 -MaxSize 4096 ​

-CaptureMode Auto -CleanupMode Auto -StaleQueryThreshold 30, -WaitStatsCaptureMode ON

Also, if your SQL Server environment has the Registered Server feature set up, then PowerShell can be used to read the servers registered there, loop over them, and enable Query Store on all user databases across your environment. This would be done using the Get-DbaRegServer command in the DBATools module.

Trace Flags for Query Store

If you aren’t familiar with Trace Flags, these are numbers that Microsoft uses to enable certain kinds of behavior in the database engine. They are occasionally meant to be short-term fixes, and later the functionality in a trace flag is built into how the SQL Server database engine works. This is the case for trace flags and Query Store. There are two trace flags to know about and enable. Notice that flag 7752 isn’t needed on SQL Server 2019 and above.

Trace Flag 7745—This prevents Query Store data from writing to disk prior to shutdown or failover process so it doesn’t delay a shutdown or failover.​

Trace Flag 7752 – Loads Query Store data to memory asynchronously from query execution. This default is built into the engine in SQL Server 2019.​

Want to Work With The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post How to Enable Query Store in SQL Server: A Step-by-Step Guide appeared first on The SERO Group.

What are the benefits of enabling Query Store? While there are many technical reasons, here are my top four broad advantages to consider.

1. Free SQL Server monitoring

Your business has already paid for Query Store in the SQL Server licensing. With SQL Server 2016 and later, it is accessible at the database level. This means that for smaller shops that may not have a large enterprise environment, you don’t have to spend large sums of money to get observability from 3rd party software. Query Store’s native capture mechanisms can provide significant insight into your SQL Server’s performance, all without costing you any more money!

2. Capture foundational SQL Server performance indicators

Query Store collects the data already present in your SQL Server, displaying it in easy-to-understand graphs and reports. With Query Store, values for CPU, memory, duration, and more can be viewed based on MAX/AVG/STD Deviation metrics per query. This provides valuable insights into core metrics that shape the performance of your applications. Furthermore, this data allows your company to see not only how specific queries behaved when there was a performance problem but also to trend those queries over time to see shifts in performance.

SQL Server wait statistics are also captured and displayed in Query Store. When a query needs a resource, like CPU, or data read from disk, then a wait type is assigned to the query. These various waits affect query performance in a multitude of ways, and Query Store surfaces those performance-impacting waits for you. For example, the Query Wait Statistics report may show large bar graphs for BUFFER IO and CPU. Queries appearing in both graphs may be suffering from large table scans because of missing indexes.

Additionally, Query Store captures the query plans associated with queries. Think of query plans as the blueprint for how the query will be executed. These plans contain data about the decisions SQL Server is making about your data and how to process it. Some decisions revealed in the query plan can pinpoint performance issues. For example, query plans that regularly contain table scan operators may indicate missing indexes that force SQL Server to scan millions of rows when it only needs to retrieve a few thousand rows.

3. Talk to your vendors with data in hand

COTS vendors need to see hard data when approached with a performance problem. Query Store can provide that data. Without it, you can report a problem, but the software vendor is unlikely to consider making changes.

If you engage a DBA as a Service company, having performance data in hand will go a long way toward building a good relationship with that vendor. They will see your preparedness and be drawn to that. Also, it will allow them to solve your problem faster, and isn’t that what you really want anyway?

4. Allow your applications to take advantage of new performance features

Newer versions of SQL Server have a collection of features known as Intelligent Query Processing (IQP). Features such as memory grant feedback, degree of parallelism feedback, and more are tied into IQP. These features depend on Query Store. Without Query Store running and without using the appropriate database compatibility level, your applications are missing out on performance-enhancing features that make queries execute faster, use fewer resources, or do both at the same time.

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post 4 Key Performance Benefits of Enabling Query Store appeared first on The SERO Group.

View All Messages Processed By Database Mail

The sysmail_allitems view shows every email that Database Mail has tried to process, whether it was successful or not. This view can help you identify problems by showing you the details of the messages that were sent compared with the messages that weren’t sent by giving you the status of each email.

Here are the status values you’ll see:

View Sent Messages

Use sysmail_sentitems to see which messages were successfully sent. Database Mail marks a message as sent when it is successfully submitted and accepted by the SMTP mail server. However, just because an email was accepted by the mail server does not mean it was actually delivered to the recipient. This just means that SQL Server succeeded in giving the message to the email server, and it is up to the email server to actually send the email. If something went wrong after SQL Server passed it off (like a bounce or spam filter snag), you won’t see that here. Those kinds of issues are up to the mail server to handle and won’t show up in SQL Server logs.

View Unsent Messages

Use the sysmail_unsentitems view to find emails still waiting to be sent or retrying after a failure.
Messages marked unsent or retrying remain in the mail queue and could be sent at any time.
Normally, you will not see many messages here unless there is a delay or email processing issue.

Database Mail marks a message as unsent when it waits in the queue but has not yet been processed.
If a message shows a retrying status, Database Mail tried to send it but could not reach the SMTP server. Retry behavior depends on the settings for Account Retry Delay and Account Retry Attempts.
(For configuration details, see the sysmail_configure_sp stored procedure.)

View Failed Messages

The sysmail_faileditems view is used to return only the messages with the failed status. Use this view to determine which messages were not successfully sent by Database Mail and get message details to help you identify the nature of the problem.

To search for errors that are related to failed emails, use the sysmail_faileditems view to get the mailitem_id of the failed email, and then search for that mailitem_id in sysmail_event_log.

Microsoft also offers this extensive list of Database Mail troubleshooting techniques.

View Email Attachments

Use the sysmail_mailattachments view to list each attachment sent by Database Mail and its properties, such as file name and file size. This view does not store the attachment content, but it lets you track and verify attachments associated with each email. To link attachments to specific emails, cross-reference the mailitem_id with the other Database Mail views listed above.

Take Control of Your Database Mail

Don’t let email issues slow you down. Proactive SQL Server Database Mail troubleshooting keeps your environment stable and your team confident.

Tired of Troubleshooting SQL Server Issues Alone?

Let The SERO Group help you keep your SQL Servers running smoothly. Schedule a quick, no-pressure discovery call today.

The post How to Troubleshoot SQL Server Database Mail Issues Using Built-In View appeared first on The SERO Group.

1. Recovering after a database outage
2. Database migrations

What is a tail-log backup?

Tail-log backups capture transaction log records that haven’t been backed up yet and set the database into a “restoring” state. Think of it as the last transaction log backup taken right before a database is restored, moved, or damaged. Its primary purpose is to capture the “tail” end of the log (any transactions that occurred since the last regular log backup to prevent data loss).

When are tail-log backups important?

Scenario 1: Preventing data loss after a failure

Imagine that you schedule transaction log backups to occur every 15 minutes. At 10:05 AM, the server hosting your database experiences a critical failure, taking the database offline. Your last log backup was at 10:00 AM. This means that transactions that have occurred between 10:00 AM and 10:05 AM would be lost without a tail-log backup.

The tail-log backup bridges this gap, capturing those final crucial log records and allowing you to restore the database to the exact point of failure. Depending on the damage, you may need to add additional options for this backup to succeed. See here for those options.

Scenario 2: Supporting a smooth database migration

If you’re migrating a database to a new instance, tail-log backups can be beneficial as well. Let’s say you have a migration coming up from SQL Server 2016 to a new SQL Server 2022 instance. You’ve pre-staged the database on the new instance by restoring the latest Full and have been applying transaction log backups periodically without recovery throughout the week leading up to migration day. On migration day, you need to ensure the following happens:

1. All transactions are captured up to and right after the maintenance window begins.
2. Ensure the database on the old instance can no longer accept new connections. You don’t want new transactions landing here by accident.
3. Restore the final transaction log backup on the new instance and recover the database.

A tail-log backup can help in this scenario as well. You see, once you perform a tail-log backup, the database you performed it on is placed into the “restoring” state, which doesn’t allow connections. This ensures no future transactions can be written. Just in case a connection string wasn’t updated somewhere during the migration (I’d personally rather the connection fail vs. being able to connect to the database that is no longer in use). Once the migration is complete, including testing and validation, the old database can be dropped.

Let’s take a look at the requirements needed before you can utilize tail-log backups.

Requirements for tail-log backups

To perform a tail-log backup, the following conditions must be met:

Recovery model

The database must be in the FULL or BULK_LOGGED recovery model. Tail-log backups are not possible (or needed) in the SIMPLE recovery model, as the transaction log is automatically truncated.

Prior full backup

At least one full database backup must have been taken previously.

Log file accessibility

The transaction log file (.ldf) must be accessible and largely intact, even if the data files are damaged or the database is offline.

You can determine if your database meets the first two requirements by using a query similar to the one below.

USE MSDB
SELECT distinct
	backupSet.[Database_Name],  
	s.recovery_model_desc AS RecoveryModel,
	backupmediafamily.logical_device_name AS LogicalDeviceName, 
	backupmediafamily.physical_device_name AS PhysicalDeviceName, 
	backupset.expiration_date AS ExpirationDate, 
	backupset.name AS Name, 
	backupset.[description] AS [Description], 
	backupset.user_name AS UserName, 
	backupset.backup_start_date AS StartDate, 
	backupset.backup_finish_date AS EndDate, 
	DATEDIFF(mi, backupset.backup_start_date, backupset.backup_finish_date) AS DurationInMinutes,
	CAST(CASE backupset.type 
	WHEN 'D' THEN 'Database' 
	WHEN 'L' THEN 'Log' 
	WHEN 'I' THEN 'Differential' 
	WHEN 'F' THEN 'File' 
	WHEN 'G' THEN 'Diff File' 
	WHEN 'P' THEN 'Partial' 
	WHEN 'Q' THEN 'Diff Partial' 
	END AS NVARCHAR(128)) AS BackupType, 
	--backupset.compressed_backup_size / 1048576 , 
--	backupset.backup_size / 1048576,
	ISNULL(backupset.compressed_backup_size, backupset.backup_size) / 1048576 as SIZE,
	is_snapshot,
	is_copy_only,
	GetDate() AS DateChecked --, *
FROM msdb.dbo.backupmediafamily AS backupmediafamily
INNER JOIN msdb.dbo.backupset AS backupset ON backupmediafamily.media_set_id = backupset.media_set_id
INNER JOIN master.sys.databases as s ON backupset.database_name = s.name
WHERE     (CONVERT(datetime, backupset.backup_start_date, 102) >= GETDATE() - 1)
AND backupset.server_name = @@servername  --Filters out databases that were restored from other instances.
AND backupSet.[Database_Name] = 'YourDatabaseName'
AND backupset.type = 'D'
--AND backupSet.Type = 'D'
ORDER BY StartDate --DurationInMinutes DESC

How to perform a tail-log backup (high-level)

The command is a variation of the standard BACKUP LOG statement. The key difference often lies in the options used, particularly WITH NORECOVERY or WITH NO_TRUNCATE.

Scenario 1: Database damaged/not starting (log file intact)

In this scenario, you may have lost a drive containing your data files (.mdf). You’re lucky because you’ve been following the old adage of keeping your data files and log files on separate disks so the log file is available.

If the database data files are damaged or missing, the database cannot start normally. You can attempt a tail-log backup using WITH NO_TRUNCATE. This tells SQL Server to back up the log records without trying to access the data files or truncate the inactive portion of the log, which might fail since the database is damaged.

BACKUP LOG ExampleDB
TO DISK = '\\YourBackupShare\Backup\ExampleDB_TailLog_NoTruncate.trn'
WITH NO_TRUNCATE;

Scenario 2: Planned migration

In scenario 2, you’re migrating the database to a new instance and must ensure all transactions are captured. I’ll typically switch the database into SINGLE_USER mode and kill all other connections when doing so.

ALTER DATABASE ExampleDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Perform this step once your migration window has started and any applications, scheduled tasks, jobs, etc. have been stopped.

Perform the tail-log backup.

BACKUP LOG ExampleDB
TO DISK = '\\YourBackupShare\Backup\ExampleDB_TailLog.trn'
WITH NORECOVERY;

Here’s what happens when you run this backup.

1. The final log records are backed up to ExampleDB_TailLog.trn.
2. The ExampleDB database is put into the RESTORING state.
3. No further transactions can occur in the original ExampleDB database.
4. You can now proceed to restore any subsequent differential/log backups that you haven’t restored yet and, finally, this tail-log backup (using WITH RECOVERY) on the target server.
5. Once restored and recovered, don’t forget to place ExampleDB into MULTI_USER mode on the target server.

Tail-log backup process checklist

Here’s a quick checklist for performing a planned tail-log backup (like for a migration):

• Verify Recovery Model: Ensure the database is in FULL or BULK_LOGGED mode.
• Check Backup History: Confirm a recent full backup exists. Regular log backups should be running.
• Notify Users: Inform users of the planned downtime. Work with all other teams that depend on the database to determine a sufficient maintenance window for the migration. They’ll need to update connection strings, scheduled jobs, SSIS packages, etc., to point to the new database location.
• Restrict Access: Prevent new connections/transactions just before the backup.
• Execute BACKUP LOG … WITH NORECOVERY: Run the command, specifying a clear path and filename.
• Verify Backup File: Ensure the .trn file was created successfully.
• Confirm Database State: Check that the source database is now in the RESTORING state.
• Proceed with Restore: Use the tail-log backup as the final restore step on the target server or for recovery.
• Set database to MULTI_USER: If you’ve placed the source database in SINGLE_USER mode just prior to performing the tail-log backup, the restored database on the target will be in SINGLE_USER mode as well. To allow connections, be sure to switch it to MULTI_USER.

In conclusion

While often overlooked in basic backup discussions, the tail-log backup is a vital tool in the SQL Server DBA’s toolkit. It provides the critical ability to capture the very last transactions before a database restore or migration, minimizing data loss and ensuring the most up-to-date recovery possible. Understanding when and how to use it is key to robust data protection and seamless database migrations.

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post Why Tail-Log Backups Matter for SQL Server Recovery and Migration appeared first on The SERO Group.

If you’re responsible for operational stability, data integrity, or risk, it’s essential to understand the impact of undermanaged SQL Servers. Read on to discover the biggest issues—and how to prevent them before they cause problems. We’ll also show you how to build a strong business case for proactive SQL Server management.

Three Biggest Liabilities of Undermanaged SQL Servers

1. Downtime Is Costly—and More Common Than You May Think

Let’s start with the hard numbers. In the financial services industry, the average cost of IT downtime is estimated at $9,000 per minute for larger institutions. While community banks and credit unions may not hit that number, even smaller outages can disrupt transaction processing, customer support, and access to critical data—leading to lost revenue and reputational damage.

Infosecurity Magazine recently reported a study from Contrast Security that indicated that over half (54%) of global financial institutions experienced cyberattacks in the past year where data was destroyed by adversaries. 

More tellingly, a 2023 Uptime Institute report found that over one-third of data center outages across all industries stemmed from system and software issues—many of which are database-related. These are not rare events. They’re happening every day in organizations that don’t have a dedicated plan for monitoring and managing their SQL Servers.

2. Security Threats Are Rising—and Databases Are a Target

As financial institutions increase their digital footprint, SQL Servers become even more attractive to cybercriminals. In 2024, the average cost of a data breach in the financial sector rose to $6.08 million, according to industry research reported in the ABA Banking Journal. That’s a 22% premium over the global average, reflecting the high value of financial data and the regulatory scrutiny that follows a breach.

Unpatched SQL Server instances, misconfigured access controls, and lack of encryption are all common vulnerabilities in unmanaged environments. Bad actors know this, and they exploit it.

Without regular audits, patching schedules, and proactive security monitoring, your institution could be one missed update away from its next major incident.

3. Performance Issues Impact Productivity and Customer Experience

An unmanaged SQL Server environment doesn’t just create security risks; it can slow down your business. Query bottlenecks, deadlocks, resource contention, and stale indexing strategies can cripple performance over time.

For your internal teams, this means longer wait times for reports and slower access to operational systems. For customers, it can mean delays in processing payments, loan applications, or online transactions.

Each delay has the potential to damage your reputation with your customers and to frustrate your team. Aren’t you tired of hearing, “I’m sorry, my computer is just slow today,” when you’re trying to get something done over the phone?

There’s Real ROI in Proactive SQL Server Management

The risks and the costs are clear. But that’s not the end of the story.

The upside is just as compelling. Here are some key benefits of a properly managed SQL Server estate.

Enhanced Performance

• Optimized Queries: Properly tuned SQL queries execute faster, leading to quicker application response times and improved user experience. 
• Efficient Resource Utilization: Monitoring and managing resources like CPU, memory, and disk I/O prevent bottlenecks and ensure optimal performance. 
• Database Optimization: Indexing, partitioning, and other optimization techniques improve data access speed and reduce query execution time. 

Reduced Costs:

• Resource Optimization: By identifying and addressing performance issues, you can optimize resource utilization and potentially reduce hardware costs. 
• Lower Downtime: Proactive maintenance and monitoring minimize downtime, reducing business disruption and associated costs. 
• Improved Security: Strong security measures prevent data breaches and compliance issues, which can result in significant financial penalties. 

Improved Data Management:

• Data Integrity: Proper backup and recovery procedures ensure data integrity and prevent data loss. 
• Compliance: Meeting regulatory requirements and industry standards reduces the risk of penalties and legal issues. 
• Data-Driven Decisions: Access to accurate and timely data enables better decision-making and improved business outcomes. 

What Proactive SQL Server Management Looks Like

Proactive management isn’t just about reacting to alerts—it’s about preventing problems before they start. This includes:

• Proactive Daily Health Checks
• Regularly reviewing SQL Server and Windows log files
• Real-time monitoring and alerting
• Regular performance tuning and index optimization
• Patch management
• Vulnerability scanning
• Secure access controls and encryption enforcement
• Backup validation and disaster recovery planning
• Monthly or quarterly health checks and reporting
• Annual Center for Internet Security (CIS) Benchmark Assessments

Whether you manage your servers in-house or partner with a specialized team like The SERO Group, having a defined strategy can reduce your operational risk while maximizing the value of your technology investments.

The Bottom Line: Proactive SQL Server Management is a Sound Investment

Your SQL Servers are too important to be treated as set-it-and-forget-it infrastructure. As regulatory pressures grow and customer expectations rise, your institution needs systems that are healthy, secure, and reliable.

By investing in professional SQL Server management, financial institutions can reduce downtime, strengthen cybersecurity, and improve performance—while freeing internal teams to focus on their primary duties.

Don’t wait for a breach or a breakdown to take action. Make your SQL Server estate’s health and resilience a strategic priority.

Want to learn more about how The SERO Group helps financial institutions keep their SQL Servers healthy, secure, and reliable? Schedule a no-obligation discovery call.

Learn more about our:

• SQL Server CIS® Benchmarks™ Assessment
• SQL Server Health Check

The post The Costs of Undermanaged SQL Servers for Financial Institutions appeared first on The SERO Group.

Just to be clear, storing sensitive information as a clear text string is a really, really, really bad idea.

Not encrypting information in a database can cause serious problems. As just one example, if the database is compromised, all user passwords could be exposed. Data breaches are becoming more and more common. If the authorities come knocking on your door, you need to be able to show them that you at least made a concerned effort to protect that data.

Encrypting text that will need to be decrypted

In some cases, you may be able to store your sensitive data as strongly encrypted text that will never need to be decrypted. For example, hashing a password used for your application login and then just comparing the hashed password for the login instead of the actual password. But, in most cases, being able to decrypt the sensitive data is going to be necessary.

In these cases,  ENCRYPTBYPASSPHRASE (available in SQL Server 2008 and up) offers one of the simplest ways for you to encrypt sensitive information in a way that can also be decrypted (by using DECRYPTBYPASSPHRASE). At its very basic, ENCRYPTBYPASSPHRASE requires two mandatory arguments: a passphrase used to generate the encryption key and the text to be encrypted.  Notice that it specifies a passphrase, not password. There is an important difference between these two.

A passphrase vs. a password

As described in the ENCRYPTBYPASSPHRASE documentation: 

A passphrase is a password that includes spaces. The advantage of using a passphrase is that it is easier to remember a meaningful phrase or sentence than to remember a comparably long string of characters.

Many people don’t realize that you can use a space as a legitimate special character in most passwords. By doing this, you can generate a much more secure password sentence (or phrase) instead of a single word. An example of a passphrase may be something like “I forgot my password!”

Just to be clear, a space is not required in your passphrase for ENCRYPTBYPASSPHRASE. If you wanted to use a GUID for your passphrase or a random string such as “Zgt9$Ex%*unZO8Z},” that is perfectly acceptable.

Using ENCRYPTBYPASSPHRASE

For the examples in this post, I am going to use the encryption passphrase “This is my Passphrase!”, and the text to be encrypted is “ABC123”.

The basic syntax is:
ENCRYPTBYPASSPHRASE(‘encryption passphrase’, ‘text to encrypt’)

There are other arguments that can be used with ENCRYPTBYPASSPHRASE (see MSDN Doc), but for this simple example we are just using the two mandatory arguments.

To view the encrypted value of the text “ABC123”, you would use this script:

SELECT ENCRYPTBYPASSPHRASE(N'This is my Passphrase!', N'ABC123');

That SELECT statement will return a VARBINARY value such as: 0x0100000093EEC20B790EF208B1FB631F0AB3028E3A8C196643C4BD578528A0DFAE7AB45B

It is important to note that the VARBINARY value returned from ENCRYPTBYPASSPHRASE is nondeterministic, meaning that even with the same input it will not generate the same output every time.  So you can run the exact same SELECT statement multiple times and get a different result each time.

Thankfully, this output has no bearing on using the DECRYPTBYPASSPHRASE function. As long as you have the correct passphrase, DECRYPTBYPASSPHRASE will successfully decrypt any of those VARBINARY results to their original value.

Storing an encrypted value in a table

Now that we know how to encrypt a sensitive text string, let’s take a look at how to store that encrypted value in a table.  Since the value returned from ENCRYPTBYPASSPHRASE is a VARBINARY data type, that is how we want to store it since this is also the data type required by DECRYPTBYPASSPHRASE.

The first thing we need to do is determine the size of our encrypted column in our table. The VARBINARY values returned by ENCRYPTBYPASSPHRASE can vary in size, with maximum size of 8,000 bytes. The size of the returned value is going to depend on the size of the actual text being encrypted. You can use the DATALENGTH function to help figure that out. If you have a way to control the maximum allowed length of the sensitive text value you want to encrypt, use that size for your table column, but try not to use VARBINARY(8000) if you don’t have to.

Here is a simple example of storing our encrypted text in the [Password] column of a table:

CREATE TABLE dbo.Users ([UserName] VARCHAR(50), [Password] VARBINARY(50))
 
INSERT INTO dbo.Users ([UserName], [Password])
VALUES ('Charlie Brown', ENCRYPTBYPASSPHRASE(N'This is my Passphrase!', N'ABC123'))
 
SELECT [UserName], [Password]
FROM dbo.Users

Using DECRYPTBYPASSPHRASE

Now that we have our sensitive text encrypted, we need to be able to decrypt it as well.  This is easily done by using the DECRYPTBYPASSPHRASE function with the same passphrase we encrypted our text string with. However, DECRYPTBYPASSPHRASE also returns a VARBINARY value, which we will have to convert to a string.  This can be done by adding a CONVERT function to our SELECT statement.

SELECT [UserName], CONVERT(NVARCHAR, DECRYPTBYPASSPHRASE(N'This is my Passphrase!', [Password]))
FROM dbo.Users

Now you should see your decrypted value returned correctly in clear text. ENCRYPTBYPASSPHRASE offers a quick and easy way for you to encrypt text in SQL Server and can be useful for encrypting sensitive information if you need to be able to decrypt it later. 

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post How to Encrypt Sensitive Text in SQL Server with ENCRYPTBYPASSPHRASE appeared first on The SERO Group.

Monitoring the growth of your SQL Server transaction log files is crucial for maintaining database performance and ensuring system reliability. Unchecked transaction log growth can lead to disk space issues and system outages. Let’s take a look at some of the causes of transaction log file growth, why it’s important to monitor, and how you can use the sp_whoisactive procedure to keep an eye on it.

What Causes the Transaction Log File to Grow

The transaction log file records all transactions and database modifications made by each transaction. Several factors can contribute to its growth:

• Long-Running Transactions: Transactions that take a long time to complete prevent the log from truncating because SQL Server needs to maintain the log records until the transaction is committed.
• Recovery Models:
  • Full Recovery Model: In this model, the transaction log will not truncate until a log backup occurs. If log backups are not taken regularly, the log file will grow indefinitely.
  • Bulk-Logged Recovery Model: Similar to the full recovery model, it is used for bulk operations. Log growth can still be an issue if backups aren’t scheduled appropriately.
  • Simple Recovery Model: Although SQL Server automatically truncates the log in this recovery model, you must still watch for transactions that are making large changes all at once. For instance, if you update millions of rows in one transaction, this could be enough to cause the log file to grow.
• Lack of Log Backups: Without regular log backups in the full or bulk-logged recovery models, the log cannot truncate, leading to continuous growth.
• High Transaction Volume: A sudden spike in transaction activity can cause the log file to grow rapidly to accommodate the increased volume.
• Replication and Availability Groups: Features like availability groups and replication can delay log truncation until the data is sent to the replicas or replicated databases. Seeing the log file continue to grow even after taking a log backup? Check the log_reuse_wait_desc column in sys.databases. It’ll indicate why.
• Open Transactions: Uncommitted transactions hold on to log space because SQL Server needs the log records to roll backup if necessary. Who hasn’t started their session with “begin transaction” and gone home for the weekend (forgetting the commit)?

Why it Matters

The impact can be massive, from crashing applications to filling up disk space and affecting all other databases on the same drive.

• Disk Space Consumption: Uncontrolled log growth can consume all available disk space, leading to application failures and downtime.
• Performance Degradation: Large log files can slow down database operations, including backups and recovery processes, affecting overall system performance.
• Recovery Time Objectives (RTOs): In disaster recovery scenarios, large transaction logs can increase the time it takes to restore databases, impacting business continuity.
• Maintenance Challenges: Managing and maintaining oversized log files can be cumbersome, requiring more time for routine operations like backups.
• Risk of Data Loss: If the disk runs out of space due to log growth, new transactions cannot be logged, leading to potential data loss or corruption.

How to monitor it using sp_WhoIsActive

sp_whoisactive is a powerful stored procedure developed by Adam Machanic that provides a comprehensive view of the current activity on your SQL Server. It can be used to monitor transaction log growth.

Here’s how you can use it:

Installation

First, download the script from https://github.com/amachanic/sp_whoisactive and run it on your instance. I usually place it in a database named DBA vs. master.

Monitoring Active Sessions

Run the procedure to see all active sessions:

USE DBA
GO
EXEC sp_whoisactive

Identifying Long-Running Transactions

To focus on transactions that might be causing log growth, look for sessions with high values in the tran_log_writes column, which shows the number of log records written by the session. You’ll need to set the @get_transaction_info to 1 to include transaction details.

EXEC sp_whoisactive @get_transaction_info = 1

This will add columns related to transaction duration and log usage.

Ordering by log writes

If you’re interested in sessions consuming the most log space, order the results accordingly:

EXEC sp_whoisactive @get_transaction_info = 1, @sort_order = '[tran_log_writes] DESC'

Automating Monitoring

Schedule sp_whoisactive to run at regular intervals and log the output to a table for historical analysis or to send an alert if certain thresholds are met. This can help you identify patterns over time (i.e., Mike usually starts a new session every Friday evening and leaves for the weekend.). The following code will create a table, dbo.WhoIsActiveLog, with the appropriate schema. The second statement will then execute sp_whoisactve and store the results within this table.

--create the dbo.WhoIsActiveLog table
DECLARE @schemaDefinition VARCHAR(MAX)
EXEC sp_WhoIsActive 
    @find_block_leaders = 1, 
	@get_transaction_info = 1,
	@get_locks = 1,
	@return_schema = 1,
	@schema = @schemaDefinition OUTPUT

SELECT @schemaDefinition =  REPLACE(@schemaDefinition,'<table_name>','dbo.WhoIsActiveLog')
EXEC (@schemaDefinition)
GO
EXEC sp_WhoIsActive 
    @find_block_leaders = 1, 
	@get_transaction_info = 1,
	@get_locks = 1,
	@destination_table = 'dbo.WhoIsActiveLog'

Once you identify sessions causing excessive log growth, you can investigate the underlying queries or processes:

• Optimize Queries: Rewrite inefficient queries to reduce transaction time.
• Adjust Recovery Models: If appropriate, and point-in-time recovery isn’t required, consider switching to the simple recovery model. However, this won’t help if it’s a long running transaction making many changes simultaneously.
• Schedule Regular Backups: Ensure that log backups are taken frequently to prevent log file bloat.
• Kill Problematic Sessions: As a last resort, terminate sessions that are causing issues, but be cautious of potential data loss.

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post Prevent SQL Server Outages by Monitoring Transaction Log Growth appeared first on The SERO Group.

I should also mention that the results of these queries will only go back to the last SQL Server start time. Anything that occurred before then won’t be available.

Logins Vs. Users

First, let’s take a look at the difference between “logins” and “users” in SQL Server, as people sometimes get them confused, or think they’re the same thing. A “login” allows access to a SQL Server instance. A “user” allows access to a specific database on that instance. Usually, a user is tied to a login, although you can have a user that is not tied to a login (known as a loginless user).

When was the last time a login was used?

--list of logins and last time each logged in
SELECT [Login] = login_name 
	,[Last Login Time] = MAX(login_time)
FROM sys.dm_exec_sessions
GROUP BY [login_name];

Which logins have logged in within the last X hours?

--all logins in the last 4 hours
SELECT [Login] = login_name
	,[Last Login Time] = login_time
	,[Host] = HOST_NAME
	,[Program] = PROGRAM_NAME
	,[Client Interface] =  client_interface_name
	,[Database] = DB_NAME(database_id)
FROM sys.dm_exec_sessions
WHERE [login_time] > DATEADD(HH,-4,getdate())--modify date as needed
ORDER BY [login_time] desc

How many times has each login logged in within the last X hours?

--login counts for the last 4 hours
SELECT [Login] = login_name
	,[Last Login Time] = MAX(login_time)
	,[Number Of Logins] = COUNT(*)
FROM sys.dm_exec_sessions
WHERE [login_time] > DATEADD(HH,-4,getdate())--modify date as needed
GROUP BY [login_name]
ORDER BY [Login] desc

Which logins have Sysadmin access?

--check for logins with sysadmin access
SELECT [Login] = name
	,[Login Type] = type_desc
	,[Disabled] = is_disabled
FROM     master.sys.server_principals 
WHERE    IS_SRVROLEMEMBER ('sysadmin',name) = 1
ORDER BY [Login]

Checking A User’s Access To Databases

This query will return a list of databases that the specified user has access to. This will work for SQL Server Logins as well as Active Directory Logins. This is done by specifying EXECUTE AS LOGIN just before the query. (also be sure to specify REVERT after the query runs)

It should be noted that this query only shows you what databases the user can access, not the permissions the user has on the databases.

EXECUTE AS LOGIN = 'YourDomain\User.Name' --Change This
	SELECT [name]
	FROM MASTER.sys.databases
	WHERE HAS_DBACCESS([name]) = 1
REVERT

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post Useful Scripts For SQL Server Logins and Permissions appeared first on The SERO Group.