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.

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.

That’s the question someone on LinkedIn recently posted in the SQL Server Administrators group recently. Here’s a link to the question. The LinkedIn poster essentially wanted to know how SQL Server handles permissions when a user is a member of more than one database role if the roles conflict.

The short answer is: permissions in SQL Server are cumulative. If a user is a member of the db_datareader role and the db_datawriter role, the user will have both read and write permissions to the table. However, when DENY is thrown into the mix, it trumps all other assigned permissions. It doesn’t matter if multiple roles grant access to a table, if even one DENY is present for the user, the user will not have access to the table.

Here’s a link to some documentation that provides additional information and background. Database-Level Roles – SQL Server | Microsoft Docs

Testing db_datareader and db_denydatareader precedence

Sometimes an example is worth a thousand words so let’s create a simple scenario to demonstrate how db_denydatareader overrides db_datareader. For this example, I’ll use the BaseballData sample database.

Let’s start by creating two users, Arnie and Belinda.

USE MASTER; 
GO 

--create logins
CREATE LOGIN Arnie WITH PASSWORD = 'a7a68d@@#8tn'; 
CREATE LOGIN Belinda WITH PASSWORD = '**4mfn*@!96f';


--create database users 
USE BaseballData; 
GO 

CREATE USER Arnie FOR LOGIN Arnie; 
CREATE USER Belinda FOR LOGIN Belinda; 

Neither Arnie nor Belinda have access to the players table at this point.

--test access to the the players 
EXECUTE AS LOGIN = 'Arnie';

--attempt to select from the players table
SELECT TOP 5 USER_NAME(), lahmanID, nameFirst, nameLast FROM players; 

REVERT; 

Now, let’s assign Arnie to the db_datareader role. We’ll assign Belinda to the db_datareader and db_denydatareader roles.

--add Arnie to the db_datareader role
ALTER ROLE db_datareader ADD MEMBER Arnie; 
GO 

--add Belinda to the db_datareader and db_denydatareader roles
ALTER ROLE db_datareader ADD MEMBER Belinda; 
ALTER ROLE db_denydatareader ADD MEMBER Belinda; 
GO 

Test Arnie’s access to the players table.

--test access to the the players 
EXECUTE AS LOGIN = 'Arnie';

--attempt to select from the players table
SELECT TOP 5 USER_NAME(), lahmanID, nameFirst, nameLast FROM players; 

REVERT; 

Meanwhile for Belinda.

--test access to the the players 
EXECUTE AS LOGIN = 'Belinda';

--attempt to select from the players table
SELECT TOP 5 USER_NAME(), lahmanID, nameFirst, nameLast FROM players; 

REVERT; 

So Belinda, despite being a member of the db_datareader database role was denied access to the table because she was also a member of the db_denydatareader role. DENY trumps GRANT.

Finally, for good measure, let’s remove Belinda from both roles and then add them back in reverse order. This will prove that order doesn’t matter when role member is assigned.

-- remove Belinda from her roles
ALTER ROLE db_datareader DROP MEMBER Belinda; 
ALTER ROLE db_denydatareader DROP MEMBER Belinda; 
GO 

--add Belinda to the roles in reverse order
ALTER ROLE db_denydatareader ADD MEMBER Belinda; 
ALTER ROLE db_datareader ADD MEMBER Belinda; 
GO 

Running the select statement again for Belinda, produces the same result – access denied.

So, when a user is assigned to multiple database roles, the effective permissions are cumulative, except when DENY is present. DENY means deny. Period.

Testing db_datareader and db_denydatareader precedent for sysadmin and db_owner

Oh, but you say, what about members of elevated roles such as db_owner and sysadmin? Will DENY still override someone who has that level of access?

Ahh! Good question. Let’s see.

Let’s create a third user, Charlene, and make her a member of db_owner. We’ll also create a login, Dallas, and make it a member of the vaulted sysadmin server role. Note: in the example, we’ll add Dallas as database user. Members of the sysadmin role have access to database resources, such as tables, without the need for an associated database user. However, since db_denydatareader is a database role, Dallas will need a database user so we can attempt to deny the login with the database role.

USE MASTER; 
GO 

--create logins
CREATE LOGIN Charlene WITH PASSWORD = 'ynr87rn3!u*b'; 
CREATE LOGIN Dallas WITH PASSWORD = ')rbc$6t*hlq1';
GO 

--add Dallas to the sysadmin server role
ALTER SERVER ROLE sysadmin ADD MEMBER Dallas; 
GO 

--create database users 
USE BaseballData; 
GO 

--create user Charlene
CREATE USER Charlene FOR LOGIN Charlene; 
GO

--create user Dallas 
CREATE USER Dallas FOR LOGIN Dallas; 
GO

--add Charlene to the db_owner database role
ALTER ROLE db_owner ADD MEMBER Charlene; 
GO 

Now let’s test their access as members of db_owner and sysadmin to the players table.

--test access to the the players 
EXECUTE AS LOGIN = 'Charlene';

--attempt to select from the players table
SELECT TOP 5 USER_NAME(), lahmanID, nameFirst, nameLast FROM players; 

REVERT; 


--test access to the the players 
EXECUTE AS LOGIN = 'Dallas';

--attempt to select from the players table
SELECT TOP 5 USER_NAME(), lahmanID, nameFirst, nameLast FROM players; 

REVERT; 

As expected, both natively have access to the players table due to their elevated permissions.

Now, let’s add Charlene and Dallas to the db_denydatareader database role.

--add Charlene and Dallas to the db_denydatareader role
ALTER  ROLE db_denydatareader ADD MEMBER Charlene;
ALTER  ROLE db_denydatareader ADD MEMBER Dallas; 
GO 

Running the same query again as Charlene and Dallas now produces the following.

So, members of the db_owners database role can be denied access to key tables and resources within a database using database roles. However, members of the sysadmin server role will still have access even if their associated database user is denied access.

If you’ve been following along and want to clean up after your code

USE BaseballData; 
GO

DROP USER Arnie; 
DROP USER Belinda; 
DROP USER Charlene; 
DROP USER Dallas; 

USE MASTER; 
GO 

DROP LOGIN Arnie; 
DROP LOGIN Belinda; 
DROP LOGIN Charlene; 
DROP LOGIN Dallas; 

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 Takes Precedent db_datareader (GRANT) or db_denydatareader (DENY)? appeared first on The SERO Group.