What is Accelerated Database Recovery?

Accelerated Database Recovery (ADR) came out in SQL Server 2019 and is an enhanced way for SQL Server to do database crash recovery. It uses a new Streaming Log (SLOG) feature that allows much faster redo and undo phases of the process by tracking any non-versioned actions.

The Persistent Version Store is another new component to the process. It holds row versions in the database itself, either on the data pages being modified or in a separate system table. This persisted version store is very similar to how read committed snapshot isolation uses row-versions to allow for read and write queries to operate without blocking each other. This holding mechanism for row versions is cleaned up periodically by a background process that removes unneeded row versions. This persisted version store, in combination with the SLOG, allows a couple of things.

First, in the redo phase there is no longer the need to read the transaction log serially from the oldest uncommitted transaction forward to the time of the crash to replay and redo records for creating a consistent state in the database. Instead, SQL Server uses the SLOG to recover any non-versioned actions from the oldest uncommitted transaction forward up to the point of the last checkpoint. This is much faster. Once the last checkpoint is reached, only then will SQL Server start reading the transaction log for any redo work.

Second, in the Undo phase, the SLOG is used again to undo any non-versioned operations, and the persistent version store is used to simply switch the database rows back to whatever the proper current row was at the time of the crash.

Traditional Recovery: Picture from https://learn.microsoft.com/en-us/sql/relational-databases/accelerated-database-recovery-concepts?view=sql-server-ver17

Recovery using Accelerated Database Recovery: Picture from https://learn.microsoft.com/en-us/sql/relational-databases/accelerated-database-recovery-concepts?view=sql-server-ver17

Why would you want to enable Accelerated Database Recovery?

Accelerated database recovery can save you and your clients from extended outages due to long rollback times under heavy load. I’ve seen rollback times of 45-60 minutes be reduced to seconds with this feature enabled. The use-case I had was during SQL Server patching clients weren’t always out of the system as requested. In some cases, the client activity had a lot of changes in-flight when patching was applied and the traditional recovery method took a very long time after the server rebooted.

I enabled ADR and never had that problem again. This feature can also save you from pain you inflict on yourself. If you’re running a query to make a lot of changes and it is decided to kill the query, causing rollback, then the ADR feature can execute rollback almost instantaneously. This is much better than waiting a long time for single threaded rollback of a query that has been running a long time.

How to determine if Accelerated Database Recovery is enabled?

The system table sys.databases can be queried to show whether this feature is enabled or not.

SELECT name
FROM sys.databases 
WHERE is_accelerated_database_recovery_on = 1;

How to enable Accelerated Database Recovery?

An exclusive database lock is required to enable Accelerated Database Recovery. This means the change should be done in a maintenance window where no activity is expected. The feature can be enabled in the presence of other activity using the termination clause WITH ROLLBACK [IMMMEDIATE | AFTER {Number} SECONDS | NO_WAIT] . Using the  IMMEDIATE option will immediately rollback other transactions so that the ALTER statement will complete. The NO_WAIT option will terminate the ALTER statement if it can’t be executed immediately. Choose one of the three options.

ALTER DATABASE [<db_name>] SET ACCELERATED_DATABASE_RECOVERY = ON WITH ROLLBACK [IMMMEDIATE | AFTER {Number} SECONDS | NO_WAIT;

What sp_configure settings should be adjusted for Accelerated Database Recovery?

First, the ADR Cleaner Thread Count option in sp_configure controls the number of cpu threads to use for the background cleaner process that removes old row versions from the Persisted Version Store. This option was introduced in SQL Server 2022. It is advisable not to set this to a large number. You can increase it from the default of 1 to 2 or perhaps 4 to ensure that Persisted Version Store cleanup is happening quickly enough across a large number of databases.

-- Configure ADR cleaner to use 4 threads
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'ADR Cleaner Thread Count', 4;
RECONFIGURE WITH OVERRIDE;

Second, the ADR Pre-allocation Factor setting can also be adjusted. If the “just in time” mechanism to allocate pages to store rows in the persisted version store is above zero by a significant amount, then this sp_configure option can be set to allocate pages ahead of time for the version store. There is an extended event called tx_version_optimized_insert_stats that can be reviewed to see what the “just in time” value is. The value to check is labeled “foreground_allocation_percent.”

The default value for the ADR pre-allocation factor is 4. The number of pages allocated at any one time is 512 X the ADR Pre-allocation Factor. It isn’t recommended to set this fact too high because pre-allocating too many pages can cause contention.

-- Configure ADR Preallocation Factor
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'ADR Preallocation Factor', 6; -- Defaults vary based on workload
RECONFIGURE WITH OVERRIDE;

Is a Long Rollback Costing You Downtime?

SQL Server recovery issues can turn a routine maintenance window into a multi-hour outage. The SERO Group specializes in exactly this kind of proactive SQL Server management. Schedule a free discovery call and let’s talk about your environment.

The post An Overview of Accelerated Database Recovery appeared first on The SERO Group.

• A runaway transaction filling up a log file or even an mdf file in a user database or tempdb.
• Someone or some process took an extra backup that wasn’t planned for.
• A new database was created with larger than expected files sizes.
• An application is using the Volume Shadow Service to make backups of databases to a local volume.

This last scenario related to volume shadow service is what I want to talk about today. This one can be a little confusing at first because your organization may get a low disk space alert that doesn’t seem to make sense. The alert may indicate that there is less than 10% free space, but looking at the volume in Windows Explorer doesn’t show that at all. It turns out that VSS files aren’t visible to Windows explorer. You might come across this when investigating the following error, “Volsnap – 36 – The shadow copies of volume E: were aborted because the shadow copy storage could not grow due to a user imposed limit.”

To investigate what is happening, try some of the VSSAdmin commands, like this:

vssadmin list shadowstorage

The output pf this PowerShell command will show what volumes are being backed up by VSS, and what the target volume is for those VSS files. If the volumes are already low on space, deleting some of the shadow copies may be the first thing needed. This can be done with the following command:

vssadmin delete shadows /for=<ForVolumeSpec> [/oldest | /all | /shadow=<ShadowID>] [/quiet]

Then a limit can be placed on the amount of storage allocated to VSS files using this command:

vssadmin resize shadowstorage /for=<ForVolumeSpec> /on=<OnVolumeSpec> [/maxsize=<MaxSizeSpec>]

Keep in mind that someone will need to determine first if the older VSS files are needed prior to executing the delete and resize commands.

Tired of Chasing SQL Server Alerts?

Dealing with disk space issues on your SQL Servers? That’s exactly the kind of problem The SERO Group solves every day. Schedule a free discovery call and let’s take a look.

The post How to Use VSSADMIN Commands To Manage Low Disk Space 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.

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.