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...

This metric counts the number of principals who are members of the sysadmin fixed server role. SQL Server relies on role-based security to manage permissions. If multiple IT system administrators have permissions to set up new SQL Server logins, they might be inclined to do so as part of the sysadmin role. Adding a normal user to the sysadmin role could pose a security risk and is not recommended unless the principal is highly trusted.  Read more...

Data pages read from disk are placed in the buffer pool with the intention that they will be reused, and accessing them from RAM is faster than from disk. Knowing how much of your RAM is committed to each database can help you provision the right amount of RAM to SQL Server, and also to identify rogue queries that draw too much data into RAM and force data from other databases out of the cache.  Read more...

This metric collects the total amount of memory, in kilobytes, used by the plan cache of an instance to help identify memory pressure or plan cache pollution. It is similar to the SQL Server: memory manager: SQL cache memory counter, but instead of providing the number of 8-kilobyte pages that make up the plan cache, it provides the total memory used.  Read more...

This metric measures the percentage of free space for transaction log files (LDF files). You’ll find this useful if your SQL Server has limited capacity, so you need to maximize existing disk space utilization by minimizing unused space. It will also alert you if the amount of free space drops below the specified thresholds.  Read more...

If the transaction log autogrows rapidly, it can suggest that log backups are not being carried out frequently enough, or another resource may be preventing the log from truncating. This metric measures the number of transaction log files that are greater than 10 GB. The associated alert is raised when the number of files exceeds a specified threshold.  Read more...

A foreign key points to a primary key that must exist in another table, for example, column X in Table 1 must also be present in Table 2. The key protects this link, and only valid data can be inserted in the foreign key column. An untrusted foreign key may threaten a database’s referential and data integrity.  Read more...

This metric returns the number of ‘login failed’ error messages found in the SQL Server error log file in the last hour.  Read more...

This metric measures the amount of memory used in the buffer cache by the largest object (based on the number of pages). It checks the sys.dm_os_buffer_descriptors to identify the object, and returns the relative percentage used. You should use this metric if you want to monitor what is in the buffer area, or if you are having performance-related disk read problems.  Read more...

This metric returns the number of check constraints that have their is_not_trusted flag set to 1 in the sys.check_constraints table. Untrusted constraints force SQL Server to construct less efficient query plans, because it doesn’t know enough about the kind of data contained in the table. This can point to a data integrity issue which should be investigated.  Read more...

This metric for Red Gate SQL Monitor measures the number of database autogrowth events (data file or log file) in the last hour. Too many autogrowth events causes disk fragmentation which requires a change in the autogrowth settings of a database.  Read more...

This metric reports the number of connections that are currently blocked, divided by the total count of current connections. Most well-balanced SQL Servers will have some degree of blocking. This metric attempts to measure the impact of lead blocking queries against other queries. Higher values indicate that many connections are being blocked, and queries should be tuned to reduce the amount of contention.  Read more...

This custom metric adds Brent Ozar's popular SP_Blitz scripts to Red Gate SQL Monitor. It looks for configuration, security, health and performance problems, and reports back with a list of issues for you to look into. It’s great for quickly understanding the state of a server you've been asked to look after.  Read more...

This SQL Monitor custom metric tells you if a specific SQL Server Agent job that runs at the same time every day has overrun. The metric is useful when a job can have negative effects on other processes if it overruns.  Read more...

SQL Monitor’s Job duration unusual alert is a powerful tool for keeping track of most jobs in your SQL Server environment. It works by comparing the running time of any job instance against the median for that job, and identifying when a variation in the job duration could hint at a performance problem. However, if your environment contains big jobs whose durations vary by several orders of magnitudes, it can be tricky to specify what kind of variation is expected and what would be unusual. For these cases, it is possible to go beyond the functionality of the built-in alert with a custom metric.  Read more...

You can extend SQL Monitor to track whatever you need to watch on your own system with custom metrics. Grant Fritchey shows us how.  Read more...