For example, you may have a series of consecutive jobs that run for 1 minute each, starting at 9am. It’s important for the first job to finish by 9:01, so the second one can begin, and so on. If the job runs for longer than expected, an alert is raised.

Important: You’ll need to edit the T-SQL with the job’s name and the expected start and finish hour and minute. In this query, the job is called ‘TestJob’, it starts at 17:00, and it should finish by 17:02.

Use this metric to track the amount of data waiting to be sent from the principal database to the mirror. This is also known as the send queue. For more details, see Database Mirroring Sessions (MSDN article).

Important setup information

Before you can start using this metric, you need to:

1. Run the following Microsoft procedure on the msdb database you’ll use in the custom metric:

   USE msdb;
   GO
   EXEC sp_dbmmonitoraddmonitoring;
   GO
   

   This sets up a SQL Agent job that periodically updates information about the mirrored databases on your server. For more information, see http://msdn.microsoft.com/en-us/library/ms403582.aspx.

2. Make sure the SQL Agent is configured and running on the server. Then you can retrieve information using the sp_dbmmonitorresults procedure.

With this metric installed, you’ll know from a single value what the current status of your mirroring system is. It can be used to check for changes in the environment, for example, if a mirror goes from synchronized to pending failover, or if the there’s an error situation that causes the server to disconnect.

Important setup information

Before you can start using this metric, you need to:

1. Run the following Microsoft procedure on the msdb database you’ll use in the custom metric:

   USE msdb;
   GO
   EXEC sp_dbmmonitoraddmonitoring;
   GO
   

   This sets up a SQL Agent job that periodically updates information about the mirrored databases on your server. For more information, see http://msdn.microsoft.com/en-us/library/ms403582.aspx.

2. Make sure the SQL Agent is configured and running on the server. Then you can retrieve information using the sp_dbmmonitorresults procedure.

The metric returns the current role of a given database within your mirroring set up. The single value returned tells you whether the database is the principal or the mirror, which is important information if you always want one server to act as the principal.

Important setup information

Before you can start using this metric, you need to:

1. Run the following Microsoft procedure on the msdb database you’ll use in the custom metric:

   USE msdb;
   GO
   EXEC sp_dbmmonitoraddmonitoring;
   GO
   

   This sets up a SQL Agent job that periodically updates information about the mirrored databases on your server. For more information, see http://msdn.microsoft.com/en-us/library/ms403582.aspx.

2. Make sure the SQL Agent is configured and running on the server. Then you can retrieve information using the sp_dbmmonitorresults procedure.

It’s best practice to set up a witness that manages connections to your mirrored databases. The witness is a SQL Server instance that ensures you maintain uptime, so knowing if it is offline can be as important as knowing if your mirrored databases are available. This metric returns a single value that tells you whether the witness is connected, disconnected or unknown. For more details about witness servers, see Database Mirroring Witness (Microsoft TechNet article).

Important setup information

Before you can start using this metric, you need to:

1. Run the following Microsoft procedure on the msdb database you’ll use in the custom metric:

   USE msdb;
   GO
   EXEC sp_dbmmonitoraddmonitoring;
   GO
   

   This sets up a SQL Agent job that periodically updates information about the mirrored databases on your server. For more information, see http://msdn.microsoft.com/en-us/library/ms403582.aspx.

2. Make sure the SQL Agent is configured and running on the server. Then you can retrieve information using the sp_dbmmonitorresults procedure.

This metric returns the longest running instance of the named job in the last hour. In the example, the job of interest is called ‘My_long_running_job’, so you’ll need to replace this with the job in your environment that you want to target.

By creating multiple custom metrics from this example – one for each job you’re interested in – you can specify alert thresholds for each job individually. Alert thresholds are absolute rather than relative values, which may help cover a few scenarios that the built-in alert is not suited for.

With appropriate thresholds set on the associated alert, you will be notified when the number of available steps gets too low.

For more information, see Using sys.dm_os_ring_buffers To Diagnose Memory Issues in SQL Server.

You may also be interested in installing a metric that shows when virtual memory is low. See Low virtual memory.

If indexes are being updated with new data more often than they are being used in query plans, they can cause performance issues during write-heavy operations (INSERT, UPDATE, and DELETE statements), while adding little or no benefit to read operations.

For more information, see General Index Design Guidelines.