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 risks of delaying code analysis

Delaying an analysis of code compatibility is surprisingly common for businesses undertaking a migration to the cloud. Early cost-benefit analyses often address the hardware and infrastructure changes involved but can sometimes neglect to consider the impact of required code changes.

Infrastructure concerns are critical considerations when evaluating a move to the cloud. However, limiting our analysis to these considerations may hide the costs and risks associated with any necessary re-engineering. Unfortunately, it is very possible for these hidden risks and costs to turn out to be deal-breakers. To avoid a sticky situation, learn about these factors up front before investing time and energy into migration preparations.

Azure options: SQL VM vs. Managed Instance vs. SQL Database

It is important to note that a “move to the cloud” can come in many forms. Some examples are migrations to a hybrid environment, “lift and shift” moves to Azure-hosted VMs or SQL Managed Instances (SQL MI), or full or partial migrations to multi-tenant Azure SQL Databases (SQL DB). You will need to know what type of migration is being considered before evaluating code changes since the different options have different levels of compatibility with SQL Server.

Here’s a quick breakdown of the options in Azure with SQL Server compatibility.

IaaS Option

SQL Server on an Azure VM
Since this option constitutes a full installation of SQL Server on a dedicated Azure-hosted virtual machine, there are no code or feature incompatibilities to be concerned about. Azure SQL VMs achieve complete feature parity with on-premises SQL environments. With this option, the primary difference between the Azure implementation and an on-premises installation is the management of the underlying server.

PaaS Options

Azure SQL Managed Instance
SQL MI boasts “near 100% compatibility” with the latest Enterprise Edition of the SQL Server database engine, while still including automated backups, patching, and high availability of the SQL environment. This option uses a single-tenant database engine intended to enable the least disruptive migration from an on-premises or Azure-hosted SQL Server instance to a full PaaS environment. This means that many of the incompatibilities that exist with Azure SQL Database are minimized or eliminated with Azure SQL MI. However, functionality that requires access to the file system or OS is still impacted.

Azure SQL Database
Azure SQL DB is another fully managed PaaS option consisting of a multi-tenant database engine that is optimized for cloud-native applications. While this option is generally less expensive than Azure SQL MI, there is less overlap with SQL Server and greater potential for code or data flow incompatibilities.

10 Common Incompatibilities

There are several very helpful tools (see the “Resources and tools” section below) that can help you identify data flow issues prior to migration. As you go through your analysis, keep in mind that Microsoft has established workarounds for a good number of these incompatibilities, so their presence in your code does not necessarily mean they are a barrier to migration.

For a high-level overview, here are some of the most common sticking points we see for migrating SQL code. The differences between SQL MI and SQL DB are included where applicable, as well as some potential workarounds.

1. Uses linked servers

Linked servers can be used in SQL MI to access SQL Server and Azure SQL Databases without distributed transactions. SQL DB requires the use of elastic queries instead.

2. Performs cross-database queries or transactions

These are supported with SQL MI, but not with SQL DB. In SQL DB, cross-database queries may be able to be converted to elastic queries.

3. Uses Database Mail

This is available for SQL MI but not SQL DB. There are workarounds available for sending email in the Azure platform, but they will require some re-engineering.

4. Uses system tables, views, functions, or stored procedures

Some system objects are available in both SQL MI and SQL DB but not all. Consult Microsoft’s documentation for a full comparison of what is available.

One important note is that the amount of space available to tempdb is provisioned in both SQL MI and SQL DB based on the number of cores available and the service tier licensed. Consult the documentation of each for details.

5. Accesses Windows command line or file system

Neither SQL MI nor SQL DB supports direct access to the file system or the Windows command line.

One workaround is to migrate files to Azure Blob Storage or Azure Files. For SQL MI, with the appropriate security and firewall configurations, it is also possible to establish connectivity between your Managed Instance’s VNet and the location of an on-premises file share.

SQL MI also supports SSISDB configuration and the Integration Services Catalog, allowing SSIS packages to be used for file manipulation. Azure Data Factory can also be leveraged to load and transform files for both SQL MI and SQL DB. An Azure-SSIS Integration Runtime (IR) can be installed and configured, and SSIS packages can be run directly from Azure Data Factory.

6. Uses change data capture (CDC)

Change data capture is supported for SQL MI. It is also supported for SQL DB, but only in the S3 service tier and above.

7. Uses BULK INSERT or OPENROWSET

BULK INSERT and OPENROWSET are only supported from a supported Azure file source (e.g.: Azure Blob Storage or Azure Files).

8. Uses .NET Framework: common language runtime (CLR)

CLR support is not available for SQL DB, but it is available in SQL MI with some important differences.

9. SQL Server Agent

SQL Server Agent is not available in SQL DB, and elastic jobs should be used instead. In SQL MI, SQL Server Agent is supported with important differences.

10. Uses semantic search

Full-text semantic search is not available in either SQL MI or SQL DB.

Other important things to remember when migrating to a PaaS environment

• High availability: Since high availability is included in the PaaS offerings, SQL Server functionality and syntax connected with Always On Availability Groups is not supported.
• Maintenance: Updates, patches, backups, and restores are likewise managed automatically in the PaaS offerings. Therefore, associated T-SQL syntax will not work in SQL DB and will be different for SQL MI.
• Credential management: Windows authentication is not supported in SQL DB, and is replaced by Windows Authentication for Microsoft Entra in SQL MI.
• Collation: Catalog collation is set when an instance (SQL MI) or a database (SQL DB) is created, and it cannot be changed afterwards.

Resources and tools

I hope this provided you with a jump-start for thinking about whether your SQL Server code is Azure-ready.

Here are a few more resources and tools that can help you take the next steps toward a full compatibility analysis:

• Data Migration Assistant – Microsoft’s robust tool for enabling database compatibility assessments, recommendations, and migration assistance.
• Azure Migrate – this service can be used as a start-to-finish hub for planning and facilitating a cloud migration.
• Pro Database Migration to Azure – An excellent and comprehensive book covering the best practices for successful on-premises migrations to the Azure cloud platform.

Want to learn more?

Want to learn more about how The SERO Group helps organizations prepare for a SQL Server cloud migration? Schedule a call and let’s talk.

The post Is your SQL Server Code Ready for Azure? appeared first on The SERO Group.

The specs for the VM we’re using are:

• Standard B4ms (4 vcpus, 16 GiB memory) – Supports up to 2880 IOPs or 35 MBps.
• Target disk – Standard SSD E10 – 500 IOPs or 60 MBps. This drive is capable of bursting to 600 IOPs or 150 MBps.

We’ll use Microsoft’s diskspd utility to generate the load using the 8kb block size.

Azure VM Metrics – Reviewing disk-related counters

Using Azure VM Metrics, you can review numerous counters related to the VM and create alerts based on a set threshold. We’re focused on the following counters within the Virtual Machine Host namespace. Three separate charts are used. FYI, filters can be added if you’re only interested in a specific disk. Identify the disk LUN and then add the LUN filter to the chart.

Disk Throughput / Sec – Write and Read

• Data Disk Write Bytes/sec
• Data Disk Read Bytes/sec

Disk Operations / Sec (IOPs) – Write and Read

• Data Disk Write Operations/sec
• Data Disk Read Operations/sec

Disk Latency

• Data Disk Latency (Preview)

The screenshot below shows each one of the counters. The time range has been set to the last 30 minutes, which refreshes every 5 minutes.

In the example above, we’ve maxed out on read IOPs, leading to severe latency (above 1 second). By maxing out on IOPs, we’re also limiting in how much data can be read from the disk. At 8kb blocks * 524 IOPs, the disk maxes out at 4.1 MB/s. It’s important to note that if your application reads or writes in larger block sizes it is possible to increase throughput at the cost of lowering IOPs.

Conclusion

The example above represents a bottleneck encountered at the disk vs. the VM size. We’re nowhere near the VM’s limit of 2,880 IOPs or 35 MBps. Azure VM Metrics is a fantastic way to review performance counters directly from within the Azure portal.

For more information

If you’d like some assistance assessing your SQL Server workload on an Azure Virtual Machine, reach out. We’re happy to help.

In the meantime, here are some other posts you may find interesting.

• Identifying SQL Server Disk Latency
• Identify Disk I/O Performance Issues for Your SQL Server Using DiskSpd
• Azure shared disks – Failover Clustered Instances
• How to Create SQL Server 2019 Failover Clustered Instances in Azure
• Why is My SQL Server Slow? 14 Common Reasons
• 10 Data Storage Considerations for Growing Companies

The post Analyzing Disk Latency in Azure Virtual Machines – Part 2 appeared first on The SERO Group.

When hosting SQL Server on Azure Virtual Machines, choosing the right combination of VM size and disk types is essential from both a cost and performance perspective.

However, workloads change over time and may require resizing the Azure VM or disks. For example, perhaps you deployed a new application that utilizes SQL Server on an Azure Virtual Machine. At first, usage was low, but now the application has become critical to the organization, and usage has increased significantly. You’ve noticed disk-related waits in SQL Server have increased, and you are wondering how to address the latency and end users have started to complain.

Tracking down disk performance issues can be tricky. There are multiple layers to consider. Is it the virtual machine or the disk(s) causing the bottleneck?

In Azure, disks and VMs have a cap on how much throughput and IOPs can be performed. When looking into disk performance issues, it’s essential to account for the following at both the VM level and Disk level, as each has different levels of performance:

• VM – Max cached and temp storage throughput (IOPs/MBps). Not all VMs support premium storage caching.
• VM – Max uncached disk throughput (IOPs/MBps)
• VM – Max data disks
• Disk – Max disk size
• Disk – Max throughput (MB/s)
• Disk – Max IOPs

To understand the VM level caps mentioned above, let’s review the three paths an IO can take: Cached, Uncached, Local/Temp disk.

Azure Virtual Machine Disk IO Paths

Cached

Purpose: Host caching in Azure is designed to improve performance by storing frequently accessed data closer to the VM. This caching mechanism enhances read operations and can significantly reduce latency.

Types of Operations: It’s typically used for read-heavy workloads. You can configure host caching to be read-only or read/write (not recommended for disks hosting transaction log files). Read-only caching is ideal for workloads that predominantly involve read operations, while read/write caching is suitable for a balance of read and write operations.

Performance: Cached I/O allows for higher IOPS and throughput as it utilizes the VM’s cache, which is faster than accessing data directly from the disk.

Limitations: The amount of storage available for host caching is limited and specified in the VM’s documentation. Also, cached I/O counts towards the VM’s cached limits.

Data Integrity: For read/write caching, writes are initially written to the cache and later written to the disk, which can be a concern for workloads requiring immediate persistence on disk.

Uncached

Purpose: Uncached disk I/O involves direct interaction with the disk without the intermediate caching layer. It is used for less frequently accessed data or when the latest data is required.

Types of Operations: Suitable for workloads that involve a significant amount of write operations or where data integrity and immediate persistence are crucial.

Performance: Generally, uncached disk I/O has lower performance compared to cached I/O due to the absence of the caching layer. The IOPS and throughput are limited by the disk’s and VM’s capabilities.

Limitations: The performance is constrained by the disk type and size and VM size. For example, a P30 disk can handle up to 5,000 IOPs.

Data Integrity: Since all operations are directly on the disk, there is immediate persistence of data, which is critical for certain applications and data security protocols.

Local/Temp disk

Purpose: Temporary disks provide short-term storage for applications and processes running on the VM. They are primarily used to store data that doesn’t need to be persistent, such as swap files, system caches, page files, or temporary data files (tempdb for example).

Performance: Temporary disks are typically faster than standard storage disks because they are located on the same physical machine as the VM. The performance of the temporary disk is tied to the VM size and offers high I/O throughput and low latency, making them ideal for temporary workloads and caching.

Data Persistence and Reliability: Data on the temporary disk is volatile. This means it persists only during the lifetime of the VM instance. If the VM is stopped or de-allocated (not just restarted), data on the temporary disk is likely to be lost. During some maintenance events or when the VM is moved to a different host hardware, the data on the temporary disk can also be lost.

Therefore, temporary disks should not be used for any data you need to keep.

To learn more on how Azure High-Scale VMs utilize disk caching, see here.

Azure VM Size Limitations

Each Azure Virtual Machine size has the following properties defined (some VM sizes include additional properties such as burstable credits and cached throughput):

• vCPU – Number of virtual CPUs
• Memory GiB
• Temp Storage
• Max Data Disks – Number of data disks that can be attached.
• Max Network Bandwidth (Gbps)
• Max NICs – Max number of network interface cards.
• Max uncached disk throughput IOPS/MBps – Combined total of all disks. For example, the remaining disks will encounter latency if one disk uses all available IOPs.

We’ll focus on the disk-related properties throughout this series.

Conclusion

In part 2, we’ll review an Azure VM experiencing high disk latency. We’ll use Azure VM Metrics to help identify where the bottleneck may be and how to alleviate the issue.

In the meantime, here are a few other articles that may be helpful.

• Azure shared disks – Failover Clustered Instance – SQL Server 2016
• Azure shared disks – Failover Clustered Instances
• How to Create SQL Server 2019 Failover Clustered Instances in Azure
• Identifying SQL Server Disk Latency
• 10 Data Storage Considerations for Growing Companies

If you’d like some assistance assessing your SQL Server workload on an Azure Virtual Machine, reach out. We’re happy to help.

The post Analyzing Disk Latency in Azure Virtual Machines – Part 1 appeared first on The SERO Group.

• Contained Availability Groups
• Enhancements to Availability Groups and Distributed Availability Groups
• Query Store enhancements, including being available on secondary replicas
• Parameter Sensitive Plan (PSP) optimization
• Ledger to help assure data hasn’t been tampered with

You can learn more about SQL Server 2022 on the What’s new in SQL Server 2022 – SQL Server | Microsoft Docs site.

Now, how can you explore SQL Server 2022’s new features?

Test Driving SQL Server 2022

Containers are a great way to explore new versions of a product like SQL Server without having to actually install bits on your computer that you’ll later want to remove. Containers are lightweight, standalone, and have everything required to run SQL Server. There’s nothing to install directly on your host machine. And nothing to remove later, except, of course, the container and image file. But those won’t leave remnants of SQL Server in your registry or file system.

Prerequisites

To use SQL Server in a Docker container, you’ll need the Docker Desktop. There are versions for most every desktop platform, including Windows, Mac, and Linux. In Getting Started with SQL Server in a Docker Container – The SERO Group, I walk through the process of configuring Docker Desktop for a Windows 10 client. If you don’t already have the Docker Desktop installed, do that first.

Pulling the SQL Server 2022 container image

Once you have Docker Desktop in place, you can pull (download) the SQL Server 2022 image using the following command in the Windows command prompt.

docker pull mcr.microsoft.com/mssql/server:2022-latest

Starting the SQL Server 2022 container

Once the pull has completed, you can create the container from the image using the following command.

docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=iO1$6sJ&64YRCJAx" -p 1433:1433 --name sql2022ctp1 -d mcr.microsoft.com/mssql/server:2022-latest

The ACCEPT_EULA parameter indicates that you agree to Microsoft’s End User Licensing Agreement. SA_PASSWORD parameter is where you set the sa password for this instance. You’ll want to replace iO1$6sJ&64YRCJAx in the example above with a complex password of your choosing.

The -p parameter allows you to map a TCP port on the host environment to a port in the container. In this example, I’m mapping the default host environment port of 1433 to the container port of 1433.

Set the name for your container using the –name parameter. I’m naming this one sql2022ctp1.

And finally, the -d parameter is the name of the container image your want to run.

Listing your containers

You can use the following command to list all containers in your Docker environment.

docker ps -a

You can see that this Docker environment has two SQL Server 2019 containers, sql2019 and sql2019a, along with our newly created container, sql2022ctp1. The sql2022ctp1 container is running. The other two are not.

You can also see your containers in the Docker Desktop as shown below.

Querying the SQL Server 2022 instance

Using Azure Data Studio or SQL Server Management Studio, you can connect to your new SQL Server 2022 instance and query as normal from your host operating system. For example, running the following query in Azure Data Studio will return the SQL Server Edition, Version, and Product Level.

SELECT  SERVERPROPERTY('Edition') AS SQLEdition,
        SERVERPROPERTY('ProductVersion') AS ProductVersion,
        SERVERPROPERTY('ProductLevel') AS ProductLevel;

You can use the following query to review information about the host operating system.

SELECT  host_platform, 
        host_distribution, 
        host_release
FROM    sys.dm_os_host_info;

Exploring SQL Server 2022’s new features

Now that you have a working SQL Server 2022 instance, you can begin exploring its new features.

For example, I’d like to better understand the new Parameter Sensitivity Plan (PSP) optimization enhancements. So, I restored a copy of the BaseballData database that I sometimes use for testing and demos. See Getting Started with SQL Server in a Docker Container – The SERO Group for how to restore a backup to your container.

Next, I set the compatibility level of the BaseballData database to 160 and enable Query Store using the following t-sql commands.

ALTER DATABASE BaseballData  
SET COMPATIBILITY_LEVEL = 160;  

ALTER DATABASE BaseballData 
SET QUERY_STORE (QUERY_CAPTURE_MODE = auto);

To verify that setting the compatibility level to 160 enabled PSP optimization, I can run the following query.

SELECT name, value, is_value_default
FROM sys.database_scoped_configurations
WHERE name = 'PARAMETER_SENSITIVE_PLAN_OPTIMIZATION'

Now I can begin experimenting how PSP optimization affects my queries. For more information about PSP optimization, see Parameter Sensitivity Plan optimization – SQL Server | Microsoft Docs.

Stopping and starting your Docker container

You can leave your container running all the time if you wish. However, if you like to stop it and start it again later, you can with the following command, where sql2022ctp1 is the name you gave to your container.

docker stop sql2022ctp1

To start the container later, use the following.

docker start sql2022ctp1

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 free 30-minute call to see if our SQL Server Health Check or one of our SEROShield plans is right for you.

Schedule a call with us to get started.

The post Use a Docker Container to Explore SQL Server 2022’s New Features appeared first on The SERO Group.

Why are SQL Servers often misconfigured?

SQL Server is robust. Microsoft has put a lot of effort into creating a database platform that works well even when not configured optimally.

Unfortunately, SQL Server’s robustness and its dependability is sometimes taken for granted. In larger organizations with hundreds of SQL instances, the DBA team often doesn’t have the time or tools to get to know each instance. They sometimes have to manage by exception, tackling problems as they arise.

In smaller companies without the need or budget for a full-time DBA, another IT professional is tasked with SQL Server duties. They split time between their primary job and managing the SQL Server.

In Why 9 Out of 10 SQL Servers Aren’t Configured with Best Practices, we share 5 reasons why many SQL Servers aren’t configured with industry best practices. Here’s a summary. I encourage you to go read the full post.

1. SQL Server is so easy to setup
2. SQL Server just works
3. Introducing the Accidental DBA
4. Duct-taping with hardware
5. Everyone has their own standards

A free infographic: SQL Server settings commonly overlooked

We work with SQL Servers of all shapes and sizes. Some have high transactional volumes while others are used only for reporting purposes. Some measure their storage requirements in TB while others are a faction of that size. They are in the cloud, in colocation data centers, and in the server room.

We support SQL Servers used in healthcare, legal, banking, government, import/export, construction, manufacturing, and retail distribution.

We’ve found that there are five commonly overlooked issues that can cause performance or reliability issues for the SQL Server. Here they are in a short infographic.

Fortunately, these are not difficult to resolve.

If you’d like more detail about each of these, download our 5 Risks to SQL Security & SQL Server Performance | Download | SERO (theserogroup.com) pdf.

How is your SQL Server?

Have some uncertainty around your SQL Server backups? Schedule a free 30-minute call to see if our SQL Server Health Check or one of our SEROShield plans is right for you.

The post Infographic: 5 Commonly Overlooked SQL Server Settings appeared first on The SERO Group.

In short: how should I configure my SQL Server tempdb so that it performs well and doesn’t become a bottleneck? And is there an easy way to tell if my SQL Server tempdb is configured properly?

Let’s start with how should your tempdb be configured.

How should the SQL Server tempdb be configured?

Configuring SQL Server tempdb is a bit of a balancing act. Settings appropriate for one instance may not be right for another instance. And since tempdb can have dramatic implications for the performance for all databases on the SQL instance, it’s important to get it right.

Microsoft has good information on the SQL Docs page to help you optimize the tempdb system for performance. I’ll summarize here, but you should really go read it yourself in SQL Docs.

• Number: This will depend on several factors, including the number logical processors available to the instance. A good starting point is:
  • 1 to 8 processors – create one tempdb file for each logical processor.
  • More than 8 processors – start with 8 tempdb files and monitor. If contention in tempdb becomes a bottleneck, increase the number of data files in increments of 4 and continue to monitor.
• Size: All tempdb data files should be the same size.
• Growth: Set growth increments to a reasonable size, and make sure it’s the same for all tempdb data files. Don’t grow by percentage.
• Location: Place your tempdb files somewhere other than on the operating system drive.

Is my SQL Server tempdb configured properly?

Okay, now that we know a good starting point for our tempdb configuration, are we there? Or do we need to make some changes?

Let’s check.

You can, of course, open SQL Server Management Studio and drill down into the tempdb setting to have a look. Or, you can write some T-SQL queries to return the configuration information. There’s a nice little query on SQL Docs for this.

My favorite way for a quick check, however, is to use the Test-DbaTempDbConfig command in dbatools. Use the command below, replacing the name of the instance with the instance name you’re interested in.

Test-DbaTempDbConfig -SqlInstance sql2019 | format-table -Wrap

Here’s the output from a test system.

The command returns six lines of output. These roughly correspond to the settings mentioned above – file size, location, growth settings, and max size.

The command also checks for Trace Flag 1118. Read more about this Trace Flag in KB328551.

Review your tempdb settings and refine, if needed

Regardless of whether you used the database properties in SSMS, ran a T-SQL query to return the settings, or used the dbatools powershell script above, review the current configuration for your tempdb. Determine if a change is warranted and update the settings, if needed. Add some additional files, resize the existing files, adjust the growth settings, etc.

As a general rule, these changes will require a restart to take effect. (Depending on the specific change, that’s not always the case, but it’s generally better to make the changes during a maintenance window and restart the SQL Server service.)

For more information on configuring your SQL Server tempdb

Want to know more about SQL Server tempdb and how it should be configured? See the following pages.

• tempdb database – SQL Server | Microsoft Docs
• 3 Ways to Find Your SQL Server tempdb Data Files
• How Many tempdb Data Files Should My SQL Server Have?
• TempDB in SQL Server: Temporary Data with Long Term Problems (sentryone.com)

Want to work with The SERO Group?

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

Schedule a call with us to get started.

The post How to Configure SQL Server tempdb? 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.