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.

The holiday season is a time for reflection and connection, and we sincerely hope it brings you peace, happiness, and moments of rest. As we look ahead to 2025, we wish you continued success, health, and joy in all that you do!

Thank you for being part of our community. Here’s to a wonderful holiday season and an exciting new year ahead!

The post Cheers to a Joyful Holiday and a Bright New Year appeared first on The SERO Group.

By this point in the conversation, they’ve usually told me about a performance problem they’re struggling with. Or maybe an availability issue that’s been plaguing them. They’ve shared what they’ve done to try to remedy the situation. For example, maybe they’ve increased hardware resources, or shuffled some scheduled jobs around, trying to make things better. It hasn’t worked.

Note: I’m definitely not judging their attempts. Not in the least. If someone asked me to diagnose and solve a Linux DNS issue or debug some C# code, well, let’s just say they’d never ask me again. And things would be a lot worse after my attempt. So, I applaud their effort to fix an issue that is outside their area of expertise. Necessity is the mother of invention, or at least it’s the mother of Googling for help.

The rest of the conversation

Anyway, as the conversation continues, it goes something like this:

Me: “Ok, so who is responsible for SQL Server in your environment?”

Them: “Well, we are.”

Me: “Ok, good. Frequently we find that if a company doesn’t have a DBA on staff, either an experienced application developer or perhaps a systems administrator is the one tasked with taking care of the SQL Servers in their spare time. Do you have someone like that?”

Them: “Well…”

Me: (waiting)

Them: “Ok. So, the infrastructure team believes that SQL Server is an application. It’s loaded on top of the O/S, on top of the hypervisor, the network, the storage, etc. So, they don’t want to own it.”

Me: “Ok, I get that. SQL Server is not exactly infrastructure. So, is the App team responsible for it?”

Them: “Well. The developers say that should it live with the infrastructure group. They say ‘It’s in the name – SQL Server. Servers are part of infrastructure.’ So, no they don’t really want to be responsible for it either.”

Me: “Ok, got it. So, who keeps it healthy? Who takes care of it when something goes wrong?”

Them: “That’s why we’re talking with you.”

Where should SQL Server live?

For companies with a DBA team, the answer is easy. SQL Server lives with them. They own it. They are responsible for keeping it reliable. For keeping it secure. And for keeping it performing well.

But what about for companies that do not have a team of DBAs? Who should be responsible for them?

We’ve seen SQL live with infrastructure, where it’s treated as infrastructure. We’ve also seen it live with application developers or with the BI team. In some companies it’s the CIO who manages the SQL Server environment.

And these were not small companies. These are companies with more than $100M in annual revenue, with hundreds or even thousands of employees. Yet they didn’t need a full time DBA. They had 10, or 20, or maybe 50 SQL Server instances. They don’t have enough DBA work to justify hiring a DBA, much less a couple of DBAs. Because two is one and one is none.

And yes, that’s where we can help.

I’m curious, though. If you do not have a DBA, who is responsible for SQL Servers in your company? Who’s telephone rings when it’s slow? Who’s making sure the backups are running?

Want to know more?

Here are other posts that you may find helpful if you don’t have a DBA on staff.

• Working Without A SQL Server DBA? Do These 10 Things Now
• 4 Ways to Better Manage SQL Server Without a DBA
• Who’s Caring for Your SQL Servers?
• 10 Unseen Things Successful DBAs Do
• Why is it important to monitor SQL Server?
• Do I Still Need a SQL Server Health Check?
• The SERO Script Library

Or, if you’d like to learn a bit more about how we help companies with our a SEROShield – DBA as a Service, feel free to reach out.

The post Who Is Responsible for SQL Server? appeared first on The SERO Group.

And, we’d like your feedback on it.

How the new SQL Server Daily Health Check works

Here’s a brief overview of how it works:

1. The Daily Email. Each morning, you and our DBA team receives a Daily Health Check (DHC) email. The email provides a summary of the overall health of each SQL Server being monitored in your environment. It reviews information such as:
   • Windows Event and Application logs
   • SQL Server and SQL Server Agent logs
   • Low Disk space alerts
   • Failed logon attempts
   • Failed user-created jobs
2. The Dashboard. If you notice anything usual in the email, click the link. You’ll be taken to your SEROShield Dashboard where you can see additional information about the health, reliability, and security of your SQL Server. Information such as:
   • Performance issues
   • Security vulnerabilities
   • Reliability concerns
   • Recoverability problems
   • And more
3. Dive Deeper. The SEROShield Dashboard not only shows the most recent Health Check information, but you take a deeper dive and review the past 30 days’ worth of findings. This will help you spot trends and recognize anomalies.

Join the Focus Group

We want to build the best user-experience possible in our next version of our SQL Server Daily Health Check. And you can help.

Sign for an upcoming Focus Group and provide your insights and opinions. The next one is 11:00 CST on 30 January, 2024.

In meantime, if you are interested in learning more about how our SEROShield DBA Team as a Service helps to keep SQL Server healthy, reliable, secure, and performing well, contact us.

The post Preview Our New SQL Server Daily Health Check in an Upcoming Focus Group appeared first on The SERO Group.

According to a 2022 survey conducted by Enlyft, of all the companies using Microsoft SQL Server, 39% are small businesses with less than 50 employees and 72% have revenue of less than $50M annually.

For many of those companies, justifying a full-time Database Administrator is hard.

It can be hard even for larger companies. Companies with more than $1B in annual sales or with tens of thousands of employees can have a hard time spending money on a full-time DBA. Why? If they have fewer than a couple of dozen SQL Servers, a full-time DBA is probably not warranted. It’ll be hard to keep a good DBA busy. And if you hire one DBA, you’ll probably want to hire a second, doubling your costs for salary, HR, benefits, etc.

So, if you find yourself in this situation, working without a DBA, what can you do?

Managing SQL Server without a DBA

If you are a CIO who is responsible for managing SQL Server with a DBA in your organization, you have some options. Here are four.

1. Use a SQL Server management tool
2. Train your IT staff on SQL Server administration
3. Use a cloud-based SQL Server hosting service
4. Partner with a SQL Server consulting company

Let’s look at each of these.

1. Use a SQL Server management tool

One of the first places many companies turn when attempting to working without a DBA is to buy tools. There are a lot of great tools out there for monitoring SQL Server. Some are specific to SQL Server, such as Solarwinds’ SQLSentry and Redgate’s SQL Monitor. Others are part of broader networking monitoring tools, such as PRTG and DynaTrace.

These tools can help you to monitor your SQL Server environment, troubleshoot problems, and highlight resource contention. But the onus is on you and your team to interpret the information and to do something about it. It’s like the gauges in a car. They can tell you when something isn’t right. But it’s up to you to act. As the saying goes “knowing but not acting is the same as not knowing.”

If you decide to go this route, train your team on the use of the software. Make sure they know how to set it up, tune the alerts, and identify when something isn’t going as planned. Too often, great monitoring tools become shelf-ware because the team doesn’t know how to use it. They install it, it lights up like a Christmas tree, and they eventually uninstall it.

If you opt for this approach, you’ll also want to have an escalation plan for when something goes wrong. No one wants to rely on a team’s Googling skills while the rest of the company is idled because the key SQL Server is out of commission.

2. Train your IT staff on SQL Server administration

Microsoft has spent a fortune making SQL Server a robust, enterprise-capable database platform. SQL Server is good. It’s scalable, it’s resilient, and it’s reliable.

However, you still have to configure it appropriately for your workload. You still have to perform backups, schedule maintenance jobs, apply patches, and yes, troubleshoot performance and other issues.

If you do not have a DBA, it is important to train your IT staff on the basics of SQL Server administration. Pluralsight has a lot of good training sessions for DBAs. In fact, we provide a Pluralsight subscription for each of our DBAs to help them keep their skills current.

Your team may not need to know some of the more advanced topics like understanding the differences in Availability Groups (AGs) and Failover Cluster Instances (FCIs) – unless of course you need high availability. Still, a sound understanding of how SQL Server works, and how you can keep it healthy, reliable, and secure is good.

3. Use a cloud-based SQL Server hosting service

Another approach that some companies are looking into is getting out of the SQL Server management game altogether.

Microsoft Azure SQL Databases and Azure SQL Managed Instances can help to offload some of the traditional DBA tasks to Microsoft Azure. AWS has similar offerings.

Of course, the convenience comes with a price tab and some limitations. For example, with a SQL Server VM, you have access to everything – the operating system, the SQL Server configuration, the drive configurations, etc. With a Managed Instance, Microsoft takes care of the operating system for you. Which is good, but it also means you don’t have access to make changes there if needed. The same is true with Azure SQL Databases. You only have access to the database, not the SQL Server instance and certainly not the operating system.

Is it a good option for you? It may be.

Here’s what we’re seeing. Some companies are leveraging Azure SQL Database for new development. But, we’re not seeing a lot of migration of existing database applications to Azure SQL Databases. It’s easier to design and build for that environment from the beginning than it is to retrofit an application.

Azure Managed Instances can also be good under certain circumstances, but the use-case is pretty narrow at this point.

4. Partner with a SQL Server consulting company

A lot of companies recognize that important aspects of their business depends on SQL Server being available, performing well, and of course, being secure. So, they partner with companies like The SERO Group to provide DBA services.

Experienced DBAs work with your teams for items such as:

• Ensure the current configuration supports your RTOs and RPOs
• Develop and test disaster recovery scenarios
• Identify departures from best practices and build remediation plans
• Proactively monitor and respond to alerts
• Prevent potential issues from becoming disruptive events
• Assist with consolidation efforts to reduce the SQL footprint before a true-up

Companies like The SERO Group provide the SQL expertise, the mature DBA processes, and the tools required to manage SQL Server environments – without the compensation package and the Human Resources requirements for finding, onboarding, training, retaining, and eventually replacing a DBA.

Using a combination of these options

Of course, this is not a comprehensive list of options. There may be other options for your organization to better manage SQL Server without a DBA.

We find that many companies opt for a combination of these approaches.

Maybe they want to move some of their workload to AWS or Azure, reduce their overall SQL Server footprint with consolidation, and work with a knowledgeable DBA team that can help accomplish their objectives.

Or maybe they’ve purchased some tools, have trained their team on the basics of SQL Server administration, and would like to have access to an experienced DBA team for some of the more complex activities and troubleshooting.

We’ve worked with companies in these and other capacities.

Additional resources for managing SQL Server

Here are some other resources that may help.

• Who’s Caring for Your SQL Servers?
• SQL Server Maintenance: 10 Things to Keep Your SQL Server Running Well
• Do I Still Need a SQL Server Health Check?
• 10 Unseen Things Successful DBAs Do

Want to work with The SERO Group?

At The SERO Group, we work with companies who just don’t need a full-time DBA on staff. But they need reliable and secure SQL Servers. We do that.

If that’s something you’d like to learn more about, let’s have a conversation to see if we’re a good fit for what you’re looking for.

The post 4 Ways to Better Manage SQL Server Without a DBA appeared first on The SERO Group.

Sound familiar? Many of our new clients come to us because they are experiencing slowness in a key application.

We can help. It’s a core tenet of our SEROShield DBA Team as a Service. We assist them in getting the most out of their SQL Server investment by helping them to create a well-configured, secure, and reliable SQL Server environment that perform well.

But, there’s more to it than that.

Removing SQL Server constraints

Recently, I re-read The Goal: A Process of Ongoing Improvement by Eliyahu Goldratt. I first read the book 30 years ago as a requirement for one of my MBA classes. I forget which class, but I remember the book.

The book, written as a business fable, explores Goldratt’s Theory of Constraints. It’s set in a manufacturing facility, so a first glance it’s not evident how this could apply to our small team of DBAs delivering SQL Server services to clients. We don’t have raw materials coming, work stations refining the materials, and finished goods leaving on big trucks.

But, as I reflected on it, every business, every process, is constrained by something. The SERO Group has constraints. Our clients have constraints. So, the questions become – how to identify the constraints, what needs to be done about them, and then how to make the changes.

At first glance, it seemed that we remove constraints from our clients’ SQL Server environment, making each server faster, more reliable, and more secure.

Yes. Certainly, we help with that. I’m confident that our clients’ SQL Servers are better because of our services. In fact, they tell us so.

Removing Team Constraints

But I think there’s more to it than that. For our clients, we help remove a constraint at the team, or Human Resources, level.

Some clients cannot justify a DBA

Many of our clients cannot justify the expense of a full-time Database Administrator. But they know that an ignored SQL Server is a not a good SQL Server. So, some companies ask a developer or system administrator also take care of the SQL Server in their spare time.

When it needs patching, they patch. When it gets slow, they Google. When it stops working, they get very nervous, and often lose data.

Their business is hampered, or constrained, by not having a SQL Server DBA on staff.

Some clients could justify a DBA

Other clients do have the budget for a SQL Server DBA. They can afford to hire a mid-level DBA to join their team. But they know that having a single DBA is also having a single point of failure. It’s the “two is one and one is none” concept. What happens with that DBA goes on vacation? Or wins the lottery? Or decides that the grass is greener at another company?

And what happens when that DBA reaches the end of their knowledge? Who can they turn to for another set of eyes on the problem, or to get advice from?

We help those clients by removing Human Resources related constraints. We remove the constraint of having to budget for, recruit, interview, hire, onboard, train, manage, and eventually replace a team of experienced, senior DBAs.

We eliminate all that. And that’s no small constraint.

Want to learn more about how we serve our clients?

So, while we make our clients’ SQL Server environment better. We do more than that. We allow our clients to focus on their core mission. We support their backend SQL infrastructure so they don’t have to. And we offload the HR burdens of attracting, training, and keeping a team of DBAs on staff.

Want to learn more? It’s easy and there is no obligation. 

Contact us to get started.

The post The Goal: Removing SQL Server Constraints 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.

Letting the small stuff go

In life, the small stuff can weigh you down. Worrying about things that don’t really matter can strip you of the joy that is otherwise present.

Here’s an example from my life.

Many years ago, my then three-year-old donned her rainboots and headed out the door just as the last drop fell from the sky. She was in search of puddles. What three-year-old doesn’t like to stomp around in puddles, splashing water as high as they can, and giggling all the while?

I walked outside to see her excitement. And to probably take a picture for Instragram or FaceBook.

When I got to her, I looked down and noticed that she had put her rainboots on the wrong feet. The left boot was on her right foot and vice versa.

That’s wrong.

Being a good dad, I wanted to help her learn something important. Right boot, right foot. Left boot, left foot.

So, I called to her. “Lydia, your boots are on the wrong feet. Come here and we’ll fix that for you.”

She looked at me, glanced down to her feet, and then back to me and said “Daddy, daddy, daddy. It’s ok.”

And she was right.

It was ok.

It was small stuff that didn’t really matter in the moment.

In some things, like when a three-year-old is having fun splashing in puddles, the small details don’t matter. They get in the way.

The “small stuff” in SQL Server

We want our SQL Servers to work. And we want them to be fast enough to not be a drag for our users. And that’s usually good enough. After all, there are other things to tend to. Right?

We know that we should verify the backups. We know that we should do test restores of key databases. And those patches? They really should be applied. We know that.

We also know that we should regularly check our SQL Servers’ health. (Daily is ideal, but who has time for that!) And Disaster Recovery? Well, so far so good. Maybe next year?

And so it goes.

We can tell ourselves that those are the “small things,” that it’s not important in the moment because, well, the SQL Server is fine. At least in the moment.

But the small stuff isn’t small, it’s important

When SQL Servers aren’t an issue, they often get ignored.

Patching. Performance tuning. Index maintenance. Monitoring. Upgrades. Planning and testing Disaster Recovery scenarios. Root cause analysis when something odd happens.

These are not “small things.”

These are the things that keep SQL Server, and your business, going.

If SQL Server is unhappy, lots of people are unhappy. Users are unhappy. Execs are unhappy. Patients, nurses, project managers, supervisors, customers, investors, and all the other stakeholders are unhappy.

With SQL Server, the “small things” are not really small things. They are the things that keep your SQL Servers up and running. They are the things that keep your users happy.

Sweat the small stuff.

Where to start with the SQL Server “small stuff”

Not sure where to start? Here are a few links that will help you get started.

• Working Without A SQL Server DBA? Do These 10 Things Now
• Is My SQL Server Configured Properly?
• Where to Start with Disaster Recovery in SQL Server
• What SQL Server Version Am I Running?
• Is There an Update for My SQL Server?
• Should I Upgrade SQL Servers that Are Out of Support?

Check out our Script Library, too.

Want to work with The SERO Group?

This is what we do. We take care of SQL Servers so you, and your team, can focus on the big, important things. The things that only you can do.

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

The post Don’t Sweat the Small Stuff, Except with SQL Server appeared first on The SERO Group.

It’s like what Harvard Business School Professor Theodore Levitt said about marketing: “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!” In the world of databases, stakeholders don’t care about SQL backups. They care about the ability to restore a SQL database.

Testing your SQL Server backups

How do you know if your SQL Server backups are good? We recommend three levels of testing.

1. Checking your SQL backup jobs
2. Verifying the backup file
3. Proving your backups with a test restore.

Checking your database backup job

The ability to restore a database starts with having a good backup. We prefer native backups and in our minds, there’s no better way to manage your native backups than using Ola Hallegren’s Award winning scripts. It’s our tool of choice when it comes to SQL backups. (Note: when/if you run a SQL Server backup manually, you can use this script to see how much longer the backup will take.)

Schedule full, differential, and transaction log backups to occur regularly. Then make sure that they actually run and complete successfully.

Job failure notifications are good, and you should set those up, but it’s reassuring to actually see for yourself that the jobs complete successfully. The absence of a failure notification doesn’t automatically mean success. It’s better to check. For our customers, we look at the SQL Server Agent job histories daily.

You can use SQL Server Management Studio or Azure Data Studio to look at job histories. Of course, scripting it out is faster and more detailed. You can use the following script as starting point for your own query to check job history. This query looks for all failed jobs within the past week.

USE msdb;
GO

SELECT j.name AS Job_Name,
    h.step_name AS Step_Name,
    CONVERT(CHAR(10), CAST(STR(h.run_date, 8, 0) AS DATETIME), 111) AS RunDate,
    STUFF(STUFF(RIGHT('000000'+CAST(h.run_time AS VARCHAR(6)), 6), 5, 0, ':'), 3, 0, ':') AS Run_Time,
    h.run_duration AS Step_Duration_In_Seconds,
    CASE h.run_status
		 WHEN 0 THEN 'Failed'
		 WHEN 1 THEN 'Succeeded'
		 WHEN 2 THEN 'Retrying'
		 WHEN 3 THEN 'Canceled'
		 WHEN 4 THEN 'In-progress'
	  END AS Execution_Status,
    h.message AS [Message]
FROM sysjobhistory AS h
    JOIN sysjobs AS j ON j.job_id = h.job_id
WHERE CAST(STR(h.run_date, 8, 0) AS DATETIME) > DATEADD(ww, -1, GETDATE())
    AND h.step_name = '(Job outcome)'
    AND h.run_status != 1
ORDER BY j.name ASC,
	    h.run_date DESC,
	    h.run_time DESC;

In this example, the database backup job failed recently.

Another script we frequently use to look for backup job failures is:

USE MSDB;

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

Verifying your database backup file

Your weekly, daily, and sub-daily backups are scheduled and running like clockwork. You’re checking to make sure that they are actually completing successfully. But, what if the SQL backup file is bad or incomplete? What if a file was corrupted while being written to disk? The job completed successfully, but you don’t have a valid backup file to restore from.

To help with this, you should verify your SQL backup files regularly. Use the RESTORE VERIFYONLY TSQL command to check the completeness of the backup file, as well as to make sure the entire file is readable by SQL Server.

In the following example, we’re verifying that the BaseballData.bak file is valid.

RESTORE VERIFYONLY FROM DISK='/var/opt/mssql/backup/BaseballData.bak'

If it verifies successfully, you’ll see a message similar to the following.

RESTORE VERIFYONLY helps provide confidence that the backup files are usable without having to actually restore the database. We recommend running a RESTORE VERIFYONLY regularly, at least monthly on select SQL backup files.

Testing your database backup

Once you’ve have confidence that SQL backups are occurring, and that the backup files are well-formed and complete. There is still one more check that should be done periodically. To have complete confidence you can restore when needed, it’s good to actually go through the restore process.

It’s like a grade school fire drill. You can talk to students about what to do during a fire, showing them exit plans and rallying points, but until you walk through the process, it’s all theoretical. And, in an emergency, you don’t want to work from theory; you want to have practiced.

Take a SQL backup file and restore it another SQL Server instance. Apply differential backup files and transaction log files. Document the steps if you haven’t already. Creating scripts that automate it the process is a good idea, as well. In the following script, I’m restoring a copy of the BaseballData database to another instance.

RESTORE DATABASE BaseballData_restored  
   FROM DISK = '/var/opt/mssql/backup/BaseballData.bak' 
   WITH RECOVERY,  
   MOVE 'Baseball' TO '/var/opt/mssql/data/Baseball_restored.mdf',   
   MOVE 'Baseball_log' TO '/var/opt/mssql/data/Baseball_restored.ldf';  

Once you’ve restored the SQL backup, test the integrity of the database by running DBCC CHECKDB, checking the output for errors. Also see: When Was the Last Known Good DBCC CHECKDB Integrity Check?

DBCC CHECKDB (BaseballData_restored);

For our DBA as a Service customers, we recommend going through this exercise quarterly.

How often should you test SQL Server backup files?

Each environment is different and has it’s own setup of unique requirements. So there isn’t a one-size-fits-all answer here. We generally recommend the following as a good starting point and then adjusting as needed.

1. Checking your SQL backup jobs. Do this daily. Without a backup file, you cannot restore. Don’t rely exclusively on job failure notifications. Make sure the backup jobs completed successfully.
2. Verifying the backup file. Spot check a few key backup files at least monthly to ensure that the files are well-formed and complete.
3. Proving your backups with a test restore. Depending on your systems and the storage requirements, performing a test restore and running an integrity check against the restored database every three or four months is worthwhile exercise.

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

The post How Often Should I Test My SQL Server Backups? appeared first on The SERO Group.

That’s a question most every CFO, CIO, VP, and Director with a SQL Server environment and budgetary responsibilities has asked.

The reason is obvious. SQL Server Enterprise Edition is expensive. How expensive? According to Microsoft’s web site, the price for SQL Server 2019 Enterprise Edition is currently $13,748 for a 2-core pack, whereas the Standard Edition is $3,586.

Oh, but there are discounts, you say. There may be, but even so, Enterprise Edition is not inexpensive, especially if your workload requires 16, 32, 64, or more cores, and you have a multitude of instances.

What makes Enterprise Edition so much more expensive? Let’s compare.

What’s the difference in SQL Server Standard and Enterprise Editions?

Generally speaking, Microsoft designed SQL Server Standard Edition to meet the needs of many, if not most, small and medium-sized organizations. It has many of the same features and capabilities found in the more expensive counterpart. Both can handle heavy workloads, provide a secure data infrastructure, and offer a broad swath of data-related components.

But there some notable differences in the feature sets of each edition.

For example, both editions have HADR options such as Always On failover cluster instances (FCIs), accelerated database recovery, log shipping, and backup compression. But only the Enterprise Edition provides Always On availability groups (AGs), online index creation and rebuilds, and the ability to hot add memory and CPU. These features may be a luxury in some environments and a non-negotiable, must-have in other organizations.

Another example of feature discrepancy in the editions may be found in the reporting capabilities. SQL Server Reporting Services is available in both editions, however if you want to use Data-Driven subscriptions or a scale-out deployment, you’ll need Enterprise Edition. Standard Edition simply doesn’t have those capabilities.

One final noteworthy example is the ability to scale. SQL Server 2019 Enterprise Edition is only constrained by the operating system. Enterprise Edition can use as much CPU and memory as the operating system can handle. That’s not the case for Standard Edition. It’s CPU usage is limited to the lesser of 4 sockets or 24-cores. And, the database engine can only use a maximum of 128 GB in Standard Edition.

Here’s a list of the other scale differences between the two editions.

Reducing your licensing costs

So, given the high price tag of Enterprise Edition, it’s far better to use Standard Edition if you can. Our customers typically look to three areas for reducing their licensing spend.

Avoid using Enterprise Edition features

This is the obvious answer, right? If you can get away from using features that require Enterprise Edition, then you may be able to go with Standard Edition. For example, perhaps you can leverage Failover Clustered Instances as part of your HADR strategy rather than implementing Availability Groups. (For more information, see High Availability and Disaster Recovery in SQL Server and How to Create SQL Server 2019 Failover Clustered Instances in Azure.)

We’ve also seen some organizations migrate to a PowerBI reporting environment and phase our their use of Data-driven Subscriptions in SSRS. It’s not necessarily an easy lift, but it’s certainly doable and may be cost effective.

Of course, not everything is that well defined. Standard Edition’s resource constraints may require some getting used to by your users. Maintenance windows may be required to keep your indexes in order. Restarts may be required when adjusting resources. If these requirements are acceptable, SQL Server Standard Edition may be sufficient for you.

Consolidate your Enterprise instances

Another approach for reducing your licensing spend is to reduce the number of Enterprise Editions in your environment. If you currently have six Enterprise Edition instances each with 16 cores, maybe you can consolidate down to three 24-core Enterprise instances? Or even two 32-core instance and an 8-core instance.

There are a lot of factors involved in a consolidation project. Which databases will play nicely with the others? Which vendors have access and/or other requirements that make it difficult to have a shared instance?

You should also consider how you’re using AGs in your environment. If secondary replicas are used for any production activity, even as mundane running backups, they must be licensed as production. If the secondary replicas are simply waiting for the primary to fail so they can get into the game, then typically they do not have to be licensed. NOTE: licensing is complex and can change. Please consult a licensing expert before making final decisions.

Optimize your configuration and applications

Throwing hardware at a problem is not uncommon. With the stroke of a pen, we can add CPU or memory to relieve unpleasant SQL symptoms. Users are complaining of slowness? Add memory. That didn’t work? Add CPU or faster storage. That worked? Good enough.

Adding resources can cover a multitude of sins. But at some point, all those additional resources add up.

Perhaps you can reduce your need for Enterprise Edition’s resources by optimizing what you have. Assess your SQL Servers to see if they are configured properly and in accordance with best practices. Review the query plans and tune the most egregious resource hogs. Investigate to ensure you have the right indexing strategy in place. Check your tempdb to ensure its configured optimally. Like some help assessing your SQL Servers? We can help.

By the way, this approach is also good for Standard Edition, especially when the applications are in the cloud.

So, do you really need SQL Server Enterprise Edition?

Is the Enterprise Edition worth all that extra money? Perhaps.

Can you satisfy your objectives with Standard? Again maybe. If you can, that’s definitely the way to go. There’s no point in spending the money on licensing when you don’t have to.

It all really depends on your needs and if you can effectively reduce your spend while maintaining the level of performance and reliability your users require.

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

The post Do I Really Need SQL Server Enterprise Edition? appeared first on The SERO Group.