Get a FREE Health Check
Access awesome analytics on the health of your system.
Using 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.
The 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.
This 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.
This 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.
The 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.
This 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.
This 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.
WRITELOG 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.
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.