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.

Azure Arc is a set of technologies from Microsoft that extends Azure management and services to any infrastructure, including other clouds, on-premises, and edge. This enables you to manage all your SQL Server instances across environments from a single, unified interface.

Why use Azure Arc-enabled SQL Server?

Organizations operating in hybrid environments often face challenges in maintaining consistency across their SQL Server instances. This is especially acute with complex compliance requirements and security policies. Azure Arc addresses these issues by: 

• Streamlining operations: Having a unified platform for managing all SQL Servers simplifies the DBA’s tasks.
• Enhancing security: Leveraging Azure’s robust security framework helps protect data across all environments.
• Improving compliance: Automated compliance tools reduce the risk of violations.

Let’s take a look at a few key features.

Key features of Azure Arc-enabled SQL Server

• Unified Management: Azure Arc provides a centralized portal for managing all your SQL Server instances. Whether your databases are on-premises, in the cloud, or at the edge, you can see them from the Azure Portal. 
• Automated Updates: One challenge with managing SQL Servers across different locations is ensuring they are all updated and patched consistently. Azure Arc can automate this process, ensuring instances are always up to date with the latest security patches and performance improvements. 
• Advanced Security: You can apply Azure’s security management and threat protection capabilities to your SQL Server instances, no matter where they reside. This includes advanced threat detection using Microsoft Defender, vulnerability assessments, certificate rotation, and access controls.
• Compliance and Governance: Azure Policy can be applied to SQL Servers managed through Azure Arc, helping ensure compliance with external regulations and internal policies through automated checks.
• Business Continuity: Azure Arc enables you to configure automated backups to local storage, perform point-in-time restores, view Always On failover cluster instances, and view Always On availability groups.
• Migration Readiness: The Azure SQL readiness assessment evaluates the readiness of SQL Server migrations to Azure SQL (Azure SQL Managed Instance, SQL Server on Azure VM, Azure SQL Database).
• SQL Server Assessment: The best practices assessment provides a method to evaluate the configuration of SQL Server. Once enabled, an assessment scans the SQL Server instance and databases to provide recommendations.

How it works

Setting up Azure Arc for SQL Server involves installing the Azure Connected Machine Agent on your physical or virtual server first. This agent communicates with Azure and brings the SQL Server under Azure management. From here, you can perform operations like monitoring, setting up alerts, implementing backup solutions, and more from within the Azure Portal. 

In conclusion

Azure Arc-enabled SQL Server simplifies management, enhances security, and ensures compliance across all your SQL Server instances, regardless of their location. By extending Azure’s management capabilities to your on-premises and multi-cloud environments, Azure Arc helps you harness the power of the cloud wherever your servers may be.

Additional Resources:

• Azure Policy
• SQL Server enabled by Azure Arc
• Azure Connected Machine Agent Prerequisites
• YouTube – Azure Arc-enabled SQL Server Experience

Want to work with The SERO Group?

Are you interested in simplifying the management of your SQL Servers? Schedule a no-obligation call with us to learn more!

The post Azure Arc-Enabled SQL Server: Centralized Management for Hybrid Environments 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.

In How Often Should I Test My SQL Server Backups?, I shared a schedule we recommend to our customers for monitoring, verifying, and testing their SQL Server backups. That last part, testing the backups, is important, really important. So, I shared a couple of basic T-SQL scripts for restoring a database to a test location and running DBCC CHECKDB on it.

Fans of PowerShell know that testing SQL backups can also be done using dbatools. Let’s have a look. For this exercise, you’ll need PowerShell, of course, along with a recent copy of dbatools. You can download dbatools for free.

Backing up a SQL Server database with dbatools

Let’s start by backing our BaseballData database using the dbatools Backup-DbaDatabase command. This creates a native SQL Server backup file, the same file that is created with the T-SQL BACKUP DATABASE command.

In this example, I’m creating a Full back up the BaseballData database that resides on the local default instance of SQL Server. The instance is running in a Linux container, so the -Path parameter is formatted for a Linux file system.

Backup-DbaDatabase -SqlInstance localhost -SqlCredential sa -Database BaseballData -Type Full -Path /var/opt/mssql/backup

The command output shows that a SQL backup file has been created.

Testing a SQL Server backup using dbatools

Now that we have a SQL backup file, let’s use the Test-DbaLastBackup command to test the backup. This command performs several steps for us, including:

1. Restoring the SQL backup file to a destination with a new name. The destination can be the same or a different SQL Server instance.
2. Changing the database name to prevent confusion. The restored database will be called “dbatools-testrestore-BaseballData” by default. I can provide a different name, if I wish.
3. Changing the SQL database file names to prevent conflicts with original database files.
4. Checking the newly restored database with DBCC CHECKDB to confirm that it is in good working order.
5. Dropping the newly restored database as part of the clean up.

Notice that I didn’t specify which SQL backup file to test. The command finds the most recent Full backup to test.

Test-DbaLastBackup -SqlInstance localhost -SqlCredential sa -Database BaseballData   

The result of theTest-DbaLastBackup command are sent to the output screen by default. Of course, we can also send the results to a file.

Looking at the output, we can see that the database was successfully restored, and how long it took to restore it. We can also see that DBCC CHECKDB ran and how long it took to complete. We can dive into the results of the integrity check, too. See When Was the Last Known Good DBCC CHECKDB Integrity Check? for more information.

Test your SQL Server backups often

Using PowerShell and the Test-DbaLastBackup command makes testing your SQL backups relatively easy. Yes, you still need the disk space and server resources to do it. But being able to answer that frantic question “Do we have a good backup?” makes it definitely worth while.

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.

The post How to Test SQL Server Backups Using dbatools appeared first on The SERO Group.

Goals for your SQL Servers

Although every environment is unique and each business has its own set of important measures for success, here are five goals for your SQL Servers to consider as you plan the coming months. These goals are designed to help build a robust and responsive data infrastructure to support your organization.

1. Assess your SQL Servers
2. Update your SQL Servers
3. Start performing health checks
4. Implement monitoring and alerting 
5. Review your Disaster Recovery plans

Goal 1: Assess your SQL Servers

Whether you’re responsible for one SQL Server sitting in a server room next to you or hundreds of SQL Servers spread around the world, it can be difficult to keep up with the exact configuration of each SQL Server. This is especially true if you’re time is split. For example, when you’re a network administrator, web developer, or systems admin who is also tasked with taking care of the SQL Servers in your spare time.

Uncertainty about the patch level, configuration, and health of each or your SQL Servers creates stress and unease. Doubts creep in.

Do any of these internal dialogs sound familiar? 

• Are the SQL Servers behind on patching? Probably, I’m not sure, but they are working, right? (See Is There an Update for My SQL Server?)
• Are the SQL Servers configured optimally? Probably not. I’ve been meaning to do some research and check. But at least no one is complaining right now. And no new is good news? (See Is My SQL Server Configured Properly?)
• Are the databases healthy? I remember setting up some maintenance jobs a while back, I think. If they weren’t healthy, I’m pretty sure I’d know. 
• We pay a maintenance fee to the application vender. Does that include applying SQL Server updates? I’m not sure.
• Ok, I really should have a look, but ugh, when? 

Now is that time. The new year brings with it an opportunity to examine each of your production SQL Servers to see if they are configured optimally.

So what should you check?

Examine the log files, the configuration settings, the maintenance jobs, the performance DMVs, and patch level of each of your critical servers. Do you have the right number of tempdb files? Do you have any unneeded services running? Are there an excessive number of waits being reported? Are you still using the default values for MAXDOP and Cost Threshold for Parallelism? Etc?

Look for areas of concern, and there will likely be some, and prioritize resolving them. 

Not sure where to start? We can help – Getting Started with a SQL Server Assessment.

Goal 2: Update your SQL Servers 

Once you’ve assessed your SQL Servers, you know your starting point. You know the overall health of each instance. Next, make a plan to address or remediate the instances as needed. 

Start with the most important servers first and attack the Priority 1 issues as soon as you can. The P1 issues are those items that are of grave concern due to security and data integrity, recoverability, and availability. 

“As soon as you can” will mean different things to different organizations. Some environments allow minor changes and patches directly to production servers during off hours. For example, want to apply the latest CU? “Sure. Anytime after 7:00 PM Thursday will be fine.” 

Other businesses have a more standardized process in place. Make a remediation plan; confirm with application venders; present the plan to the Change Control Committee for review, deconflicting, and sequencing; apply the changes to a lower level environment; confirm with the QA team that the changes didn’t introduce ill effects; add the patch to the list for the next quarterly patching window, etc. 

Whatever your approach, get the process started. 

Goal 3: Start performing health checks

You’ve assessed and remediated your SQL Servers. Now, let’s ensure that the environment remains up to date and in good health. Make a plan to check on your SQL Servers regularly.

We recommend Daily Health Checks for your SQL Servers. (That’s what we do for our DBA as a Service customers.)

Create a checklist to review each day. Some things we like to check are: 

• Review the SQL Server and Windows log files for errors, unexpected restarts, excessive failed login attempts, and other warnings that could indicate potential issues.
• Check the history for each scheduled SQL Agent job to ensure none have failed. 
• Examine the size and growth of each data and log file to check for anomalies in growth. 
• Verify that each SQL Server is up to date on patches.

Goal 4: Implement monitoring and alerting 

Proactively checking the status of each of your SQL Servers is helpful. But there may be occasions in between the health checks when the SQL Server experiences difficulties. When that happens, it’s really nice to know that before your users and your boss becomes aware. 

It’s best to identify and resolve an issue before anyone else notices. However, the next best thing is to be able to answer a call with “Yeah, I know and I’m working on it,” rather than “Really? When did this start? Tell me the server again.” 

To get to that point, you’ll want to ensure that all SQL Servers are configured with Database Mail, and that standard alerts are created. We recommend creating alerts for all errors with a Severity level 16 or above, along with errors 823, 824, and 825. There may be other alerts you’ll want to create in your environment as well. 

Additionally you’ll want to ensure that all jobs are configured to notify you upon failure. Make sure to enable the Fail Safe Operator, too. You never know when msdb will have an issue.

Often there are other events inside of SQL Server that you’ll want to know about when they happen. Maybe it’s Disk I/O latencies? Or the occurrence of deadlocks? Or perhaps it’s an excessive number of recompiles? 

That’s when a more advanced monitoring solutions can help. We’ve used most of them in our customer environments and all add value over what you can do solely in SQL Server. Our preference is SentryOne’s SQLSentry. It’s well designed and very helpful.

Whichever you choose, install it, configure it, tune it, and then actually use it.

Too often, we see environments where a monitoring tool was purchased and even installed, but ignored because no one had the time to figure it out. There were too many warnings so the team began ignoring or disabling them. 

Goal 5: Review your Disaster Recovery plans 

Despite all of your efforts to create and keep a healthy system, bad things can still happen. 

Hardware can fail. Databases can corrupt. Users can delete data. Not to mention other issues like ransomware hitting your network, tornados hitting your data center, or any of the other things a year like 2020 can throw at us. (See Protect Your SQL Server from MrbMiner and Other Malware Attacks)

We live in a world where the ability to recover from the unexpected is, well, to be expected.

So, now is a great time to review your High Availability and Disaster Recovery plans. 

• Work with your business stakeholders to understand their expectations. What is their Recovery Time Objectives (RTO) and Recover Point Objectives (RPO)?
• Brainstorm ways to accomplish your objectives. Should you consider Failover Clustered Instances? Or maybe other HA/DR options? 
• Create a cadence to test your SQL Server backups. Restore selected database backups to a test system and run an integrity check on the restored database periodically. Schedule it on your calendar.
• Document your processes. Record the steps and all the information you’ll need, including contact names and numbers, that will be important should an event requiring a recovery become necessary. 
• Schedule DR tests. There is nothing more insightful than actually going the process over a weekend. It will reveal shortcomings and gaps in your plans or documentation. Refine your plans and test again a few months later.

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 Five Goals for Your SQL Servers in the New Year appeared first on The SERO Group.

Running DBCC CHECKDB

You’d be surprised at how many times in our SQL Server Assessments we discover that DBCC CHECKDB hasn’t been run on a critical database. That’s a problem.

Running DBCC CHECKDB checks the physical and logical database objects and will help to spot corruption before too much time passes. As with many things, early detection is important.

So, let’s start there. To perform an integrity check, run the following command in a query window.

DBCC CHECKDB(master); 

Depending on a number of factors, including the size of the database, this may take some time to complete, so you’ll want to do this during periods of lesser activity.

When I ran this on the master database of my test container, it took about a second to run and I received 421 lines of output in the messages window.

At the very bottom of the output, it tells me that the command finished successfully and that I should check the output for error messages. So, I review all 421 lines, looking for any unexpected output. Bigger databases with more objects will take longer to run and will have more output to review.

So, is there a way to see if DBCC CHECKDB completed with no errors without having to review all of the output?

When did DBCC CHECKDB last complete without errors?

Fortunately, DBCC CHECKDB will log each time it completes without finding any errors or corruption in the database. That’s called the Last Known Good date. Let’s look at three ways you determine the Last Known Good date. We’ll use a T-SQL query, a PowerShell command with dbatools, and the SQL Server Logs via Management Studio.

Finding the last known good date using T-SQL

From a query window in either SQL Server Management Studio or Azure Data Studio, run the following command. Replace ‘master’ with the database for which you’d like to find the Last Known Good date.

USE master; 
GO 

DBCC DBINFO() WITH TABLERESULTS;

I ran it on my test container for a SQL Server 2019 instance and received 94 lines of output. Approximately half-way down, at line 51, you’ll see a line where the third column (called Field in the output) shows dbi_dbccLastKnownGood. That’s what you’re looking for. The forth column for that row, called Value, shows the date that DBCC CHECKDB last completed successfully. That’s the DBCC CHECKDB Last Known Good date.

That’s not a heavy lift, but it still takes some effort to sift through the results.

Finding the last known good date using PowerShell and dbatools

If you’re a fan of PowerShell and dbatools, you can use the combination to find DBCC CHECKDB Last Known Good Date using the following command where localhost is the SQL Server instance, sa is the credential I’m using to connect to the instance, and master is the name of the database I want to run the DBCC CHECKDB command on.

Get-DbaLastGoodCheckDb -SqlInstance localhost -SqlCredential sa -Database master

The results are shown below. As you can see, the output shows some additional information about the database, including how many days it’s been since the Last Known Good.

By the way, I can omit the -Database parameter and find the Last Known Good date for all databases on the instance.

Get-DbaLastGoodCheckDb -SqlInstance localhost -SqlCredential sa | Format-Table 

I’ve formatted the output in table format for ease of reading.

Finding the last known good date using the SQL Server Logs

DBCC CHECKDB logs information into the SQL Server ERROR LOG files. You can view the logs using Management Studio. Drill down into instance, Management, SQL Server Logs, and right-click on the Current log as shown below.

You’ll see the following window where your search for the DBCC CHECKDB output.

What if DBCC CHECKDB has never been run?

But, what will the output show if it’s never been run on a database?

Using the Get-DbaLastGoodCheckDb dbatools command in PowerShell, the LastGoodCheckDb value will be blank if the DBCC CHECKDB has never been run on this database, as in the BaseballData in the following example.

Using T-SQL, the Value column will show the default value for a date that is NULL in SQL Server, 1900-01-01 00:00:00.000.

Of course if you find this to be the case, you should run DBCC CHECKDB as soon as you can. Again, it should be run during times of lesser activity since it takes some resources and time to complete.

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 When Was the Last Known Good DBCC CHECKDB Integrity Check? appeared first on The SERO Group.

When Microsoft SQL Server is installed, by default one SQL Server tempdb file is defined. For many systems that may be enough. But, over time, as the database sizes grow, as the number of users increases, and type of queries grow in complexity, one tempdb file may not be able to handle the load. It may become a source for contention.

How to find your tempdb data files

Checking the number of tempdb data files is straightforward. Here are three easy ways: one graphical, one T-SQL, and one PowerShell, so you can use your tools of choice.

List tempdb data files using database properties

Perhaps the most frequently used way to check the number of tempdb data files for a SQL Server is to view the Database Properties. This can be done using either SQL Server Management Studio (SSMS) or Azure Data Studio (ADS). I’m using ADS in images below.

Drill down into the SQL Server instance, Databases, System Databases, and right click on the tempdb database. Select Properties in the pop-up menu.

The Database Properties window will open. As you can see in the image below, the SQL Server 2019 container I downloaded is configured with four tempdb data files. That’s not bad, although the size and auto growth settings are concerning.

Of course, while you’re in the Properties window you can adjust the number, sizes, etc, of the data files. Your SQL Server should be restarted afterward.

List tempdb data files using T-SQL

As with most everything you can do using point-and-click in SSMS or ADS, the same can be accomplished using Transact-SQL. Sometimes, it’s just nice to have a library of commonly used scripts on hand so you can quickly, easily, and consistently run them.

In this case, the query below can be used to check the number of tempdb data files currently defined.

SELECT  file_id, 
        type_desc, 
        name, 
        physical_name, 
        [size],
        state_desc
FROM    tempdb.sys.database_files 
WHERE   type = 0 ; 

Here are the results. Of course, you can add additional output columns to see other properties as well, such as max_size, growth, and is_percent_growth.

List tempdb data files using PowerShell and dbatools

Experienced SQL Server DBAs often make extensive use of the dbatools PowerShell module. You get all the flexibility and capabilities of PowerShell combined with the ability to administer most every aspect of your SQL Server.

In the code below, I’m using the Get-DbaDbFile command. The command is fully documented here. I’m connecting to the localhost using the -SqlInstance parameter and authenticating as sa using the -SqlCredential parameter. I will be prompted for the password each time. The -Database parameter allows me to find the datafiles for a specific database. I’m then piping the output to table format for readability.

Get-DbaDbFile -SqlInstance localhost -SqlCredential sa -Database tempdb |Format-Table

Here’s the output from the Get-DbaDbFile command.

Want to know more about your SQL Server configuration?

Here are few other posts for SQL Server configuration settings and tempdb that may be helpful.

• Is My SQL Server Configured Properly?
• How Many tempdb Data Files Should My SQL Server Have?
• Why 9 Out of 10 SQL Servers Aren’t Configured with Best Practices

[EDIT Oct 5, 2021] – Also see How to Configure SQL Server tempdb? for other tempdb configuration settings that can affect performance.

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 3 Ways to Find Your SQL Server tempdb Data Files appeared first on The SERO Group.

You also need to be able to recover from an unexpected disaster quickly. Whether due to corruption, theft, or a natural disaster, you need to be able to recover the data and database systems quickly. (A process that should be clearly documented and periodically practiced.)

The last thing you want is for your business to grind to a halt while the IT team attempts to figure out what happened and how to respond. Your customers will be waiting while your employees are idled despite wanting to do their jobs. Running a database system without considering HADR is like walking a tightrope without a net.

The Cost of Unplanned Downtime

Unplanned downtime costs companies an average of $5,600 per minute according to a 2014 Gartner study. A more recent 2016 study from the Ponemon Institute put the figure at $8,850 per minute. That’s over a half million dollars an hour of lost revenue, decreased productivity, and incident response costs. Other studies suggest that many unplanned outages involved database servers. Ouch!

So, it goes without saying that good HADR is important, but it’s not a replacement for performing Daily Health Checks and actively monitoring the SQL Server to ensure their health. 

4 High Availability and Disaster Recovery Options in SQL Server

Although High Availability and Disaster Recovery is a much broader topic than the database servers, the following SQL Server options should be considered as part of the larger discussion.

1. SQL Backup and Restore

Database and log backups are the foundation of any HADR implementation. It’s the basic blocking and tackling of any database implementation. Every SQL Server should be backed up periodically in addition to any other HADR solutions you may have implemented.

We recommended using native SQL Server backups. Of course, to recover from a catastrophic failure, you’ll have to (re)create a new SQL Server system to restore the backups. Taking frequent snapshots of the virtual server can help with the system recovery but those are no substitute for true database backups.

Backing up is important. But it’s really the ability to restore that important. Periodically restore selected databases to another system and run integrity checks on those databases. Document the process so that in a true disaster recovery scenario, you’ll have a proven protocol.

2. Logshipping in SQL Server

Log shipping leverages the native SQL Server log backup processes and creates a more controlled and automated recovery story. By automatically sending transaction log backups to a secondary SQL Server instance, you’ll have a standby server available with as little as a few minutes of lost data. That’s good news.

Should a disaster strike, client applications and other systems will have to be adjusted to point to the new SQL Server instance. This typically requires manual intervention and will not be seamless for the end users. They’ll know that a failure has occurred, however, recovery times are typically faster and the recovery points more granular than with an ordinary backup approach.

3. Failover Clustered Instances (FCIs)

Failover Clustered Instances takes your HADR game up several levels. Leveraging Windows Server Failover Clusters (WSFC), a single instance of SQL Server can be installed across multiple WSFC nodes. Should one of the nodes experience a hardware or software failure, key services such as SQL Server, are automatically shifted to another node.

With FCIs, SQL Server appears to client applications as one instance running on one Windows Server. Since services are automatically shifted to another node during an unexpected failure or planned maintenance cycle, client applications are automatically redirected to the active node. They typically do not notice any disruption in service.

The FCI is online as long as its underlying WSFC cluster is in good quorum health. This instance level redundancy provides substantially reduced potential for noticeable downtime for clients.

4. Availability Groups (AGs)

With Always On Availability Groups, transaction logs are synchronized from the primary replica to one or more secondary replicas. Should the primary replica become unavailable, either due to a failure or scheduled maintenance, a secondary replica transitions to the primary role. Clients, which connect to a listener, are unaware of any changes to the actual location of the primary replica.

Availability Groups further decrease the likelihood of a noticeably disruptive event.

Looking for Additional HADR Information?

Of course, this is a high-level overview of some options for High Availability and Disaster Recovery options in SQL Server. There are many other factors to consider as well, including backup methodologies, cloud strategies, and virtualization techniques. You can even implement Distributed Availability Groups or Failover Clustered Instances across multiple subnets. These are topics for another post.

Additionally, you’ll need to fully understand the business requirements of your stakeholders for Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO). The approaches mentioned here obviously come with varying levels of RTO and RPO capabilities and with different licensing price points.

If you’re looking for additional information, check out Microsoft’s Business Continuity and Database Recovery on SQL Docs. Additionally Luke Campbell (@luke7621) has a series on Creating Failover Clustered Instances in Azure.

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 High Availability and Disaster Recovery in SQL Server appeared first on The SERO Group.