SQL Server Health Checks: 10 Issues That Show Up Again and Again

If you’re responsible for a SQL Server environment, you already know the stakes: performance, availability, recoverability, and security. But what you don’t know—until something goes wrong—can cost you dearly. That’s why regular SQL Server Health Checks matter. Here are the most common problems we uncover—and why they need attention before they cause trouble.

Top 10 SQL Server Health Check Issues—and Why They Matter

1. Windows Power Plan Set Incorrectly

SQL Server can be resource-intensive—and yet, many servers are configured to run on the “Balanced” power plan instead of “High Performance.” This can limit CPU availability and throttle performance, especially under load. It’s a simple setting, but one that can have an outsized impact. Read more about checking the power plan setting.

2. SQL Server Can’t Use All Processors

SQL Server 2016 Standard Edition and later supports the lesser of 4 sockets or 24 cores. The key word there is “lesser.” Let’s look at an example.

Let’s say that you’ve licensed SQL Server Standard Edition for 16 cores. But those cores are presented to the VM as 8 sockets, each with 2 cores. Unfortunately, SQL Server Standard will only be able to use 8 cores. Why? Because it can only access cores on 4 sockets. 4 sockets times 2 cores per socket is 8 cores total.

This means that you aren’t leveraging all of the cores that you’ve licensed.

3. Too Few or Too Many TempDB Data Files

Microsoft recommends starting with one TempDB data file per logical processor, up to eight, to reduce contention on allocation structures. However, we find that many environments are configured to use either too few (often just one, leading to PFS, GAM, or SGAM contention) or too many (which can introduce unnecessary overhead and make monitoring more complex).

Misconfigured TempDB can degrade the performance of operations like sorts, joins, temporary tables, and version store activity. Read more about configuring your SQL Server tempdb files.

4. Jobs Without Failure Notifications

SQL Agent jobs that silently fail can be costly accidents waiting to happen. From backups and index maintenance to ETL workflows, you need to know when jobs fail. Yet we routinely find environments with no alerts configured. If no one’s watching, critical failures can go unnoticed for days or weeks.

We’ve received quite a few calls from soon-to-be clients where a restore from a backup is needed, yet none is available because the backup job hadn’t successfully completed in more than 6 months. Or the integrity check jobs failed with errors, but no one noticed.

5. Missing Patches or Updates

Out-of-date SQL Server instances are not only a security risk but also more likely to suffer from performance issues and instability. We often find unpatched servers that haven’t been updated in months—or even years—leaving them vulnerable to known issues with known fixes.

Learn more: Is There an Update for My SQL Server?

6. Missing Maintenance Jobs

SQL Server uses statistics to help determine the most efficient way to execute queries. When statistics are accurate, SQL Server can create effective query plans, leading to better overall performance. Conversely, outdated or inaccurate statistics can result in poor query plans and inefficient query execution.

SQL Server automatically updates statistics by default, which is OK in many cases. However, there are plenty of scenarios where relying solely on automatic updates may not be ideal. In such cases, setting up a scheduled job to manually update statistics can help maintain optimal performance.

Similarly, we find that integrity checks are not scheduled to occur regularly. That can lead to undetected database corruption. To learn more, see 10. Missing DBCC CHECKDB (Integrity Checks).

7. Default Settings That Hurt Performance or Recovery

SQL Server has several settings that can affect performance—MAXDOP, Cost Threshold for Parallelism, max memory, min memory, etc. Prior to SQL Server 2022, these were almost always suboptimal for most workloads. SQL Server 2022 does a better job at defaults, but the settings should be tuned for your workload.

Although there is no “go faster” knob in SQL Server, adjusting these defaults can bring improved performance.

8. Backup Plans That Don’t Support Requirements

One of the most important responsibilities in managing SQL Server is ensuring the integrity and reliability of database backups. SQL Server’s native backups provide powerful tools for protecting your data, especially for databases using the full recovery model. However, combining native SQL Server backups with disk or VM snapshots can cause problems during a restore. So be careful mixing your backup approaches. Read more about these problems.

We also regularly find backups that are saved to the same drive as the database, that don’t support the organization’s Recovery Point Objectives (RPOs), and that haven’t been tested. Learn more about SQL Server backups.

9. Misalignment with RTO/RPO Requirements

Stakeholders might say, “We can’t afford more than 15 minutes of downtime,” but the database configuration tells a different story. In our SQL Server Health Checks, we frequently find gaps between what the business expects (Recovery Time and Recovery Point Objectives) and what the current setup can realistically deliver. That gap needs to be closed.

You have a choice. You can adjust SQL Server to support the stated RTOs and RPOs, or you can realign stakeholder expectations.

10. Missing DBCC CHECKDB (Integrity Checks)

Without database integrity checks, corruption can silently lurk in your database, remaining undetected for weeks, months, or even longer. That’s bad. Backing up a database doesn’t magically get rid of corruption. The corruption is backed up, too. To learn more, see When Was the Last Known Good DBCC CHECKDB Integrity Check?

Stay Ahead with a SQL Server Health Check

If you haven’t reviewed your SQL Server environment recently, now is the time. These common issues don’t announce themselves—they quietly erode performance, recoverability, and reliability until something breaks. Don’t wait for that moment. Schedule a no-obligation discovery call to learn more about our SQL Server Health Check. Take control of your database environment before it controls you!

Dive Deeper: Further Reading and Next Steps

• 📋 Do I Still Need a SQL Server Health Check?
  Learn when and why Health Checks are essential—even if your SQL Server seems to be running fine.
• 🚨 The Impact of SQL Server Downtime (and How to Prevent It)
  Explore the real costs of downtime and what steps you can take to keep your environment resilient.
• 🛠️ Our SQL Server Health Check Services
  See how our structured assessments uncover hidden risks and help you align performance with business needs.
• 🎥 Recorded Webinar: RTO/RPO Considerations for Your SQL Server
  Understand how Recovery Time and Recovery Point Objectives affect your backup and disaster recovery strategy.
• 🔐 Free SQL Server Security Self-Assessment
  Quickly evaluate your environment’s security posture and receive bonus guidance on preventing ransomware attacks.
• 🔎 Public SQL Health Check Priorities (sp_Blitz)
  A community-ranked list of common SQL Server issues, created by Brent Ozar and maintained as part of his open-source tools.