The longest time that any database in a SQL Server has gone without a successful differential or full backup.

Use the "Longest Time" metric values to determine if Service Level Objectives for backup frequency are being met, and use the historical values of these metrics to identify whether recent delays are a one-time problem or a recurring problem (for example, nightly backups aren't happening every Tuesday). If a metric value is higher than expected:

• Review the backup schedules for full backups to verify that they are correct and not disabled.
• Review the backup results to determine if any errors are causing backup failures to occur.

To limit the databases that are included in the metric results, you can exclude SQL Server databases from backup metrics.

The longest time that any database in a SQL Server has gone without a successful full backup. See Longest Time for a DB without a Successful DB Backup (Diff or Full) for recommendations.

The sum of all I/O activity for all database files. If this is high:

1. Examine the current physical structure of databases on the server to see if it is possible to reduce I/O load by redistributing the database files to distinct disks.
2. Examine queries and database design to determine if they can be tuned to reduce I/O.

The rate at which SQL Server finds the data blocks it needs in memory rather than having to read from disk for this instance. By itself, the buffer cache hit ratio is not very meaningful except for servers with undersized memory settings. Tuning queries and performing index optimization is the best way to increase buffer cache hit ratios. To see the current metrics for the buffer cache, run the following query:

select * from master..sysperfinfo where object_name like 'Buffer Manager'

The percentage of time when SQL Server looks for an execution plan in the procedure cache and finds it for this instance. If this is low, try to write more reusable code or consider increasing the size of the procedure cache. To see current metrics for the procedure cache, run the following query:

select * from master..sysperfinfo where object_name like '%Plan Cache%';

The amount of free space in TempDB. Spaced used in TempDB fluctuates based on the nature and volume of the SQL statements that are currently running.

If TempDB fills up and there is not enough disk space for it to autogrow (or it is not set to autogrow), the performance of all SQL statements will be affected as they wait for access to TempDB.

The amount of space in TempDB used by internal objects. Internal objects are created by SQL Server to process queries. For example, internal objects can be used for spooling operations, for sort space, or for hash tables. Queries that process large amounts of data can increase the space required for internal objects in TempDB.

The percentage of space allocated to the TempDB log file that is not currently being used.

The amount of space allocated to the TempDB log file that is currently free.

The amount of space in TempDB used by user objects. User objects are temporary objects explicitly created by users. They include temporary tables and indexes, temporary stored procedures, table variables, and cursors.

The amount of space in TempDB used by the version store. While a table row is being updated or deleted, the version store contains the committed version of that row. SELECT operations that need to access the row being updated or deleted are not blocked because they can read the row in the version store. When the transaction is committed, the row is removed from the version store.

Long-running or orphaned transactions can increase the size of the version store. A large version store can affect database performance because of the overhead of reading the large version store.