path-to-cloud3.svg

Get a FREE Health Check

Access awesome analytics on the health of your system.

Try Spotlight Cloud Pro
Compare Plans & Pricing
health-check-hero.png

The Spotlight Health Check provides a prioritized list of key health issues enabling you to pinpoint and address them within your SQL Server infrastructure.

  • Implement healthchecks for Security, Disaster Recovery, Index Optimization, Memory, I/O, and Configuration.
  • And we’re adding new healthchecks all the time!
  • Get insight into the performance of each of your instances, including recent history of the instance’s performance, system waits and I/O latency.
  • See how your performance is trending over time and compare one instance with another. Using aggregated statistics from the entire Spotlight community you can compare how your instances perform.
  • Spotlight Health checks are available to all Spotlight Enterprise users.
healthcheck.png

 

Health Checks currently available

Security


Guest User Access

Guest User Health CheckUsing this check you can identify whether the user Guest has access to any databases they should not have access to.

Because any login can access the database through the guest user, access via the guest user should be disabled for user databases.

 

Login Password Policy

Password Policy Health CheckThe intent of this health check is to identify logins that have a password policy vulnerability. 

By analyzing SQL logins we can determine if any are not following best practice policy. If either the password policy is not checked, or there is no expiration for the password (or both) these logins are listed by name, so you can identify them and take action.

 

Disaster Recovery


Simple Recovery Model

Simple Recovery ModelThis health check identifies the databases that have a recovery model that potentially exposes them to data loss.

For a recovery without any data loss to be possible, the recovery model of the database must be either Full or Bulk Logged. If the recovery model of the database is Simple, the transactions since the last backup are lost.

 

Database Backups

Database BackupsThis check identifies databases that are exposed to the risk of data loss, due to absent backups.

It also provides a list of steps that can be taken to resolve the issue.

 

Index Optimization


Missing Indexes

Missing Indexes Health CheckThe purpose of this check is to alert the user to the presence of missing indexes, the relative impact their creation may yield and the SQL required to create them.

SQL Server maintains a list of the indexes it considers to be missing from each database. The indexes are ranked based on the relative improvement they would yield if they existed.

 

Memory


Physical Memory Pressure

Memory Pressure Health CheckThis health check identifies if a server is experiencing physical memory pressure.

It compares the total physical memory that is available with the physical memory consumed by all processes. It then breaks down the total amount consumed to show you the proportion consumed by a particular SQL Server Instance over a 24 hour period. All this provides a complete snapshot of physical memory pressure on your system.

 

Ad-hoc Workload

Adhoc Workload Health CheckThis check calculates the amount of memory in megabytes in the total cache consumed by ad-hoc plans over a 24 hour period. It also examines the relationship between ad-hoc plans, the plan cache and the total cache. If the percentage of the plan cache consumed by ad-hoc plans exceeds 10% it means the plan cache is too full of ad-hoc plans.

 

I/O


Writelog Wait

Writelog Healt CheckWRITELOG wait represents the time spent waiting on a LOG I/O to complete. Operations that commonly cause log flushes are checkpoints and transaction commits.

We check if your WRITELOG Wait-time is too high a proportion of total wait time. If it is too high this may indicate a bottleneck on your SQL Server instance.

 

Configuration


Compatibility Level

Compatibility Level Health Check It’s now possible to review databases with a non default compatibility level and decide if they should be changed to the default compatibility level.

There may be a good reason to have these databases set to a non-default compatibilitiy level. Application compatibility is obviously a primary reason.