If your code uses temporary tables, variable tables or dynamic cursors, this metric can help identify whether you have contention on tempdb allocation. Tempdb is shared by all databases and is used for many operations in a SQL Server instance, so it is common for tempdb to cause performance problems.  Read more...

This metric can help if you want to monitor the number of indexes per database that haven't been used for the last month. Indexes that aren't in use should be removed because they can degrade INSERT, UPDATE and DELETE performance, and they use storage space.  Read more...

This is a general indicator of performance problems. Index fragmentation can affect the rate of return for moderate to large tables. If this value indicates an increased amount of index fragmentation throughout your database, you may need to fine-tune your indexes by redesigning, or rebuilding more frequently.  Read more...

If your application relies on identity columns, this metric is a useful measure of the number of identity columns that are near to the limit per database. You can then avoid logical problems in your application and SQL Server errors.  Read more...

This metric picks up excessive counts of Virtual Log Files (VLF) in a transaction log that can lead to performance problems, including write performance, restore and recovery times. The ideal value for this metric should be less than 25; excessively high values (greater than 50) can cause high write times when writing to the transaction log.  Read more...

When a table has multiple indexes defined on the same columns, it produces duplicate indexes that waste space and have a negative impact on performance. This metric measures the number of possible duplicate indexes per database above a set threshold. You can then consider dropping the indexes and reverse the change.  Read more...

This metric is a great general indicator of performance problems. High stall times indicate I/O problems, which can be attributed to busy physical disks or queries that return large data sets to the client.  Read more...

Trying to determine if you have pressure in your buffer allocations can be difficult. This metric reliably indicates if you have a buffer problem using the memory dump from DBCC MEMORYSTATUS() and comparing Target Committed to the Current Committed allocations. If you hit negative numbers you are looking at a buffer issue.  Read more...

Backups are at the heart of the activities of any DBA. You have to restore the backup to know it is good, but you can get an early alert that something is wrong if your backup size changes rapidly or unexpectedly in a short period of time.  Read more...

If your log restores aren't happening when they’re meant to, you want to know about it. You’ll be relying on restoring from logs should anything happen to your databases, and if you can’t restore to a certain point in time, you risk losing valuable data.  Read more...

The number of out of memory errors that have occurred within a rolling five minute window. If you just want to keep an eye out for any memory errors, you can watch the ring buffers for the Out of memory errors alert when it gets registered there.  Read more...

This metric creates an alert that will be raised when something is added to the schema, or the existing schema is modified.  Read more...

During a transaction, data is written to the log cache so that it’s ready to be written to the log file on commit, or can be rolled back if necessary. When the log cache is being flushed to disk, the SQL Server session will wait on the WriteLog wait type. If this happens all the time, it may suggest disk bottlenecks where the transaction log is stored.  Read more...

This metric measures the amount of memory used by the total number of ad hoc queries in the plan cache that have only run one time. This value is only accurate for the instant the query is run, and the value can change radically from one capture time to the next.  Read more...

This metric measures the total number of ad hoc queries in the plan cache that have only run one time. The value is only accurate for the instant the query is run, and the value can change radically from one capture time to the next.  Read more...

This metric is useful if you want to know exactly how much physical space a particular table is taking up, including the size of its indexes. If a database is growing quickly within a short time and you suspect a certain table is responsible, you can monitor its actual size, or the rate at which it is increasing.  Read more...

This metric monitors whether a server principal’s default database is offline. When you create a SQL Server server principal (formerly referred to as a server login) it has a default database setting that is used to assist in a connection request when no database is specified.  Read more...

If you manage a server where you are not in complete control of the creation of databases, or you’re unfamiliar with what settings to change, you may miss things out or set them incorrectly. This metric could pick up on issues that affect performance in obscure ways, and saves you having to search for them when a system suddenly stops performing as you would expect.  Read more...

Using a default account for SQL Server services can be a security risk for two reasons. Firstly, it can give the service a higher level of permissions than it needs. Secondly, isolation is compromised by several services running under the same account. This metric checks whether SQL Server services are running under any of the default accounts, such as localsystem.  Read more...

This metric checks whether your SQL Server installation is using the default TCP port. It’s widely known that SQL Server 2005 and 2008 listen on TCP port 1433. Keeping this default gives hackers a potential way of attacking your server.  Read more...