Whether you’re migrating to a new platform, upgrading legacy infrastructure, or implementing new security and compliance protocols, your SQL Server partner isn’t just a vendor—they’re a strategic collaborator.

So, what should you expect from a SQL Server partner during your next core banking upgrade?

The Best SQL Server Partners for Core Banking Upgrades Deliver:

1. Deep SQL Server Expertise and Core Banking Systems Familiarity

Core banking environments are complex. They handle everything from transaction processing and customer account management to regulatory reporting and data security. Your SQL Server partner must understand not only the technical architecture but also the core banking systems’ operating requirements.

Expect your partner to ask the right questions about your environment, your data dependencies, your peak usage times, and your business continuity and recovery needs. The best SQL Server consultants come equipped with industry experience and a blueprint for helping banks navigate change.

Core banking system providers are experts in their own software, but they’re not always expert SQL Server administrators. That’s where a specialized SQL Server consultant adds value. They ask the right infrastructure questions, including about Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs). These metrics help ensure your SQL environment supports your business continuity and disaster recovery needs. A knowledgeable SQL partner can turn those objectives into strategies like point-in-time recovery, automated failover, and high-availability design.

2. Rigorous Planning and a Clear Project Timeline

A core banking database upgrade isn’t something to approach casually. Your SQL Server partner should help you scope and sequence every phase of the upgrade, including:

• Environment assessments and baseline performance benchmarks
• Compatibility testing with the new infrastructure
• Backup and restore strategies for rollback protection
• Performance settings recommendations
• Cutover planning and go-live support

Look for partners who can produce a detailed project plan and who proactively manage timelines, milestones, and communication. You shouldn’t have to tolerate surprises—and neither should your customers.

3. Zero-Downtime (or Near-Zero) Migration Strategies

Unplanned downtime in core banking systems means customer impact, reputational risk, and possible regulatory scrutiny. SQL Server partners should be able to offer strategies that minimize or eliminate unexpected downtime through:

• High availability (HA) and disaster recovery (DR) design reviews
• Pre-migration dry runs to simulate live scenarios
• Staged cutovers during low-usage periods

Expect your partner to not only explain these strategies but also test and validate them in your environment before launch day.

4. Compliance and Security Oversight

With the FFIEC sunsetting its Cybersecurity Assessment Tool and CIS® Benchmarks™ gaining ground as the new standard, your SQL Server partner must be fluent in financial data security requirements.

They should review your SQL Server configuration for gaps, recommend security hardening, and help you prepare for both internal and external audits. This includes:

• Encrypted backups and secure storage
• Role-based access controls
• Configuration baselines aligned with best practices
• Detailed documentation for compliance reviews

5. Post-Upgrade Monitoring and Support

A good partner doesn’t just help you upgrade. They help you meet your regulator with confidence.

The job isn’t finished when the core system goes live. The first few weeks post-upgrade are critical. Your SQL Server partner should offer extended support to monitor system performance, resolve unexpected issues, and ensure optimal database operation.

Banks should expect:

• Real-time monitoring for performance and error trends
• Rapid-response troubleshooting
• Ongoing patching, maintenance, and tuning
• A smooth transition to in-house teams or ongoing DBA-as-a-Service

This post-upgrade care is what separates good partners from great ones.

Choose a Partner Who Understands Banking

A core banking upgrade isn’t just technical. You need a partner who is not only steeped in SQL Server but also understands your industry, speaks your language, and can deliver with precision. At The SERO Group, we specialize in helping financial institutions modernize their SQL Server environments while prioritizing SQL Server health, security, and reliability.

If you have an upgrade to core banking system on the horizon, let’s talk. We’ll help you plan, execute, and support your transition—every step of the way.

The post Choosing the Right SQL Server Partner for Your Core Banking Upgrade appeared first on The SERO Group.

This is true with walking. It’s true in other areas of life, too, including life as a database professional.

Good DBA teams look “up and out” and they look “down and in.” They don’t want to miss something.

But what does that mean?

Looking “down and in”

Looking “down and in” means you have to take care of the SQL Servers in your charge. Sure, SQL Servers are resilient. They are designed to be behind-the-scenes workhorses for applications and services. Microsoft has done a great job building in a high degree of robustness into the product.

But that doesn’t mean that you can or should ignore your SQL Servers. Far from it.

Because SQL Server is good at running even under less than ideal circumstances, some potential issues may go unnoticed until it’s a big problem.

For example, if some pages in a key table, perhaps even a system table, become corrupted, it may not be immediately apparent. The corruption may go undetected for days, weeks, or even months. The longer the corruption lies dormant, the more difficult the recovery process.

That’s just one example.

Proactively monitoring and alerting, automating and confirming maintenance jobs, regularly reviewing the SQL Server and agent logs, checking the Windows event logs, verifying and performing test restores on backups, routinely applying patches to test and then production systems, etc, these are the “down and in” activities that help ensure each SQL Servers is healthy, secure, reliable, and performs well.

These are the basic blocking and tackling of the DBA role. And they are critical.

Looking “up and out”

But looking “down and in” isn’t enough. Good database professionals look beyond the day to day operations of their immediate environment. They are watching for trends in the SQL estate. Is it growing rapidly and maybe even unnecessarily? Could the SQL footprint be reduced by consolidating a few servers, thus reducing the licensing costs? Or maybe, given the growth of specific application databases, we can predict that next year’s budget should include additional storage, more CPUs, or additional memory.

DBAs also continuously look for trends or changes in the business and in the industry. Can their environment support the organization’s Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs)? Should we consider using Azure or AWS as part of our Disaster Recovery planning? What does the business need? What does our industry require? Are we there?

Good data professionals assess the role that SQL Server has in the business, crafts a vision for their SQL estate, and develops a plan to close any gaps.

Sounds good, but I don’t have the time

“Up and out” and “down and in.” Both are important.

But when? It’s one thing to know what to do. It’s another to have the time and know-how to actually do it.

That’s what our SEROShield DBA Team as a Service is designed help with. We look “down and in” to keep our clients’ SQL Servers healthy, secure, reliable, and performing well. We also look “up and out,” sharing with our clients trends we see in their environment as well as what we’re seeing in the broader SQL Server space.

Want to learn more? Schedule a call or send us an email. It’s easy and there is no obligation

The post Looking “Up and Out” and “Down and In” appeared first on The SERO Group.

Here’s a short introduction video for how DiskSpd can be used to gather the necessary performance metrics without using the SQL Server Dynamic Management Views (DMVs). Having a way to support your case without using SQL Server to capture these metrics can sometimes be helpful.

Using DiskSpd on Your SQL Server System

Using Diskspd we can benchmark the raw performance of storage without relying on SQL Server DMV information at all. It’ll report on write and read latency, on sequential and random disk activity. It’s very granular and can be extremely insightful.

For example, I downloaded the utility and ran it on my laptop using the following command.

Diskspd.exe -b8K -d60 -h -L -o2 -t4 -r -w30 -c100M c:\test\io.dat > c:\test\output.txt

In this simple case, I set the block size to 8K using the -b parameter, ran the test for 60 seconds using the -d parameter, disabled hardware and software caching with the -h parameter, measured latency statistics with -L, used 2 overlapped IOs with the -o parameter, created 4 threads per target with the -t parameter, defined a workload of random input/output with the -r parameter, defined 30% of the I/O to be writes with the -w parameter, had the utility create a 100MB test file at c:\test\io.dat, and configured the output to be written to c:\test\output.txt.

There are many more parameters available in DiskSpd. For a complete list, run DiskSpd -?.

Interpreting the DiskSpd Disk I/O Performance Results

In my case, I received the following results in the c:\test\output.txt file. Keep in mind this is on a laptop and not a production SQL Server.

Command Line: Diskspd.exe -b8K -d60 -h -L -o2 -t4 -r -w30 -c100M c:\test\io.dat

Input parameters:

	timespan:   1
	-------------
	duration: 60s
	warm up time: 5s
	cool down time: 0s
	measuring latency
	random seed: 0
	path: 'c:\test\io.dat'
		think time: 0ms
		burst size: 0
		software cache disabled
		hardware write cache disabled, writethrough on
		performing mix test (read/write ratio: 70/30)
		block size: 8192
		using random I/O (alignment: 8192)
		number of outstanding I/O operations: 2
		thread stride size: 0
		threads per file: 4
		using I/O Completion Ports
		IO priority: normal

System information:

	computer name: DESKTOP-K9DJS56
	start time: 2020/10/21 14:18:01 UTC

Results for timespan 1:
*******************************************************************************

actual test time:	60.00s
thread count:		4
proc count:		4

CPU |  Usage |  User  |  Kernel |  Idle
-------------------------------------------
   0|  71.35%|  13.26%|   58.10%|  28.65%
   1|  66.28%|  15.23%|   51.04%|  33.72%
   2|  70.03%|  13.41%|   56.61%|  29.97%
   3|  68.15%|  17.73%|   50.42%|  31.85%
-------------------------------------------
avg.|  68.95%|  14.91%|   54.04%|  31.05%

Total IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      4398579712 |       536936 |      69.91 |    8948.90 |    0.222 |     0.740 | c:\test\io.dat (100MiB)
     1 |      4435599360 |       541455 |      70.50 |    9024.22 |    0.221 |     0.739 | c:\test\io.dat (100MiB)
     2 |      4433772544 |       541232 |      70.47 |    9020.50 |    0.221 |     0.757 | c:\test\io.dat (100MiB)
     3 |      4367548416 |       533148 |      69.42 |    8885.77 |    0.224 |     0.787 | c:\test\io.dat (100MiB)
-----------------------------------------------------------------------------------------------------
total:       17635500032 |      2152771 |     280.31 |   35879.40 |    0.222 |     0.756

Read IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      3077742592 |       375701 |      48.92 |    6261.66 |    0.256 |     0.669 | c:\test\io.dat (100MiB)
     1 |      3101097984 |       378552 |      49.29 |    6309.18 |    0.256 |     0.751 | c:\test\io.dat (100MiB)
     2 |      3100819456 |       378518 |      49.29 |    6308.61 |    0.254 |     0.606 | c:\test\io.dat (100MiB)
     3 |      3055476736 |       372983 |      48.57 |    6216.36 |    0.258 |     0.715 | c:\test\io.dat (100MiB)
-----------------------------------------------------------------------------------------------------
total:       12335136768 |      1505754 |     196.06 |   25095.82 |    0.256 |     0.688

Write IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      1320837120 |       161235 |      20.99 |    2687.24 |    0.144 |     0.879 | c:\test\io.dat (100MiB)
     1 |      1334501376 |       162903 |      21.21 |    2715.04 |    0.139 |     0.702 | c:\test\io.dat (100MiB)
     2 |      1332953088 |       162714 |      21.19 |    2711.89 |    0.144 |     1.023 | c:\test\io.dat (100MiB)
     3 |      1312071680 |       160165 |      20.85 |    2669.41 |    0.145 |     0.928 | c:\test\io.dat (100MiB)
-----------------------------------------------------------------------------------------------------
total:        5300363264 |       647017 |      84.25 |   10783.58 |    0.143 |     0.890



total:
  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      0.054 |      0.048 |      0.048
   25th |      0.168 |      0.082 |      0.121
   50th |      0.192 |      0.095 |      0.174
   75th |      0.228 |      0.113 |      0.211
   90th |      0.337 |      0.144 |      0.292
   95th |      0.557 |      0.203 |      0.454
   99th |      1.394 |      0.610 |      1.291
3-nines |      4.510 |     14.778 |      5.577
4-nines |     18.031 |     26.059 |     20.629
5-nines |    117.426 |    117.574 |    117.502
6-nines |    153.091 |    161.708 |    153.091
7-nines |    162.048 |    161.708 |    162.048
8-nines |    162.048 |    161.708 |    162.048
9-nines |    162.048 |    161.708 |    162.048
    max |    162.048 |    161.708 |    162.048

As you can see, DiskSpd creates quite a bit of information.

According to the results, the test consumed nearly 69% of the CPU resources. As for the latency, the last section shows the metrics broken down by percentiles. In my case, the minimum read latency was 0.054 ms and the best write latency I could achieve was 0.048 ms. The maximum latencies were read 162.048 ms and write 161.708 ms. At the 50th percentile, my system had a read latency of 0.192 ms and a write latency of 0.095 ms.

This output can help you determine whether the disk I/O subsystem is delivering the performance your SQL Server system needs.

Where to Get DiskSpd

DiskSpd is available on GitHub, and additional how-to documentation can be found on TechNet here.

For other checks to run on your SQL Server system, check out Is My SQL Server Configured Properly.

The post Identify Disk I/O Performance Issues for Your SQL Server Using DiskSpd appeared first on The SERO Group.

And the server performs well. For a while. Then it slows down and maybe even a database corrupts. You recover by restoring the prior night’s backup. You lost some data but not too much. At least, you’re running again. So, you add some memory and a couple of processors to the virtual machine in hopes that it’ll help. But you begin to wonder if your data is safe, really safe. And if it goes down, can you recover?

Unfortunately, this is a story that happens all too often.

SQL Configuration Matters

Microsoft SQL Server is a robust, well-designed database engine that performs remarkably well even when neglected. But knowing that critical information is not being actively cared for often leads to angst, especially in those who are responsible for the business.

If you have a SQL Server, you also probably have people who depend on it and the information it contains. They need SQL Server to be performant and reliable. Throwing hardware at problems can overcome a multitude of issues but at a cost – a real cost in terms of additional licenses and an emotional cost in terms of uncertainty.

The thing is: the way SQL Server is configured after it is installed can have a dramatic effect on how it performs. We’ve found that most SQL Servers are not configured with industry best practices. In fact, we find that 95% of the SQL Servers we’ve assessed depart from best practices in many areas. And that puts them at risk for poor performance or even data loss. You can download a free pdf of the most common issues we find.

So, we can you do?

Assessing Your SQL Configuration

A review of your SQL Server configuration settings is a great first step toward ensuring your SQL Server can perform well. Confirming that your SQL Servers are up to date and that the settings are consistent with industry-established best practices will give you confidence in knowing that your SQL Server has the foundation for solid execution.

There are several ways to do this.

1. Do You Own Configuration Review

Whether you have 5 or 500 SQL Servers, identify each instance in your SQL Server environment and prioritize the list based on key factors: impact on the business, frequency of issues, and complexity of setup. Review the list and begin assessing the configuration of the highest priority instances. Compare their settings to what they should be.

For example, what are their maximum and minimum memory settings? What values are configured for Maximum Degree of Parallelism and Cost Threshold for Parallelism? How many tempdb files are defined? Is the instance on the latest supported Cumulative Update? Do you have the appropriate maintenance plans defined? What about file growth settings? Etc.

Here are a few links that may help.

• Operating System Best Practice Configurations for SQL Server
• Performance guidelines for SQL Server in Azure Virtual Machines
• Recommended updates and configuration options for SQL Server 2017 and 2016 with high-performance workloads

Doing this by hand can be quite time-consuming, especially when your SQL Server landscape is broad, so automating the approach would be helpful. You can create scripts to check each value of interest. A quick internet search will provide some scripts you can use as a starting point. Brent Ozar has some free scripts; so does Glenn Berry. And there are others. Of course, be cautious with everything you get from the internet.

2. Microsoft SQL Assessment API

Microsoft has recently made assessing your SQL Server instances a bit easier with it’s free SQL Assessment API.  The API employees SQL Server Management Objects (SMO) and PowerShell to compare your SQL Server with a ruleset published in the samples repository. You and even add your own SQL Server configuration parameters to the ruleset to customize the settings as appropriate for your environment.

This API is new enough that I haven’t had a chance to explore it as much as I’d like. However, it looks promising. If you have more than a few SQL Servers to examine, I’d encourage you to see if the API is a good alternative for you.

3. Get Some Outside Help

The first two options are great for organizations that have the time and the internal skill set to evaluate what is a good configuration for their environment and what should be changed. Not all companies have this luxury.

If you don’t have both the time and the knowledge, you can look outside your organization for an external expert to review your settings and provide an unbiased assessment of your SQL Server configurations.

For example, we frequently provide SQL Assessments for our clients. For a fixed price, we examine up to three of SQL Servers and deliver a 40 to 60-page document that describes our findings. It details and prioritizes each setting and provides links to additional information. During a one-hour follow-up call, we provide specific and actionable recommendations to bring these servers into alignment with industry-established best practices.

In the end, our clients are equipped to make the changes themselves, or we assist in the remediation as needed. In either case, they can rest assured that they’ve provided the best configuration possible for their database servers.

Next Steps

Don’t wait until the next “Oh No!” moment to think about your database servers. Get the peace of mind that comes from understanding exactly how your servers are configured. Begin assessing your SQL Server soon.

Not sure where to start? We’ll be glad to help. Let’s talk.

The post Is My SQL Server Configured Properly? appeared first on The SERO Group.