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.

Multi-Attach EBS volumes in AWS enable organizations to use Windows Server Failover Clusters with shared storage. Attaching a single EBS (Elastic Block Store) to multiple EC2 instances simultaneously makes them ideal for SQL Server FCIs.

What are Multi-Attach EBS Volumes?

These EBS volumes are single Elastic Block Store volumes that can be attached to multiple EC2 instances. The feature is available for io1 and io2 Block Express volumes. However, Windows instances only support io2 Block Express volumes. Multi-Attach facilitates high availability and seamless failover for SQL Server FCIs (similar to how they operate on-premises).

Prerequisites

Before setting up these volumes for SQL Server FCIs, ensure the following prerequisites are met:

1. EC2 Instances in the same Availability Zone

All EC2 instances that will attach to the EBS volume must reside within the same AZ. This ensures low latency and high throughput between the instances and the EBS volume. This is critical for maintaining performance and reliability in a failover scenario.

2. Supported EBS Volume Types

While both io1 and io2 Block Express volumes support the Multi-Attach option, Windows instances only support io2 Block Express volumes. This limitation is due to the enhanced performance and features that io2 Block Express provides.

3. Regional Availability of io2 Block Express Volumes

Verify that io2 Block Express Volumes are available in your AWS region. Not all regions may support this volume type, so review the Amazon EBS Provisioned IOPS SSD volumes user guide to confirm availability.

4. Additional Networking and VPC Configurations

While this post focuses on EBS Multi-Attach, ensure that your networking and VPC configurations meet the requirements for setting up a Windows Server Failover Cluster. See this link to review the full list of prerequisites for WSFC.

io2 Block Express Volumes

These volumes offer the highest-performance block storage. Key features include:

• Capacity: Ranges from 4 GB to 64 TB, accommodating various workloads.
• Performance:
  • IOPS: Up to 256,000 IOPS per volume.
  • Throughput: Maximum throughput of 4 GB/s per volume

These high-performance metrics make io2 Block Express volumes ideal for demanding SQL Server workloads, especially those requiring rapid data access and high transaction rates.

Compatibility

io2 Block Express volumes are available on all Nitro-based EC2 instances. The AWS Nitro system is a collection of hardware and software components designed to provide enhanced security, performance, and flexibility for EC2 instances.

Enabling Multi-Attach for EBS Volumes

By default, this option is disabled but simple to enable. See this link for instructions on using the AWS Console or Command-Line.

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post How to Build SQL Server FCIs in AWS with Multi-Attach EBS Volumes appeared first on The SERO Group.

HADR for binkies? What? And how does this relate to SQL Server?

Sometimes the difference between the HA (High Availability) and DR (Disaster Recovery) can be difficult to grasp. There a nuances and the approaches can overlap. So, let’s consider an analogy – binkies and HADR in SQL Server.

As an infant, one of our daughters was very partial to her binky. She was seldom without one. Day or night, she “needed” her binky.

The Disaster Recovery analogy

We knew that life was better when she had a binky. Every time we left home, we strapped her into her infant car carrier, also known as a her “cry bucket”, and ensured she had a binky in her mouth.

If it was lost during our trip, life would be unpleasant. So we were prepared. We carried extra. At least one, sometimes more than one, just in case the unthinkable happened.

If she somehow managed to lose her binky, if it fell out along the way unnoticed, we would open the diaper bag and retrieve the spare.

That was binky DR. We would have to manually step in to solve the problem. She was disrupted until the fix was in place. But it was better than long periods of screaming about it. We could handle a little disruption and still avoid an all out disaster.

How this applies to SQL Server

The same is true for SQL Server. DR is a way to recover from some kind of disaster. It could be at the data center level, or at a SQL Server instance level. In either case, we need to recover from some kind of failure as quickly as possible.

In SQL Server, that could mean:

• Restoring from a backup. Assuming your backup process is robust, meets your RTOs and RPOs, and is regularly tested, you can apply the various backup files to get you back to whole again. Typically, you’ll restore a full backup, a differential backup, and then a serious of transaction log backups.
• Restore a virtual machine. If the failure affects the instance and not just a database, you may have to restore a virtual machine image. You may be done after that. Or you may have to restore a the backup files as described before to meet your RPO requirement.
• Switch to a stand-by SQL Server. Log-shipping can be a cost effective way to implement a level of DR. If you’re leveraging it as part of DR strategy, to recover you’ll need to make the standby SQL Server the new production SQL Server. You’ll stop log-shipping, recover database on the standby server, and point everything to the new production instance.
• Site-wide DR. Of course, some companies have a site-wide DR plan. If the entire data center is out of commission, they can failover to the DR site in another city or region. Properly configured, that can work very well. Typically, however, you don’t want to do that for a single instance of SQL Server. It’s reserved for disasters on a larger scale.

Disaster Recovery Summary

In all of these cases, manual intervention is required. Someone had to do something to get things back to normal. In our analogy, someone had to dig through the diaper bag to find the spare and give it to our daughter. Until that point, everyone was unhappy.

It’s also worth noting that we checked and double checked that we had a spare binky before leaving home. For SQL Server, you want to regularly test your backups to make sure you can indeed recover from them when needed.

High Availability

Our approach to binky DR when we left home tended to work pretty well. There were times when we weren’t able to recover quickly enough and drew awkward glares from those around us. However, for the most part it was a success.

At night it was a different story.

We would go through the bedtime process – reading a story, rocking for a little while, maybe even humming a lullaby, and gently placing her in her crib. Then we’d tip toe out of the room.

Unfortunately, at some point during the night, her binky would slip from her mouth. And before long, she’d notice. And when she noticed, we all were quickly made aware. One of us would have to get up, search through the blanket and put the binky back into her mouth.

Fortunately, we discovered a better way.

We began putting her in her crib with a binky in her mouth, and a spare one in each hand. That way, when the binky slipped from her mouth, she could quickly and easily replace it with one from her hand. This allowed her to sleep for longer periods and time. And us too!

Binky high availability at its finest.

How this applies to SQL Server

Many mission critical systems depend on SQL Server. For example, Practice Management Systems or Electronic Medical Records in healthcare, Project Management Systems or Job Costing Systems in construction, and core systems in the banking. They all rely on SQL Server. If SQL Server is down, the business is down. And that can be costly.

For those situations, we can leverage High Availability in SQL Server. Two technologies are commonly used.

• Failover Cluster Instance (FCI). With an FCI, one SQL Server instance is effectively spread across multiple Windows Server Failover Cluster nodes. SQL Server runs on the primary node. In the event of a planned or unplanned downtime, a secondary node will start its services, take ownership of the shared resources, and begin servicing application requests. This can happen automatically, often with minimal disruption to users.
• Availability Groups (AG). With an AG, SQL Server is installed on two or more nodes of a Windows Server Failover Cluster. (Strictly speaking the nodes don’t have to be WSFC. Linux clusters can be used.) As with the FCI, if a disruption occurs on the primary node, a secondary node will be promoted to primary and all application requests will be automatically directed to the new primary node. There are a lot of nuances to configuring an AG including synchronous / asynchronous transactions, automatic or manual failover, etc. The point here is that it can be configured to happen automatically and will little noticeable disruption to the end users.

High Availability Summary

One really nice distinction with High Availability is that it can happen automatically, without someone having to do something to make it happen. For businesses running critical applications on SQL Server, this can prevent costly unplanned and planned downtime.

For parents with kids dependent on binkies, this could mean hours of additional uninterrupted sleep each night.

In either case, HA can be really worth looking into.

Want to learn more?

Hopefully this analogy has helped. Here are a few addition resources that may likewise be helpful.

• What’s the Difference in SQL Server FCIs and AGs? – The SERO Group
• High Availability and Disaster Recovery in SQL Server – The SERO Group
• How to Create SQL Server 2019 Failover Clustered Instances in Azure – The SERO Group
• Azure shared disks – Failover Clustered Instances – The SERO Group
• Using VM Snapshots to Backup SQL Server? – The SERO Group
• Availability groups: a high-availability and disaster-recovery solution – SQL Server Always On | Microsoft Learn

If you’d like to talk though how improve your SQL Server’s reliability, give us a call. We’re happy to help.

The post HADR for Crying Out Loud appeared first on The SERO Group.

The right configuration settings are critical. Unfortunately, it’s easy to overlook many SQL Server settings and best practices. The defaults are not always the best.

A proper maintenance schedule for your databases and servers is important. So is regular monitoring. And a sound HADR plan that meets the needs of the business is critical.

Is your SQL Server healthy? A free webinar

In an upcoming webinar, we’ll discuss some commonly overlooked SQL Server settings and practices we uncover during our SQL Server Assessments. These can have dramatic effects on your database server’s performance and reliability. And we’ll share what you can do to fix them and help to keep your SQL Server healthy.

Register here for the free webinar on June 23, 2021.

In the meantime, check out these posts.

• Identifying SQL Server Disk Latency
• Scary and Dangerous Things in SQL Server
• Securing Your SQL Servers, What Should You Audit?
• When Was the Last Known Good DBCC CHECKDB Integrity Check?
• Identify Disk I/O Performance Issues for Your SQL Server Using DiskSpd
• Is My SQL Server Configured Properly?
• How Many tempdb Data Files Should My SQL Server Have?

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 Webinar: Is Your SQL Server Healthy? appeared first on The SERO Group.

There are a lot of how-to articles on the internet for setting up Always On Failover Clustered Instances (FCIs) and Always On Availability Groups (AGs). In fact, Luke Campbell created a couple of nice guides – How to Create SQL Server 2019 Failover Clustered Instances in Azure and Azure shared disks – Failover Clustered Instance – SQL Server 2016.

So, I won’t deep dive into the technologies. Rather I’ll share some of their key, high-level differences. The goal is to help you identify the better choice for your environment. Even with that narrow scope, this is a big topic. I’ll touch on the basics here and elaborate on the more advanced aspects in the future.

Keep in mind that there are lots of ways to combine different technologies to improve your HADR capabilities. For example, you can use a FCI to host one of the AG replicas. You can use Distributed AGs in different datacenters. And many other combinations.

There’s a TLDR; summary table comparing the two at the end of the post.

Comparing SQL Server FCIs and AGs

FCIs and AGs aren’t exactly apples and oranges. They have similarities. Both are native to SQL Server. And both can greatly reduce planned and unplanned downtime. However, there are some key differences in their requirements and the way they are implemented. These differences may influence what’s best in your environment. Let’s have a look.

What are the hardware and software requirements for FCIs and AGs?

Let’s begin by considering some of the aspects that may make one of these technologies a non-starter for you – the hardware and software requirements.

Windows Server Failover Clustering (WSFC) serves as the underlying foundation for both FCIs and AGs. At least in the Windows world. Pacemaker is used for clustering Linux instances. Here, I’ll refer to them collectively as WSFC.

FCI requirements and operation

With an FCI you’re essentially installing one instance of SQL Server across two or more nodes of a WSFC. Only one node is active at a time, the primary node. The secondary nodes are available, but not active. Clients connect to the Virtual Network Name and do not need to know which node is currently serving as the primary.

Should the primary WSFC node become unavailable, the SQL Server services are started on another node and it becomes the primary node. All databases, logins, jobs, etc, that are part of that SQL Server instance are available on the new primary node. That’s good. FCIs provide instance-level protection.

To make this possible, FCIs require shared storage. The primary WSFC node owns the shared resource. When it fails, another node will take ownership of the resource and then start its SQL services. The SQL binaries reside on each WSFC node, not the shared storage.

FCIs are available in both Standard Edition and Enterprise Edition of SQL Server. From a licensing perspective, FCIs are a single instance of SQL Server since only one node is actively serving clients. (Note: a qualified licensing expert should be consulted to ensure you fully understand the SQL Server licensing. It can get quite complex.)

AG requirements and operation

AS with FCIs, SQL Server is installed on each WSFC node that is part of an AG. However, unlike FCIs, the SQL Server service runs continually on each node. One of the nodes is designated as the primary replica and all other nodes are secondary replicas. Clients connect to a Listener that directs the connection to the primary replica.

Each WSFC node has its own copy of the AG databases. No shared storage is required. When changes are made to the primary replica, those changes are propagated to the secondary replicas. The increases the total storage capacity required. A two-node AG doubles your storage requirements. A four-node AG increases your storage requirements by a factor of four.

AG can be configured for HA (more on that later). Secondary replicas in HA mode typically do not require licenses.

When the primary replica in an AG configured for HA goes down, one of the secondary replicas becomes the new primary. The Listener directs all connections to the new primary replica.

AGs provide database-level redundancy. This means that all databases that are part of the AG will failover to the new primary replica at the same time. Instance-level objects are not part of the AG. So, logins, SQL agent jobs, etc, are not automatically available on the secondary replicas.

Basic Availability Groups are available in SQL Server Standard Edition. Basic AGs are limited to a two-node system with a single database. AGs in SQL Server Enterprise Edition can have multiple databases that failover together and up to 8 replicas per AG.

Is it HA, DR, or both?

There can be some overlap in what’s considered High Availability (HA) and what’s considered Disaster Recovery (DR). Though few would argue that the terms are interchangeable, some technologies can span across both terms depending on how they are implemented.

Generally speaking, HA means the databases remain online and fielding requests despite what would otherwise be a disruptive event. So, users don’t experience noticeable downtime due to unexpected events such as a hardware failure, or during normally scheduled maintenance windows.

DR, on the other hand, is typically a response to a more catastrophic event that could affect more than the SQL Servers. Fires, Tornados, flooding, hurricanes, etc, can hit a datacenter or even an entire region. Ransomware can make its way into a network. The question is how quickly can your team respond to such events?

FCIs and HADR

FCIs are generally considered an HA technology. They are designed to keep the databases online during unexpected events. FCIs can span multiple subnets, datacenters, etc, to help with DR, but they are primarily used for HA purposes.

AGs and HADR

AGs have couple of modes that are frequently used for different purposes. If the nodes are configured for Synchronous-commit mode, each transaction is held open until the secondary replicas are updated. This keeps the replicas up to date at the possible expense of performance. This is good for HA scenarios.

With asynchronous-commit modes, the transactions complete as soon as the log file is written on the primary replica. This allows for some lag between the primary and secondary replicas. Should the primary unexpectedly go offline, some data loss can occur. Asynchronous-commit mode is often used in DR scenarios, when secondary nodes are in a different datacenter or region.

What about RTO and RPO?

No HADR discussion is complete without Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs). How do FCIs and AGs stack up on RTOs and RPOs? (See Where to Start with Disaster Recovery in SQL Server for a description of RTOs and RPOs)

FCIs and RPOs / RTOs

Recall that each WSFC node has access to a shared storage resource. Only one node at a time owns the resource, but all nodes have access to it should they become the primary node. The system and user databases are located on the shared storage resource. As a result every transaction committed on the primary node persists after a failover to a new primary. There should be no loss of data during failovers.

During a planned failover, dirty buffers are written to disk on the primary before the role is transitioned to a new primary. During an unplanned failover, committed transactions that never made it to the data file are rolled forward during the start-up recovery process. Failovers are frequently very fast, however for busy systems, it can time some time.

AGs and RPOs / RTOs

As mentioned before, AGs can be configured in synchronous-commit or asynchronous-commit modes. Synchronous-commit mode can further be divided into “planned manual failover only” or “automatic failover”.

AGs configured with Synchronous-commit with automatic failover will, as the name implies, automatically failover to a secondary replica should the primary become unavailable. This process generally doesn’t take too long. Of course, you’d want to test in your environment to know what to expect.

For secondary replicas configured for Synchronous-commit with planned manual failover only, failover requires manual intervention. Once initiated, the failover typically occurs relatively quickly.

Asynchronous-commit replicas also require manual intervention and could experience some data loss since the secondary replica may be slightly out of sync with the primary.

How difficult is it to manage FCIs and AGs?

FCIs provide instance-level protection. Once installed and configured, FCIs are essentially a single instance of SQL Server spread across a WSFC. As a result, you don’t have to worry about ensuring logins, jobs, etc, are consistent among the WSFC nodes. If you’d like to add or remove nodes, use the SQL Server Setup program.

AGs, on the other hand, require a bit more effort. Since AGs provide database-level protection, you’ll need make sure that important instance-level objects that AG databases depend on are available on the secondary replicas. For example, primary replica logins are not automatically created on the secondary replicas. You’ll need to do the same for maintenance jobs. We typically add a step to the beginning of each job to determine whether the job is on the primary replica or a secondary replica. If the job is running on the primary, continue. Otherwise, don’t do anything.

What about patching FCIs and AGs?

Both FCIs and AGs can minimize downtime due to patching. Although the exact details vary, you can apply Windows and/or SQL patches to secondary nodes/replicas, manually failover the services so that the newly patched system becomes the primary node/replica, and then apply the patches to the remaining nodes/replicas.

This approach limits downtime to the time it takes to failover.

Are secondary nodes/replicas available for production use?

It can be interesting to think about using the secondary nodes/replicas to offload work from the primary node/replica. With FCIs this is unfortunately not possible. In fact the SQL Server service isn’t even running on the secondary nodes. So, the secondary nodes aren’t available for other purposes.

With AGs, you can configure secondary replicas for read-only access. This allows actions such as backups to be performed on the secondary replica. Additionally, you can offload some resources-intensive reporting queries to the secondary replica. Note, additional licenses are required if the secondary replicas are used for production proposes.

How do FCIs and AGs compare?

So, what’s the Difference in SQL Server FCIs and AGs? The following chart summarizes the differences.

* See the SQL Server 2019 Licensing Guide available on the Microsoft SQL Server licensing page.

Which is better, FCIs or AGs?

Is one of these two technologies better than the other? Yes, almost certainly. But, which one? That’s really going to depend on what your objectives are, on what technologies and licenses you have in place or can afford, and on how your SQL Servers fit into the broader HADR conversation.

The important thing is to take the first step. Start having the conversations.

In High Availability and Disaster Recovery in SQL Server, I also share a couple of other basic DR options – Backups and Log Shipping.

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 What’s the Difference in SQL Server FCIs and AGs? appeared first on The SERO Group.

There are a couple of easy ways to check for disk latency issues in SQL Server: using the sys.dm_io_virtual_file_stats DMV and using the dbatools.io Test-DbaDiskSpeed command. Let’s look at each.

Check disk latency using DMVs

Way back in SQL Server 2005, Microsoft introduced the sys.dm_io_virtual_file_stats Dynamic Management View (DMV). This DMV reports disk read and write activities for data and log files.

For many years, I’ve used a query based on one from SQLSkills’ Paul Randal. I’ve simply added a column to help quickly categorize/interpret the latency values. This query can be very helpful when troubleshooting what you suspect to be a disk I/O bottleneck.

SELECT
   [ReadLatency] =
        CASE WHEN [num_of_reads] = 0
            THEN 0 ELSE ([io_stall_read_ms] / [num_of_reads]) END,
   [WriteLatency] =
        CASE WHEN [num_of_writes] = 0
            THEN 0 ELSE ([io_stall_write_ms] / [num_of_writes]) END,
   [Latency] =
        CASE WHEN ([num_of_reads] = 0 AND [num_of_writes] = 0)
            THEN 0 ELSE ([io_stall] / ([num_of_reads] + [num_of_writes])) END,
   [Latency Desc] = 
         CASE 
            WHEN ([num_of_reads] = 0 AND [num_of_writes] = 0) THEN 'N/A' 
            ELSE 
               CASE WHEN ([io_stall] / ([num_of_reads] + [num_of_writes])) < 2 THEN 'Excellent'
                    WHEN ([io_stall] / ([num_of_reads] + [num_of_writes])) < 6 THEN 'Very good'
                    WHEN ([io_stall] / ([num_of_reads] + [num_of_writes])) < 11 THEN 'Good'
                    WHEN ([io_stall] / ([num_of_reads] + [num_of_writes])) < 21 THEN 'Poor'
                    WHEN ([io_stall] / ([num_of_reads] + [num_of_writes])) < 101 THEN 'Bad'
                    WHEN ([io_stall] / ([num_of_reads] + [num_of_writes])) < 501 THEN 'Yikes!'
               ELSE 'YIKES!!'
               END 
         END, 
   [AvgBPerRead] =
        CASE WHEN [num_of_reads] = 0
            THEN 0 ELSE ([num_of_bytes_read] / [num_of_reads]) END,
   [AvgBPerWrite] =
        CASE WHEN [num_of_writes] = 0
            THEN 0 ELSE ([num_of_bytes_written] / [num_of_writes]) END,
   [AvgBPerTransfer] =
        CASE WHEN ([num_of_reads] = 0 AND [num_of_writes] = 0)
            THEN 0 ELSE
                (([num_of_bytes_read] + [num_of_bytes_written]) /
                ([num_of_reads] + [num_of_writes])) END,
   LEFT ([mf].[physical_name], 2) AS [Drive],
   DB_NAME ([vfs].[database_id]) AS [DB],
   [mf].[physical_name]
FROM
   sys.dm_io_virtual_file_stats (NULL,NULL) AS [vfs]
   JOIN sys.master_files AS [mf]
   ON [vfs].[database_id] = [mf].[database_id]
      AND [vfs].[file_id] = [mf].[file_id]
-- WHERE [vfs].[file_id] = 2 -- log files
ORDER BY [Latency] DESC
-- ORDER BY [ReadLatency] DESC
-- ORDER BY [WriteLatency] DESC;
GO

When I run this query against a docker-based SQL Server 2017 instance, I receive the following results.

The Latency Desc column helps to interpret the results. Latency can be classified as shown in the following table. Of course, this is a rule of thumb and your needs may vary.

Check disk latency using dbatools

Fans of dbatools.io may already know that something similar to the query above is included as part of the Test-DbaDiskSpeed command.

You can run the command as-is, only providing the instance and credentials to use. I typically add a few other options to format the output into a table and send it to a file that I can easily examine.

Test-DbaDiskSpeed -SqlInstance localhost -SqlCredential sa | Format-Table -Property Database, SizeGB, FileName, FileID, FileType, DiskLocation, Reads, AverageReadStall, ReadPerformance, Writes, AverageWriteStall, WritePerformance, 'Avg Overall Latency' | Out-String -Width 4096 |out-file c:\temp\DbaDiskSpeed.txt

Running the PowerShell script on my docker-based SQL Server 2017 instance provides the following output file.

Let’s not ask SQL Server about disk latency

Of course, there will be those who mistrust the results from either of these methods, because, well, of course SQL Server wouldn’t fess up to being the bottleneck. It’s obviously going to point the finger elsewhere.

To address those claims, check out Identify Disk I/O Performance Issues for Your SQL Server Using DiskSpd. That tool completely removes SQL Server from the discussion and objectively tests the disk I/O.

But for a quick sanity check, you can’t beat the sys.dm_io_virtual_file_stats DMV and the Test-DbaDiskSpeed command.

Looking for other ways to diagnose or improve performance? Here are a few other posts that may help.

• Should I Add Hardware Resources to My SQL Server? Do This First.
• SQL Server Performance and Windows Power Plan
• How do Views Affect SQL Server Performance?
• Is My SQL Server Configured Properly?

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 Identifying SQL Server Disk Latency appeared first on The SERO Group.

There are a lots of great free options for learning SQL Server. I shared some in Want to Learn SQL Server? Here Are 3 Free Sources.

Many of those sources are directly from Microsoft through their labs, Channel 9, and EdX programs. Others are from members in the SQL Server community, both individuals and companies, usually in the form of training videos, user group presentations, and MeetUps.

But there are other resources, too, including some low-cost options for learning SQL Server.

PluralSight can be a great place to learn SQL Server

PluralSight has become a leading platform for training videos for all sorts of technical training. Some of the smartest people I know in the SQL Server world have top-notch training videos on PluralSight. I’m reluctant to begin mentioning names here because there are so many. I’m sure I’d accidentally omit someone. Nevertheless, stalwarts from the community who regularly share their knowledge in user group meetings, at conferences and pre-cons (in the pre-COVID days), and online in forums and Twitter’s sqlhelp hashtag have PluralSight courses. If you’re looking for one in particular, here’s a list of PluralSight authors. You can also search the PluralSight catalog of courses.

PluralSight is not free, however. You have to pay to have access to their content. They share that revenue with the contributors, so course authors get paid for their work. Note: I do not have any courses on PluralSight nor do I have a referral agreement with the company. So, I’m not hocking something to get a kickback .

For those of us that like to “try before we buy,” for the month of April 2021 PluralSight is making their content available for free. They are calling it FREEAPRIL.

Want to work with The Sero Group?

While you’re leveling up your SQL prowess, we’ll be happy to help out with any SQL Server needs you may have.

Schedule a call with us to learn more. There’s no obligation.

Footnote: I first started working with Microsoft SQL Server 6.5 back in 1996. In fact, that was one of the first certification exams I passed.

The post Learn SQL Server with PluralSight’s FreeApril appeared first on The SERO Group.

Scary things

Let’s start with scary.

Some things give us pause. We see them, think about them, and begin listing all the ways that something could go wrong.

Rappelling. Rappelling is a good example. Backing up to the edge of a rock mountain face with nothing between you and the distant ground. Leaning back as far as your can. Extending out from the safety of the ledge. Jumping backward with only a rope. It’s unnatural. Our instinct tells us we shouldn’t do it. Every fiber of our being screams “Nope!”

It’s scary.

But just because it’s scary doesn’t mean it’s unsafe. Or dangerous. With proper training and gear, rappelling is a great experience. It’s a lot of fun. And it can be done safely. We are aware of what we’re doing. We have a heightened sense and an increased awareness of the things that can wrong. And we purposely take steps to mitigate any danger present.

Scary things in SQL Server

In SQL Server, upgrades and server migrations can be scary. What happens if things go wrong? Can the migration be completed during the maintenance window? Will users be able to login when the time comes? What about performance afterward?

These are very real issues.

But, as with rappelling, we can take steps to mitigate the scary issues. We can meticulously plan the upgrade/migration. We can perform the upgrade/migration in a test environment first, allowing users to validate and approve before production is ever touched. Backups can be taken before the upgrade begins. The VM can snapshotted.

In short, we’ve identified the potential problems that could arise and we’ve taken precautions.

It may be scary, but it’s safe.

Dangerous things

Dangerous things are more concerning, especially if the danger is not recognized.

Walking along the side of a snow-covered mountain on a peaceful day. The sun warms your face. You can see for miles. Beauty abounds. It’s an exhilarating experience, a serene journey, a peaceful adventure.

Yet, it can also be dangerous. A foot or more beneath the crunch of each step, a layer of ice may have formed between two layers of snow. The ice creates a seam, a seam with little friction. It wouldn’t take much for that snow above the ice to begin sliding, creating an avalanche. And as we all know, avalanches are very dangerous for everyone nearby.

Dangerous things in SQL Server

In SQL Server, danger comes in many forms. Everything may seem ok, at least on the surface, but something could go very wrong, very quickly.

• Untested backups. Having backups but not testing them regularly.
• No alerts. A production SQL Server without configured alerts.
• Ignored alerts. Alerts that are ignored because there are too many false positives.
• Untested Disaster Recovery Plan. A crisis is not the time to try to figure out your DR.
• Assumed RPOs and RTOs. Not being able to recover to the right point in time in the allotted time.
• SQL Server health. Uncertainty about how your SQL Server is configured.
• Deferred maintenance. Preventative maintenance jobs take too long to complete so they are disabled.
• Unpatched SQL Servers. Patching is not scheduled regularly.
• Out of Support SQL Servers. There’s simply no time to upgrade so ancient versions of SQL Servers are still hanging around.
• Reacting rather than responding. Addressing the symptom rather than fixing the problem.
• Conflating HA and DR. High Availability and Disaster Recovery are similar but not interchangeable.
• Unmonitored SQL Server environments. SQL Servers are left on their own to report issues.
• Elevated permissions. Too many people with sysadmin or dbo privileges.

Of course, this is not a comprehensive list of all the dangers that can lurk in a SQL Server environment. I’m sure you have some from your experiences. Feel free to share in the comments below; I’d love to hear them.

Mitigating dangers in SQL Server

Recognition is the first step. We must identify and acknowledge the dangers inherent in our SQL Server environment. Then we can do something about them. We can take steps to mitigate the dangers, to reduce or even eliminate the problems we’ve identified.

Here are a few posts that may help.

• How Often Should I Test My SQL Server Backups?
• Is My SQL Server Configured Properly?
• SQL Server Assessments
• When Was the Last Known Good DBCC CHECKDB Integrity Check?
• Should I Upgrade SQL Servers that Are Out of Support?
• High Availability and Disaster Recovery in SQL Server
• DBA as a Service
• Securing Your SQL Servers, What Should You Audit?

And, of course, we’ll be happy to help. It’s what we do.

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.

(To give credit where it’s due. The idea for Scary vs Dangerous was adapted from Jim Koch’s excellent and entertaining book Quench Your Own Thirst.)

The post Scary and Dangerous Things in SQL Server appeared first on The SERO Group.