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.

Event details: GBA Operations and Technology Conference

February 26-28, 2025
The DeSoto, Savannah, GA
Want to register? Sign up here.

What You’ll Learn at the Conference

The GBA Operations and Technology Conference isn’t just about networking—it’s a valuable opportunity to gain insights into the latest trends shaping banking technology. With sessions covering cybersecurity best practices, fintech partnerships, vendor risk management, and payments innovation, attendees will walk away with actionable strategies to improve operational efficiency and security.

For financial institutions managing mission-critical data in SQL Server, staying ahead of these trends is crucial. As technology evolves and regulations tighten, banks must ensure their database environments are secure, compliant, and optimized for performance. That’s where The SERO Group comes in—we’ll be there to discuss best practices, answer your questions, and provide expert guidance tailored to your institution’s needs.

Would you like a dedicated time to chat with our team at the event? Contact us today to schedule a quick meeting!

Why visit our booth?

Stop by our booth to enter our raffle, grab a free gift, or chat about how The SERO Group can support your banking technology needs. We help financial institutions keep their SQL Server environments secure, reliable, and efficient—whether you’re tackling security, compliance, or performance challenges.

Can’t make it to the event? Connect with us for a call.

If you won’t be at the event, we’d still love to connect! Schedule a free, no-obligation discovery call to see how we can support your organization in 2025.

The post Visit Us at the Georgia Bankers Association Operations and Technology Conference! appeared first on The SERO Group.

I’ve suffered a great many catastrophes in my life. Most of them never happened. -Mark Twain

Mark Twain’s quip may have been an admonition against excessive worrying, but it also speaks to the benefits of preparedness. When you’re prepared, you’re in the best possible position if catastrophe does strike. You’ll also lower your stress levels on all of those days when there isn’t a disaster—a win-win situation.

So, what do we need to do to prepare and protect our SQL Server from disaster?

What are disaster recovery and security maintenance?

Disaster recovery and security maintenance include regular tasks that help to protect your SQL Server from data loss and unauthorized access. These activities can and should include backing up your databases, testing your backups, monitoring for anomalies, and conducting regular security audits.

1. Regular backups and recovery testing

Backups are table stakes disaster recovery. They ensure your organization can recover data in the event of a disaster. Maybe it’s from a hardware failure. Perhaps it’s from a cyberattack. Unfortunately, user error is the cause of many data disasters. This is where backups that meet your Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs) come into play.

But backing up data isn’t enough—you need to document and regularly test your recovery process to confirm that backups work as expected. Without this testing, even the best backup strategies can fall short when you need them most.

An untested backup is only the hope of recovery. Unfortunately, hope is not a strategy.

2. Security audits and vulnerability scans

Cyberattacks are a growing threat, so regular security audits are an essential tool to prevent unauthorized access and data breaches.

Security audits identify weaknesses in your SQL Server environment, allowing the vulnerabilities to be remediated before they are exploited.

Conducting vulnerability assessments, such as the CIS Benchmark Assessment for SQL Server, and updating your security policies can help strengthen your security posture and protect sensitive data. If you’re not familiar with the CIS Benchmarks, we can work with you to assess your environment and identify any security gaps in your SQL estate.

3. Monitoring and auditing for anomalies

Who has access to your SQL Server? Who has elevated permissions? When were they granted those permissions? And by whom? You’re going to want to know the answer to these questions.

So, keeping a close eye on your SQL Server environment is essential. Monitoring and auditing tools allow you to track unusual behavior, such as spikes in access attempts or unexpected changes in database structure. SQL Server has a built-in feature called SQL Audit that can help.

Catching these red flags early can help you address potential security breaches before they become full-blown incidents.

4. Data encryption and access controls

If you have sensitive data such as Personally Identifiable Information, Personal Health Information, or financial information, you should consider encrypting your data and backups.

Data encryption prevents unauthorized users from reading sensitive information, even if they gain access to it. Check out SQL Server Transparent Data Encryption to learn more.

In summary

Disaster recovery and security are essential practices for Microsoft SQL Server. For sectors like healthcare and banking, where data security and recoverability are non-negotiable, investing in these measures is a critical safeguard.

Download a SQL Server Security Self-Assessment

Securing your SQL Server is important, but knowing where to start that process can be the biggest challenge. So, we created our free SQL Server Security Self-Assessment to help you begin the process of identifying potential gaps in your security posture.

Consider a SQL Health Check or CIS Benchmark Assessment

If you’d like to know more about how The SERO Group can help assess your SQL Server estate with a SQL Health Check or a CIS Benchmark Assessment, schedule a no-obligation discovery call with us.

Looking for more information?

Here are a few links that will help.

• SQL Server Security Best Practices
• Protecting Your SQL Server from Ransomware
• Securing Your SQL Servers, What Should You Audit?
• SQL Server security best practices – Microsoft

The post SQL Server Disaster Recovery: Four Essential Security Measures appeared first on The SERO Group.

It might seem that way, but the risks will only grow while you wait.

So, why do so many businesses delay making essential improvements to their SQL Servers?

Roadblocks to creating a better SQL environment (and how to navigate them)

Budget is frequently an issue. However, there are likely other factors compounding that barrier. Let’s look at some common reasons companies choose to delay making changes that would help to create a more stable and secure SQL Server environment.

1. “That’s part of a future project.”
2. “We don’t know where to start.”
3. “We don’t know what we don’t know.”
4. “We just can’t.”
5. “We’re not sure who owns those.”

“That’s part of a future project.”

Sometimes companies will postpone tackling an issue with their SQL Server environment because it gets lumped into a much larger project.

For example, a company may recognize the need to regularly test their SQL Server backups. It’s important, and they know that. After all, an untested SQL Server backup file and process is only a hope that they can restore. (See How Often Should I Test My SQL Server Backups? for some background here.)

Creating a process to regularly test SQL Server backups may still be deferred because “that will be part of the Disaster Recovery initiative.” However, if that DR initiative isn’t budgeted and doesn’t have a start date, that means delaying improvements indefinitely.

So, what can you do?

Start small. Take baby steps that lead you in the right direction. Often those baby steps will contribute to the larger project anyway.

In our backup example, check the status of your backup jobs every day. Schedule a job or another process to verify the backup files. Create reminders to periodically restore a key database to another server and run an integrity check on it.

Is this a perfect solution? No. But it’s far better than ignoring the gap until the larger project is funded.

“We don’t know where to start.”

Sometimes, the hardest part is knowing where to start. Even worse, not knowing where to start can make getting started seemingly insurmountable.

For example, let’s say a company has 15 SQL Server instances and they’d like to get that down to 8 or 10 through a consolidation project. But before they begin, they have questions.

• Which application databases can be moved to another SQL Server?
• Which ones will play nicely together, and which will compete for limited resources?
• Are there security considerations that require some applications to remain separate?
• Will we have to add resources to the target instances?
• And what haven’t we thought about that we should?

Those unknowns can seem overwhelming, especially if you don’t know how to go about finding the answers.

So, what can you do?

Start small, build momentum, and keep your eye on the end-goal while making incremental progress.

In our SQL Server Consolidation Project example, can you build a high-level project plan with only the most basic steps? Then you can drill down into the details, step by step.

For example, the first step is to get a list of all of the SQL Servers that may be candidates for the consolidation project. Then, determine what applications use these SQL Servers. Then, identify the applications’ requirements, and so on.

We know projects like this can become dauntingly complex if you’re not used to doing them. As with most anything, breaking things down into smaller, more manageable steps will help.

“We don’t know what we don’t know.”

This one is common and can take many forms. As an example, let’s say IT wants to decommission a SQL Server, but they’re unsure whether it’s being used. It’s got a dozen databases on it, but some are from older applications that may not be used anymore. Maybe the guy who created the database isn’t even with the company anymore.

Another example: IT would like to do a side-by-side upgrade of a SQL Server. They know there are a lot of data pipelines that rely on that SQL Server. However, do they know how many pipelines? Who owns them? Will they have to be redeployed? Are there any other aspects they’ve overlooked?

What should be a relatively simple request can become a larger issue. It can seem safer not to upset the apple cart when there are so many unknowns at play.

So, what can you do?

Having a long list of open questions with no clear path to find the answers can feel paralyzing. To find your way forward, focus on your goal and your reasons for wanting it. In the upgrade example, your goal is to upgrade your SQL Server. Why? Using an older, unsupported SQL Server version could cause serious issues; an upgrade would improve security, compliance, and supportability, which means you’re less likely to encounter problems.

Once you’re clear on your motivation, determine how you can begin to answer the first unknown. Then the next one. Then the one after that. Incremental progress will help you grow in confidence about your ability to improve the environment in addition to answering those unknowns.

“We just can’t.”

Sometimes limitations are self-imposed. Other times, limitations are implicitly imposed by stakeholders, even if they don’t have the authority to make the call outright.

This can happen with patching. As an example, vocal and influential stakeholders may insist that a SQL Server cannot go down for maintenance, period. IT may accept that limitation rather than fight it. As a result, things may progress until neither the SQL Server nor the Operating System have been patched in over two years. Not good!

So, what can you do?

This one can become overly politicized or personalized. Look for and emphasize common ground.

In the patching example, the common ground may be that everyone wants the SQL Server to be available and secure. From there, you can communicate how patching will help achieve that common goal. Planned downtime is always better than unplanned downtime, and reminding stakeholders of that can help put things in perspective.

Sometimes, IT has a reputation for implementing technology for technology’s sake, regardless of what’s in the best interest of the business or its stakeholders. Keep that in mind. Present your points so that the other party can see how they’ll benefit.

“We’re not sure who owns those.”

Sometimes there’s no clear owner of your SQL Servers. No one wants to make decisions about them, even if it helps to create better SQL environment. This can happen after an acquisition, during a re-org, or when responsibilities are not clearly spelled out.

For example, IT may become aware of some new SQL Servers. However, the team isn’t sure if those instances fall within their purview or the responsibility of another team or department. Spoiler alert: if something happens to one of the SQL Servers or its databases, IT almost always ends up having to fix it.

So, what can you do?

Uncertainty in areas of responsibility can lead to big problems. Get clear on who is responsible for SQL Servers (and any other assets) as soon as possible. Otherwise, those SQL Servers will become increasingly vulnerable to breaches or data loss.

Moving forward to create a better SQL Server environment

I’m sure this list of roadblocks isn’t comprehensive. There are likely other reasons companies don’t improve their SQL environment. Many of them may even be good and valid reasons.

However, in cases where creating a better SQL environment would be in everyone’s interest, don’t let the perfect be the enemy of the good. Look for ways to make incremental progress, however small, toward a more reliable and more secure SQL environment that performs.

If you’re not sure where to start, we can help. Helping clients overcome barriers to create better SQL environments is what we do for a living. Schedule a call to see if working with our team of DBAs makes sense for you.

The post “We Want a Better SQL Environment, Just Not Yet.” appeared first on The SERO Group.

Minimum server memory

The minimum server memory setting in SQL Server determines the smallest amount of RAM that SQL Server will grab. SQL Server will always have at least this much memory available to use, even when the system is under heavy load. The default setting for minimum server memory is usually very low, and SQL Server dynamically adjusts its memory usage based on its workload.

Maximum server memory

The maximum server memory setting in SQL Server limits how much of your computer’s memory SQL Server can access. By default, SQL Server grabs as much memory as possible, which can lead to problems. If SQL Server takes up all the available RAM, it slows down other programs running on the same server (such as SSIS, SSRS, or SSAS), making everything feel sluggish.

Configuring minimum server memory

Configuring minimum server memory is usually easy because, in most cases, it’s best to leave it set to the default. Sometimes people will set the minimum and maximum server memory settings to the same value to “lock in” the memory. I’ve seen this in virtualized environments as an attempt to prevent the hypervisor from “ballooning” and taking away the resources that are supposed to be allocated to SQL Server. The risk with this type of configuration is that during a restart, SQL Server will not come online until it has claimed all of the RAM listed in the minimum server memory setting.

You can configure your server’s minimum server memory setting in SQL Server Management Studio. Find the server properties section, then look for the minimum server memory option.

You can also make this change by running the following script:

sp_configure 'min server memory', <desired memory amount (mb)>;
GO

Configuring maximum server memory

The default maximum server memory setting can sometimes cause performance issues. By limiting the RAM SQL Server uses, you can ensure there’s enough memory for the operating system and other applications to run smoothly.

Honing in on the exact number can be tricky, as it depends greatly on the load your SQL Server is under, as well as any other applications that may be running on it. However, configuring the maximum server memory appropriately ensures SQL Server has enough memory to perform efficiently without starving the operating system or other applications of the resources they need. This balance helps maintain system stability and performance.

For example, if you have SSAS installed on the SQL Server, by default it will claim 20% of the RAM on the server, leaving only 80% available for SQL. I’ve seen scenarios where SQL Server crashed with an “insufficient system memory” error every time it tried to go above 80% RAM usage because SSAS refused to release its 20%.

To configure maximum server memory, start by following the same steps as you did above. You can configure your server’s minimum server memory setting in SQL Server Management Studio. Find the server properties section, then look for the maximum server memory option.

You can also make this change by running the following script:

sp_configure 'max server memory', <desired memory amount (mb)>;
GO

Final thoughts and next steps

Although SQL Server will manage its memory dynamically right out of the box, its default settings may not suit every scenario. Fine-tuning minimum and maximum memory settings means efficient server performance without depriving the operating system and other applications of resources. Careful memory configuration can help you achieve an optimized and balanced server environment.

Further reading

• How Much Memory is “Normal” for SQL Servers? – Brent Ozar
• Memory management architecture guide – Microsoft Learn

Previously in this series

• SQL Server Settings: MAXDOP
• SQL Server Settings: Optimize For Ad-hoc Workloads

Work with us

Want help optimizing your SQL Servers? Schedule a free call with us to learn more and get started!

The post SQL Server Settings: Memory Configuration appeared first on The SERO Group.

RTO and RPO considerations webinar

Many companies take virtual machine snapshots. They snapshot their web servers and their file servers. They snapshot before software patching, before server upgrades, and before other configuration changes.

And with good reason. Snapshotting can be a great way to ensure you can recover the VM if something goes wrong.

What about SQL Server? Should you use VM snapshots to backup SQL Server? Are there RTO and RPO considerations of using snapshots instead of other approaches to backups?

In an upcoming webinar, we’ll discuss using VM snapshots as part of your backup strategy. We’ll pose eight important questions you should ask before adopting the snapshot approach.

Here’s what we’ll cover:

• Why backup?
• RPOs and RTOs
• 8 questions to ask
• Best practices
• Frequently Asked Questions

Who should attend:

This webinar will provide a discussion for those responsible for setting backup and recovery policies. It will benefit those who work with key stakeholders to understand the organization’s Recovery Point Objectives, and Recovery Time Objectives.

Want to attend?

The webinar is Wednesday, February 28 at 11:00 AM – 12:30 PM CDT. That’s 18:00 UTC.

To register, visit the Eventbrite page, or complete the embedded version below.

Have some specific questions?

Backups are good. But it’s the ability to restore that is important. How confident are you that you can restore a critical database? Are you sure that your backup strategy meets your RTO’s and RPO’s?

Here are some posts that may help.

• Where to Start with Disaster Recovery in SQL Server
• High Availability and Disaster Recovery in SQL Server
• What is a SQL Server Recovery Model?
• Script: How Long Until My SQL Server Backup/Restore Completes?
• How to Test SQL Server Backups Using dbatools
• How Often Should I Test My SQL Server Backups?

We help a lot of companies configure their SQL Server environment so that when a disaster strikes, they’ll be prepared. Want to learn more? Schedule a call and let’s talk.

The post Should I Use VM Snapshots to Backup SQL Server? A Webinar 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.

RTO and RPO considerations webinar

In an upcoming webinar and in-person session for the Middle Tennessee Chapter of ISACA, we’ll discuss discuss using VM snapshots as part of your backup strategy. We’ll pose eight important questions you should ask before adopting the snapshot approach.

Here’s the agenda:

How to attend?

The webinar is Tuesday, April 11, 2023, 11:00 AM – 12:30 PM CDT

Interesting in joining us for the webinar? If you’re in the Middle Tennessee area and would like to attend the event in-person, we’d love to have you. Just click here to register. The location is: Vaco Nashville 5501 Virginia Way #Suite 120 Brentwood, TN 37027.

If you would like to attend the webinar presentation, you can register here.

If you’re not able to attend, here’s some additional information that may help. You can also email me and I’ll send the slide deck presentation.

Want to work with The SERO Group?

Backups are good. But it’s the ability to restore that is important.

We help a lot of companies prepare their SQL Server environment so that when a disaster strikes, they’ll be prepared. They know they have good backups. They know they can restore in a timely manner (RTO) and to a point-in-time (RPO) that is important to them.

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

The post Webinar: Virtual Machine Backups – RTO and RPO Considerations for you SQL Server appeared first on The SERO Group.