5 Reasons to Perform a Database Health Check

At Koderly, we offer businesses a database health check, which is a comprehensive review of your SQL Server environment. It’s a popular service amongst those customers who recognise the benefits that this database health check can bring, such as improving critical application performance and ensuring the security and availability of their data.

Here are five reasons why you should consider a database health check for your environment.

5 Reasons to Consider a Database Health Check

Image shows an hourglass with a magnifying glass in the centre.

1. Query Tuning

Hardware is expensive, especially in the cloud, and at Koderly we strongly believe in tuning the workload (i.e. the queries), before spending money on the latest hardware. SQL Server performance tuning should always start with the queries themselves as you need to get the most out of your not-inconsiderable investment in SQL Server.

Our database health check will take a deep-dive into your environment’s most expensive queries. It will identify the queries that are using the most server resources and suggest changes that will both speed up those queries and reduce the overall workload. We’ll empower you with information to take back to your application vendor which if acted on, could further improve application performance.

5 Reasons to Perform a Database Health Check. Image shows a database with a gear come out of the top centre. To the right hand side of the database, there is a green circle with a checkmark in the centre.

2. Optimal Configuration

When your business-critical application was first installed, did anyone take the time to tune your SQL Server instance so it was optimised for your workload? At Koderly, we’ve spent a lot of time tuning SQL Server instances over the years, and 95% of the time that answer is a firm “No”.

SQL Server has an array of configuration options which, when set correctly, can deliver a significant performance improvement, both for individual queries and the entire workload.

It’s very rare that SQL Server’s ‘out of the box’ default settings are appropriate for your environment. Probably the most common setting we see is “Cost Threshold for Parallelism” being set to the default of 5. You may not realise, but this value came from a server in a Microsoft lab from the 1990’s. It makes no sense for modern and is likely hurting the overall throughput on your server.

5 Reasons to Perform a Database Health Check. Image shown a database with a blue shield covering half of the right hand side. There is a locked padlock in the centre of the shield.

3. Data Security

We all know data security is important. A lack of it can destroy a business. Our database health check will report on how secure your SQL Server environment is and make recommendations for improvements.

We’ll consider both access to the server (at the network level) and the security of the data itself. We’ll report on what additional security options are available to you to further improve the security of your data (I’ve previously blogged about a few of them here).

5 Reasons to Perform a Database Health Check. Image shows a gear in the centre of a heptagon. At each point on the heptagon, there is a green hollow circle.

4. Capacity Planning

You’re part of a successful business, and your data is growing. So are your users and customers. Those users are doing more and more, running intense processes, and executing complex reports against your databases that are hammering your SQL Server. Your applications are slowing down as a result.

Capacity planning is concerned with how well your SQL Server environment will cope with these changes in the future. Our database health check will seek to understand your workload and tell you how hard your database server is working today, so you can be pro-active, not re-active, and take action now before it causes problems for your users and applications.

5 Reasons to Perform a Database Health Check. Image shows the top of a database that is being worked on. Underneath, there is a spanner and screwdriver in the centre. Covering the right hald of the image there is a clock and an arrow going anticlockwise.

5. Disaster Recovery (DR)

If your SQL Server suffered a serious failure, how much data would you lose? How long would it take you to recover? A key reason to have a database health check is to answer these two critical questions.

DR isn’t just about having backups, it’s about being ready to implement a backup and recovery strategy that works for your business. We will review your current DR strategy, establish your current Recovery Point Objective (RPO) and Recovery Time Objective (RTO), and then show you how to get to your desired RPO and RTO.

I hope you found this information useful. If you’re interested in learning more about Koderly’s SQL Server Health Check, or our other database services, then please contact us!

Thanks for reading!

Subscribe to our newsletter to be the first to hear about new features, vacancies, and industry news.

Picture of Shaun Austin

Shaun Austin

Shaun has been working with SQL Server for over 20 years, as both a developer and DBA. He is passionate about optimising and troubleshooting SQL Server environments, ensuring that customers get the maximum value from their cloud or on-premise infrastructure. Shaun regularly blogs about SQL Server administration and performance tuning, frequently contributing to user group channels on platforms such as LinkedIn.