You can’t manage what you don’t know about. You can’t improve what you’re not measuring. If you have SQL Servers installed somewhere that people have forgotten about, and you probably do if you haven’t used an automated tool to scan for them, then you can’t manage them. You certainly can’t monitor those SQL Servers. This means that you also don’t know how well, or badly, they are performing or what bad practices and habits are lurking, just waiting to cause problems. 

All of this can lead to: 

• Lost time because your team is fighting performance problems that can’t be identified due to the right data being unavailable. 
• Lost revenue from outages that could have been prevented or shortened with the right data. 
• Poor practices and bad habits stay hidden because there isn’t anything to surface the issues. 

What should you monitor on your SQL Servers?

We could debate this topic ad nauseam, so instead, I’ll provide a list of foundational things to consider.

Common server and database settings:

Whatever is used to monitor and manage SQL Servers in your environment would do well to have a section where you can see how instance and database settings are configured. Review this information about your environment and compare what you find to known best practices. 

Host and instance memory usage:

This includes not just a raw number about percentage of RAM used or free, like you can get from the Available Bytes counter, but also things like other Performance Monitor counters such as Free List Stalls/second, Lazy Writes/second, Page Life Expectancy per NUMA Node, and Memory Grants Pending. Taken together, these metrics can help identify memory pressure. 

Host and instance CPU usage:

This one is fairly straightforward but still worth mentioning.

IOPs (Input/Output/second):

You need some measurement of the number of reads and writes occurring on your storage and whether those IOPs are experiencing any latency. Ideally, the metrics will also surface when the latency is happening. If latency is detected, inevitably, the next questions are, “When is it happening?” or “What queries are causing it?” 

Queries and associated waits:

You need to be able to see what queries were running during a certain time and what wait types those queries experienced. You need this same information for what is running at this moment so you can troubleshoot live issues. Without this, it’s really difficult to know what the problem is, or even if the problem is on the SQL Server side versus somewhere else. 

Blocking/Deadlock metrics:

Monitoring should include the number of blocking sessions and deadlocks. This is critical information to have because simply looking at the duration of queries may not tell you the whole story. A query, or set of queries, may be running long because they are experiencing blocking and not because the queries themselves are poorly constructed. Deadlock metrics will help point in the direction of needed application changes, index changes, or both.  

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 SQL Server Monitoring: Why It Matters and What You Should Track appeared first on The SERO Group.

Here are five reasons not to restart to solve a performance problem.

1. Restarting SQL Server only covers up the problem.

Restarting SQL Server is only a short-term fix, because whatever caused the problem is likely to recur. For example, if the problem you’re facing is blocking, it’s fairly likely that the queries involved will run at the same time again and cause the same issue again. As another example, if some of the queries have large memory grants, those queries will run again and will likely also consume large amounts of memory the next time they run. Do you have certain queries that use a lot of CPU? Restarting won’t help any of these issues in the long term.

2. Restarting clears the SQL Server cache.

This can cause issues with CPU usage to recompile plans. Plan recompilation can cause its own performance problem called parameter sniffing. This cache clearing effect also means more IO on the disks to read data back into memory. For SQL Server instances running 2017 and 2019 Enterprise Edition, there is a feature called Memory Grant Feedback. This feature helps with the size of memory grants for queries. The catch in 2017/2019 is that it does not persist. The memory Grant Feedback process is all in memory. So, when the SQL Server is restarted, the feedback process starts over.

3. Restarting SQL Server clears out helpful troubleshooting metrics.

SQL Server keeps track of a variety of metrics, like wait statistics and index usage information. Wait statistics are SQL Server’s way of keeping track of what resources are either being consumed or are needed for queries to run. This data can be very helpful at the server level and the query level. At the server level, certain patterns are classic indicators of certain kinds of workload problems. At the query level, wait statistics can be used to guide performance tuning efforts for individual T-SQL statements or entire stored procedures. When SQL Server restarts, this data is lost.

The same is true with index usage information from the missing index dynamic management views. A restart clears these statistics.

4. Restarting SQL Server kills all sessions that were running, instead of just dealing with the problematic sessions.

For example, if the problem is blocking, then there may be as few as 2 sessions involved in the performance problem. Restarting the SQL Server kills all sessions, causing rollback of work for many sessions instead of just the two involved in the issue. The SQL Server restart creates downtime by killing more sessions than is needed.

5. Restarting SQL Server triggers the crash recovery process.

If you restart SQL Server, this can mean long, single-threaded rollback for long-running transactions. I’ve seen this take up to 45 to 60 minutes in some cases. If the instance is older, then the modern feature called Accelerated Database Recovery can’t save you from a long rollback, and the database will be inaccessible until crash recovery completes. This means the outage will last even longer.

A Better Approach

So, what else can you do if you are experiencing performance problems? I’d suggest that you

1. Run and examine the output of sp_whoisactive
2. Run and examine the output of sp_BlitzFirst
3. Run and examine the output of sp_QuickieStore
   or
4. Contact a SQL Server consultant and ask for help if you don’t know how to do those first three things.

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 5 Reasons Why Restarting SQL Server Can Make Performance Problems Worse appeared first on The SERO Group.

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.

A Refresher on the SQL Server Maturity Curve

First, let’s remind ourselves of what the progression of the SQL Server maturity curve looks like, as discussed in this blog.

1. Reactive—Firefighting
2. Managed—Gaining control
3. Optimized—Running proactively
4. Strategic—Turning data into advantage

How SQL Server Query Store Helps Businesses Take Control

Query Store’s features can help shift businesses away from break/fix firefighting. Because the Query Store collects runtime metrics for query performance, as well as query plans, businesses aren’t running blind anymore.

You want to know what was going on last Tuesday at 3:15PM when the app was slow? Look at Query Store to see what queries were running and what plans the queries were using. There may have been a change in the query plan, and after that is when people reported that the app was slow. Those query plans may also reveal missing indexes that can help performance.

Additionally, the Query Store report called “Top Resource Consuming Queries” will show how much CPU and RAM were involved in those queries. The Query Wait Statistics report will represent the resources that queries were waiting on as very visible bar graphs. This report enables IT professionals to see that issues like locks or disk IO are affecting their queries.

This type of data gives you the insight needed to start gaining control over your environment.

Moving from Managed to Strategic with Query Store

Now your business can move to the next stage of maturity, which is being proactive. For example, now you can start rewriting queries that were running when the application was slow.  Those missing index recommendations found in various query plans can be evaluated and compared to existing indexes. Perhaps a recommended and existing index can be combined into a single index that can be tested in a lower environment to see if it has a positive impact on the query plan, resulting in lower query durations or lower resource usage.

If the application is from a vendor, then you likely can’t make changes to the queries or indexing, but you now have data to provide the vendor when approaching them with performance problems.

Additionally, you can do things like forcing certain query plans, and in SQL Server 2022, you can apply query hints within Query Store so that even if an application is from a 3^rd party vendor, you can still make improvements without changing the application code. Query Hints are stored within the Query Store and applied after the code is submitted to SQL Server.

Query Store, then, empowers your business to be strategic. The team can see where the pain points are, test and prioritize issues and solutions, and hand over data to vendors when they can’t make changes themselves. This proactive, strategic work can literally save your business a lot of money by lowering resource usage, allowing for a smaller SQL Server instance. This saves money on licensing and, if you are in the cloud, saves money spent on the size of resources provisioned.

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 Query Store Drives Progress Along the SQL Server Maturity Curve appeared first on The SERO Group.

Whether you’re planning an upgrade from an aging SQL Server instance or simply staying informed about where the platform is headed, here’s what you need to know about SQL Server 2025 and how it might affect your institution.

What’s New in SQL Server 2025?

Major Changes to SQL Server Editions

Let’s start with the news that will matter most to budget-conscious institutions: SQL Server 2025 Standard Edition now supports up to 32 CPU cores and 256 GB of RAM. This is a substantial increase from previous limits and could significantly affect your licensing decisions.

For many community banks, this expanded capacity means Standard Edition can now handle workloads that previously required Enterprise Edition licensing. Given the price difference between editions, this change alone could translate into meaningful cost savings on your next upgrade or new deployment.

Express Edition also received an upgrade, with the maximum database size increasing to 50 GB. While Express isn’t typically used for core banking systems, this expanded limit makes it more viable for development environments, smaller branch applications, or testing scenarios.

Microsoft also introduced a new Standard Developer Edition that offers full feature parity with Standard Edition. This allows your development and testing environments to mirror production limitations more accurately, reducing surprises when you deploy.

Performance Improvements That Require No Code Changes

SQL Server 2025 includes over 50 enhancements to the database engine, with several performance improvements that take effect automatically—no application changes required.

The most significant is optimized locking, which uses Transaction ID locking and lock-after-qualification features to improve concurrency. In practical terms, this means reduced row and page locks during data modifications, which translates to better performance for high-transaction environments like core banking systems.

For institutions that have struggled with unpredictable tempdb growth, SQL Server 2025 introduces tempdb resource governor options that let you control how much tempdb space individual users or processes can consume. This provides better resource management and helps prevent runaway queries from affecting other workloads.

The release also includes a new ZSTD backup compression algorithm, which is particularly valuable for large database backups. Faster, more efficient backups mean shorter maintenance windows and reduced storage costs—both welcome improvements for institutions managing growing data volumes.

Security Enhancements for Regulated Industries

Security remains a top priority for SQL Server, and the 2025 release continues that focus with several enhancements relevant to financial institutions.

SQL Server 2025 integrates with Microsoft Entra for identity and access management, supporting multi-factor authentication, role-based access control, and condition-based policies. For institutions already using Microsoft’s identity services, this provides a more unified security posture across your environment.

The release also introduces enhanced password protection using a password-based key derivation function that follows NIST SP 800-63b compliance guidelines. Additionally, security cache improvements reduce the performance impact of permission changes in high-concurrency environments—a common scenario in banking applications with thousands of active connections.

For institutions running SQL Server on Linux, version 2025 adds TLS 1.3 support, custom password policies, and signed container images. Platform support also expands to include RHEL 10 and Ubuntu 24.04.

Built-In AI Capabilities

Microsoft is positioning SQL Server 2025 as the “AI-ready enterprise database,” and this release includes native support for AI workloads directly within the database engine.

New features include a native vector data type, built-in vector search capabilities, and integrated model definitions that can be defined directly within T-SQL. The new sp_invoke_external_rest_endpoint stored procedure allows you to call AI services like Azure OpenAI or ChatGPT directly from your database.

For financial institutions, these capabilities open possibilities for fraud detection, customer service automation, document processing, and other AI-driven applications without requiring separate infrastructure for vector databases or AI model hosting. However, as with any new technology in regulated environments, careful evaluation and appropriate governance will be essential before production deployment.

Developer Productivity Enhancements

SQL Server 2025 brings several features that streamline development and reduce code complexity. Native JSON support now handles documents up to 2 GB per row with dedicated JSON indexes for improved query performance. Regular expression support is now built directly into T-SQL, eliminating the need for third-party tools or workarounds.

Change Event Streaming allows real-time, event-driven applications by streaming changes directly from the transaction log to Azure Event Hubs or Kafka. Native REST API support through system stored procedures enables richer integrations with external services.

These enhancements make SQL Server more capable for modern application architectures while maintaining the reliability and security that regulated industries require.

Key Takeaways and Institutional Impact

SQL Server 2025 delivers meaningful gains for community banks and financial institutions, combining expanded Standard Edition limits, stronger security aligned with compliance expectations, and automatic performance improvements that benefit high-transaction environments. These enhancements can reduce licensing costs, improve reliability, and support more modern workloads without major application changes.

Planning Your Upgrade Path

SQL Server 2025 supports in-place upgrades from SQL Server 2014 or later, and migration methods work all the way back to SQL Server 2008. With SQL Server 2016 reaching the end of its extended support in July of 2026, now is a good time to evaluate your upgrade timeline.

Before upgrading production systems, thoroughly test your applications against the new version. While SQL Server releases rarely include major breaking changes, version 2025 does adopt TDS 8.0 with TLS 1.3 support, which can affect linked servers and replication configurations. Identify these dependencies early to avoid surprises. You’ll also want to verify support from vendor-provided applications.

Considering a SQL Server Upgrade?

Planning a SQL Server upgrade or wondering how SQL Server 2025’s new features apply to your environment? Let’s talk. Reach out to schedule a 15-minute conversation about your database strategy.

The post SQL Server 2025: What Community Banks Need to Know Before Upgrading 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.

Yet in my conversations with CIOs and IT leaders, a common theme keeps coming up: many institutions aren’t fully confident in how their SQL Servers are being managed. In fact, some don’t even realize how reactive their environments have become until an outage, audit, or breach forces the issue.

If that sounds familiar, you’re not alone. Here are five signs your SQL Server environment may be operating at an immature level—and why it matters.

1. You’re Constantly Firefighting

If your team spends more time putting out fires than moving forward with projects, that’s a red flag. When backups fail, jobs break, or users are the first to notice performance issues, you’re stuck in a cycle of reaction. Not only is this stressful, but it’s also expensive. Every hour spent firefighting is an hour not spent on strategic initiatives like digital transformation or customer experience improvements.

2. Backups Exist, but Restores Don’t

Most banks take backups. Fewer regularly test restores. The problem? A backup that hasn’t been tested is just a false sense of security. Imagine discovering in the middle of an outage that your backups are corrupt or incomplete. The financial cost of downtime for banks often runs into thousands of dollars per minute—not to mention reputational damage and potential regulatory penalties.

3. Outdated Versions and Patch Levels

SQL Server 2008, 2012, or even 2014 are still running in some banks today. If your institution is one of them, you’re carrying significant risk. Unsupported versions don’t receive security patches, leaving you exposed to known vulnerabilities. Regulators won’t accept “we meant to upgrade” as an excuse. And from a purely financial standpoint, the cost of staying current is far less than the potential cost of a breach.

4. No Real-Time Monitoring

Do you find out about problems because end users complain first? That’s a clear sign of immaturity. Mature environments have monitoring and alerts in place so issues can be addressed before they impact customers or regulators. Without that visibility, you’re operating blind—and hoping nothing goes wrong.

5. Audit and Compliance Surprises

If your last audit or exam felt like a fire drill, that’s another warning sign. Struggling to pull the right reports or demonstrate controls indicates maturity gaps. Regulatory compliance isn’t optional in banking, and weak database management practices make audits harder, slower, and more expensive than they need to be.

The ROI of Maturity

The case for maturing your SQL Server environment isn’t just about avoiding risk—it’s about return on investment.

• Reduced downtime: With the average cost of downtime in banking estimated at $5,000–$10,000 per minute, even a single avoided outage more than pays for proactive monitoring and management.
• Lower compliance costs: Mature environments simplify audits, reduce remediation effort, and build examiner confidence.
• Staff efficiency: Instead of spending 60–80% of their time firefighting, IT staff can focus on projects that move the bank forward.
• Better decision-making: Reliable, secure databases mean your leaders can trust the reports and analytics driving strategy.

Simply put: moving from reactive to mature doesn’t just save headaches—it strengthens the bottom line.

Moving from Risk to Advantage

An immature SQL Server environment costs more than it saves. The good news is that maturity is a journey, and every step forward reduces risk, improves compliance, and frees up resources for growth.

Want to go deeper on this topic? Watch the recording of our recent webinar, Navigating the SQL Server Maturity Curve. We walk you through the four stages of maturity, what each means for banks, and how to take practical next steps.

Final Thought

You don’t have to settle for firefighting, untested backups, or audit surprises. With the right approach, your SQL Server environment can shift from being a hidden liability to a true business enabler.

The post 5 Signs Your SQL Server Environment Is Immature (and How Banks Can Reduce Risk) appeared first on The SERO Group.

The Essential Backpack: Your SQL Server Toolkit

Just like I never hit the trails without my backpack, you shouldn’t manage SQL Server without the right tools. My pack contains everything I might need during a ride—and your SQL environment needs the same thoughtful preparation.

Water Supply = Maintenance Plans. The water in my pack keeps me hydrated throughout the ride. In SQL Server, your maintenance plans serve the same vital function. They keep your databases healthy with regular backups, statistics maintenance, and consistency checks. Without proper hydration on the trail, I’ll struggle. Without solid maintenance plans, your database performance will suffer just as much.

First Aid Kit = Disaster Recovery Plan. As a former Scoutmaster, the motto “Be prepared” is still deeply ingrained in my perspective. I always carry a robust first-aid kit, including bandages, antiseptic, a SAM Splint, and other emergency supplies. Hopefully, I never need them, but when disaster strikes on a remote trail, that first aid kit becomes invaluable. Your DR plan works exactly the same way. You invest time creating restore procedures, testing failover scenarios, and documenting recovery steps. When a disk fails or corruption hits, that preparation saves the day. Hopefully you never need it, but if you do, you’ll be prepared.

Pre-Ride Check: Your Daily Monitoring Routine

Before every ride, I check tire pressure, brake function, and chain lubrication. This five-minute routine prevents many mechanical issues. Similarly, your daily SQL Server health checks catch problems before they impact users.

Strava App = Monitoring Tools. My Strava app tracks distance, elevation, time, and speed throughout the ride. It tracks trends, provides insights, and even predicts finish times. Your SQL monitoring tools serve the same purpose. They help track query performance, disk usage, and resource consumption. When something’s trending in the wrong direction, you get alerts before users start complaining.

The Right Tools for the Job

In mountain biking and in SQL Server, you need the right tools and the right resources to be successful.

My backpack toolkit includes a multi-tool, spare tubes, and a mini pump. Each is designed to help with specific problems I might encounter miles from the trailhead. Your SQL toolkit should be equally comprehensive: scripts for common tasks, backup utilities, performance analysis tools, and emergency procedures.

And, of course, I never ride without my phone. It can be a lifeline should I get stranded or worse, go OTB (over the bars). Likewise, your team needs to have someone to call when your key system has problems. Sure, they can Google for answers, but it’s far better to have an expert in the industry readily available to help.

Plan for Success

The key insight? Both mountain biking and database management require proactive thinking. Reactive approaches lead to painful experiences, whether you’re walking your bike home on a flat tire or explaining to executives why the core banking system is down.

After all, both mountain biking and database management are about reducing risk while maintaining peak performance. The difference is that when your SQL Server crashes, you can’t just walk home.

Want to work with The SERO Group?

Don’t let database surprises derail your operations. The SERO Group specializes in helping financial services organizations build resilient SQL Server environments that perform when it matters most. Ready to strengthen your database infrastructure? Get started with a complimentary consultation.

The post What My Mountain Biking Backpack Taught Me About SQL Server Management appeared first on The SERO Group.

Still, even if your technical team sees the need, it can be tough to make the business case to your CFO. Since managed services would be an ongoing investment, how do you best convey their value?

Here’s how to frame that conversation to maximize your odds of getting buy-in from financial leadership.

1. Start With the Business Impact, Not the Tech

CFOs think in terms of financial risk, cost control, and business outcomes. So instead of leading with patching, query tuning, or Always On configuration, focus on:

• Avoiding costly downtime
• Reducing licensing waste
• Freeing up internal staff for higher-value work
• Protecting customer data and ensuring compliance

Example: “We had 4 hours of unplanned SQL Server downtime last year, which impacted billing, customer support, and payroll processing. Managed services would help us avoid that kind of disruption.”

2. Quantify the Cost of Doing Nothing

IT leaders often struggle to justify costs because the risk feels abstract. Make it real by putting numbers to:

• Cost of downtime: How much are lost productivity and missed revenue costing you during each outage?
• Opportunity cost: What projects are delayed because your team is busy firefighting?
• Audit and compliance penalties: Noncompliance with data protection rules (e.g., SOX, HIPAA) can get expensive fast.

If you’re not sure where to start, consider a health check or audit to quantify current gaps and risks. These numbers can make a compelling case.

3. Emphasize Cost Efficiency Over Hiring

Hiring a full-time SQL Server DBA can cost over $120,000 per year between salary, benefits, and overhead. Even after this substantial investment, you’d still have only one person managing all of your business’s needs.

With managed services, you get a team of SQL Server experts for a fraction of the cost of building that capability in-house. That includes:

• 24/7 monitoring and alert response
• Proactive maintenance
• Performance tuning
• Disaster recovery support
• License optimization

It’s not just cheaper—it’s more scalable and more reliable.

4. Show That It’s More Than Emergency Help

Many CFOs assume managed services are only about putting out fires. Make sure they understand that SQL Server managed services also work proactively. Here are a few examples of ways to highlight the potential benefits to your business:

• Preventive maintenance reduces long-term costs.
• Regular reviews help improve system performance.
• Guidance on upgrades, cloud strategy, and license optimization saves money over time.

5. Tie It to Business Continuity

When SQL Server goes down, so does the business, and CFOs understand the financial impact of disruption. Managed services ensure that:

• Your backups are actually restorable.
• Failover mechanisms are in place and tested.
• RPOs and RTOs align with business expectations.

That kind of readiness can make or break a company in a crisis.

6. Provide a Clear ROI Narrative

It can help to build a before-and-after picture:

• Before: unplanned downtime, poor performance, reactive fixes
• After: stability, predictability, reduced risk

Highlight cost savings from:

• Consolidating underused instances
• Reducing overprovisioned licenses
• Avoiding emergency consulting fees

Then, present it using the CFO’s language: predictable monthly spend, reduced risk exposure, and higher operational efficiency.

7. Offer a Pilot or Assessment

If your CFO is hesitant, suggest a low-risk starting point:

• A fixed-fee health check
• A short-term pilot engagement
• A time-boxed cost optimization review

This allows them to see the value for themselves before committing.

Why Your CFO Might Say Yes

SQL Server managed services aren’t just an IT expense—they’re a strategic investment in uptime, security, and efficiency. When you frame the conversation in terms your CFO cares about—cost, risk, and business continuity—you’ll be much more likely to get buy-in.

Need help quantifying the value for your team? Let’s talk.

The post SQL Server Managed Services: A CFO-Ready Business Case appeared first on The SERO Group.