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.

When someone has a question about the SQL Server, it’s always “Go see Tom.”

Tom just gave his two-week notice. He’s retiring to the sandy beaches of Florida to soak in the rays and fish in the blue waters.

You’re happy for Tom. But now what? It’s a bit late to begin thinking about SQL Server succession planning.

The Knowledge That Walks Out the Door

I’ve talked to many bank CIOs who have a “Tom” on their team. He’s no SQL expert, but he’s the in-house SQL go-to guy, and he knows those systems.

And that can be a scary place to be if you’re the CIO responsible for the environment.

Why?

Here’s what typically leaves with an accidental DBA:

• Undocumented configurations. Why is the production server set up that way? Tom knows. Or rather, Tom knew.
• Tribal knowledge about recurring issues. That quirky behavior every third Tuesday? Tom had a workaround. It’s not written down anywhere.
• Recovery procedures. Sure, you have backups. But does anyone else know the exact steps Tom follows when a restore is needed at 2 AM?
• Vendor relationships and escalation paths. Tom knew exactly who to call and what to say to get things fixed quickly.
• Security and access decisions. Why does that service account have those specific permissions? Good question.

Why This Matters More in Highly Regulated Industries

If you’re a community bank, this scenario isn’t just inconvenient; it’s an examiner finding waiting to happen. If you’re in healthcare, regulatory stakes are just as high.

During IT examinations, auditors specifically look for single points of failure in critical systems. If your answer to ‘Who manages your databases?’ is one person’s name, that’s a control weakness. If your answer to ‘What happens if they’re unavailable?’ is ‘We’d figure it out,’ that’s a finding.

In these industries, auditors expect you to have:

• Documented procedures for critical operations.
• Separation of duties for database management.
• Continuity plans that don’t depend on one person.
• Evidence that someone is actually monitoring your databases.

When Tom retires and you can’t answer basic questions about your SQL Server environment, you’ve got a problem. A problem that shows up in your next IT audit. Or worse, a technical issue that you cannot resolve.

The Full-Time DBA Trap

Your first instinct might be to hire a replacement. This time, you’ll hire a real DBA, someone who can also help with network tasks when needed.

Makes sense. Kinda.

However, here’s the reality:

• Really good DBAs are hard to find and are only getting harder to find. SQL Server DBAs work in a specialized niche. They’re not application developers or network administrators. As the number of companies running SQL Server has grown, the supply of experienced DBAs hasn’t kept pace. The talent gap is real.
• You can’t compete for talent. Full-time DBAs with SQL Server expertise command $100K to $150K in most markets. The bigger banks, healthcare companies, and other industries snap them up immediately.
• You don’t need 40 hours per week. Most community banks with 2 to 15 SQL Server instances need expert DBA attention, but not full-time. You’d be paying a full-time salary for a part-time need. Worse, eventually your DBA would get bored and leave.
• Two is one, and one is none. With a single DBA, how do you cover vacation, illness, or parental leave? And when that person leaves in a few years, you’re back to square one. The succession planning problem doesn’t go away. It just resets.

A Better Approach: Building Institutional Knowledge

Instead of replacing one person with another person, forward-thinking institutions are replacing person-dependent processes with documented, repeatable systems.

Here’s what that looks like:

1. Start with a comprehensive assessment. You can’t document what you don’t know. Review your entire SQL Server environment, configurations, maintenance plans, and security posture. Get outside help if needed.
2. Document everything. Create professional documentation that anyone with database knowledge can follow: configuration standards, maintenance procedures, recovery processes, escalation paths, everything.
3. Implement consistent monitoring. Stop depending on someone noticing when things go wrong. Or worse, when your phone rings. Professional monitoring catches issues before they become emergencies.
4. Create a knowledge transfer plan. Whether you’re bringing on a DBA Services team, such as our SEROShield services, or developing internal capability, make sure the knowledge gets captured and shared.
5. Test your procedures. Documentation that sits on a shelf isn’t helpful. Regular testing proves your team can actually execute when needed.

This institutional approach is exactly what managed database services providers deliver.

The Managed Database Services Provider Alternative

More community banks are solving the accidental DBA and succession planning problem by moving to a DBA services model. Instead of one person holding all the knowledge, you get:

• A team of experts who share institutional knowledge
• Documented procedures that survive personnel changes
• Predictable monthly costs instead of salary + benefits
• Professional monitoring and proactive maintenance
• Built-in redundancy and coverage
• Separation of duties that align with auditor expectations
• Examiner-ready documentation

If and when someone on the DBA team moves on, the knowledge stays with the firm. Your bank’s operational continuity doesn’t depend on any single person. In our case, each client has a primary and secondary DBA, along with documentation.

Start Before the Crisis

The accidental DBA model worked fine 15 years ago. But as regulatory expectations have increased and technical complexity has grown, it’s become a business risk you can’t afford.

Don’t wait until Tom is packing his office to figure out what he actually did all day. The time to address succession planning is before Tom gives notice. Once he’s gone, you’re in crisis mode, making rushed decisions under pressure.

Ready to Assess Your Database Succession Risk?

Our SQL Server Health Check documents your current environment, identifies knowledge gaps, and provides a roadmap for building institutional resilience, all before your version of Tom gives notice. Schedule a short, free call with us to discuss your specific situation.

The post The Accidental DBA Retirement Crisis: Is Your Institution Ready? 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.

A reactive approach may get you through the day, but it doesn’t build long-term stability, security, or confidence.

What is the SQL Server Maturity Curve?

Over the years, we’ve found that every SQL Server environment naturally falls somewhere along a maturity curve. Understanding where your SQL Server environment is today and where you want it to be helps you move from firefighting to foresight. SQL Server maturity can be best understood in four stages: reactive, managed, optimized, and strategic.

Let’s look at each stage.

1. Reactive: Firefighting

At the lowest level of maturity, we have what we call the reactive stage. This is where SQL Server environments are managed more in a ‘break/fix’ mode. Something goes wrong—an outage, a performance issue, maybe even a regulatory problem—and the team jumps in to fix it. Since the problem usually catches them by surprise, they then have to spend time figuring out how to address the issue before they can start to fix it.

Banks in this stage tend to rely heavily on manual processes and have very little automation in place. There might be some monitoring, but it’s often not tailored to SQL Server and effectively too generic (maybe something like SolarWinds Orion). So, leaders don’t have a clear picture of what’s healthy, what’s risky, or what’s about to break.

A second indicator for this stage is an environment where no one person is truly accountable for SQL Server. It’s a shared responsibility, which really means no one’s watching it closely. It’s just one of many systems all lumped in together. In these environments, small problems slip through the cracks until they turn into something big.

A third indication is the assumption that the vendor or core provider is handling all necessary SQL Server maintenance. In reality, they’re not watching it nearly as closely as the bank thinks they are.

From a business standpoint, this leads to high operational costs, more regulatory findings, and frustrated employees and customers when things go down.

Most of the SQL-related budget at this stage goes toward putting out fires instead of preventing them. Unfortunately, this is still where a lot of community banks find themselves today—operating in a reactive state, vulnerable to risk, and always one incident away from disruption.

2. Managed: Gaining Control

The next stage up in the curve is the managed stage. In this stage banks start putting some structure in place.

Backups are running consistently. And I know what you might be thinking: ‘Of course they are.’ But you’d be surprised how often we hear that, only to find something very different once we dig in during an SQL Health Check.

Monitoring is usually turned on so the team gets alerted before things get out of hand, and patching is scheduled instead of done haphazardly.

You’ve probably heard the phrase people, processes, and technology. At this stage, banks are making solid progress on two of those: processes and technology. And there’s usually someone in IT who’s been given responsibility for SQL Server, though it’s often just one of the many things they take care of.

But the results are noticeable. Incidents are happening less often, performance is steadier, and compliance is easier to manage. There’s even some separation of duties starting to take shape.

Here, most of the SQL-related budget is still going toward maintenance, but now, instead of pure firefighting, a little bit of that time and money is shifting toward planning and improvement.

So the managed stage is a big step forward. Things are more stable, there are fewer surprises, and the environment is definitely safer. But it’s still not efficient—and it’s not yet resilient. That’s usually when the question shifts from ‘Are we stable?’ to ‘How can we do this better?’

3. Optimized: Running Proactively

Third is the optimized stage; things start to look and feel different. We’re no longer spending most of our time just keeping the lights on; the focus shifts from maintenance to efficiency.

Routine tasks like backups and testing the backups, patching, and monitoring are automated and standardized across the SQL Server environment. The team’s not reinventing the wheel on every server anymore. Builds are standardized and perhaps even automated.

Performance is managed proactively—indexes, queries, and resource usage are being reviewed on a regular basis. The bank finally has real visibility into capacity, performance trends, and risks over time.

And all that optimization pays off literally.

At this stage, banks start saving real money. They’re doing proactive performance tuning, right-sizing their environments, and consolidating where it makes sense. That means fewer servers, lower licensing costs, and less wasted hardware.

We worked with one client who was able to save about $2,000 a month—$24,000 a year—on just one of their Azure SQL Servers, simply by tuning and optimizing the setup.

And another bank we work with was able to cut their SQL footprint in half through consolidation and decommissioning efforts. That saves on licensing costs, management costs, etc.

But it’s not just about cost savings. This is also where security gets stronger. Misconfigurations get closed off, permissions are tightened, and the environment starts aligning with best practices like the CIS benchmarks and the principle of least privilege.

The payoff is easy to see. Customers experience faster, more reliable systems. Inside the bank, IT teams aren’t scrambling to fix the latest outage—they’re staying ahead of it. They identify and resolve issues before they impact operations or audits. SQL Server becomes a reliable foundation that actively supports business goals.

4. Strategic: Turning Data into Advantage

In the final stage, the strategic stage, SQL Server isn’t just stable or secure; it’s resilient by design.

High availability is built in. Disaster recovery plans aren’t just written; they’re tested and refined. Security is strong and consistent across the environment, and compliance isn’t something the team scrambles to prove once a year; it’s woven into daily operation.

Auditing and monitoring tools are in place. There’s clear separation of duties. And reporting infrastructure is mature enough to shift workloads where they make the most sense.

But what really sets this stage apart is how SQL Server starts to enable the business.

At this point, it’s not just about avoiding risk; it’s about driving strategy.

Data becomes a competitive advantage. Executives have access to real-time insights through analytics and reporting. They can spot trends, understand customer behavior, and make better decisions—faster.

And IT? It’s no longer seen as a cost center. It’s a business enabler—helping drive efficiency, innovation, and growth.

Moving Up the Curve

Wherever your institution is today, the goal isn’t perfection overnight. It’s steady progress. Moving even one stage up the maturity curve can dramatically reduce risk, improve audit readiness, and free up your team to focus on higher-value initiatives.

The key is to be intentional, to assess, document, and continually refine your SQL Server management practices.

Because in business, in banking, and in healthcare, SQL Server maturity isn’t just an IT milestone; it’s a business advantage.

Further Resources

• Curious where your environment stands today? We’ve created a short SQL Server Maturity Checklist to help you identify which stage your organization is in and where to focus next. It’s a quick, practical way to assess your current practices and start planning your path forward. Download the SQL Server Maturity Checklist to see where you stand and how to move from risk to advantage.

• For a deeper dive on this subject, you can watch our free, on-demand webinar, “Navigating the SQL Server Maturity Curve,” on YouTube.

Want to work with The SERO Group?

If your SQL Server environment feels more reactive than strategic, or if you’re ready to strengthen reliability, improve security, and become more audit-ready, we can help.

We specialize in helping institutions move up the SQL Server maturity curve with proven processes and a proactive approach. Let’s start a conversation about where you are today and where you want to be. Schedule a brief call with us today.

The post SQL Server Maturity Curve: How Banks Move from Reactive Risk to Strategic Advantage 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.