Top things you need in a SQL Server performance monitoring tool (from deadlocks ...

The initial article, Top things you need in a SQL Server performance monitoring tool (from performance metrics to wait statistic and query performance monitoring) covers the most important “things” that any DBA expects to find in an SQL Server performance monitoring application and how those are covered in ApexSQL Monitor. This sequel will cover another set of critical and essential information that any successful SQL Server performance monitoring tool should be able to monitor and present in a manner that is easy to understand and interpret, and how those are covered inApexSQL Monitor

So, besides the features described in the previous article, the following set of features that are equally important with the ones previously described will be covered:

SQL Deadlocks detection Baselining Alerting Index monitoring and maintenance Deadlocks

SQL deadlocks are always a bad thing when they occur in SQL Server. Deadlocks are a specific type of blocking where two or more processes block each other, and they cannot continue with the execution until SQL Server steps in and decide to kill the processes until it ensures that the situation where resolved. The processes that are killed while resolving the deadlock by SQL Server are “victims” in proper SQL Server terminology.

Regarding SQL Server performance, a deadlock is a substantial operation for SQL Server as it requires some time and extensive processing first to detect a situation where deadlock occurred, then to process the queries involved and decide which one should be terminated, or in which order if three or more queries are involved in a deadlock, to roll back all changes made by the queries that were chosen to be the victims, and if possible to perform the victimized operation again. Besides that, the consequence of SQL deadlocks is that the end user was left in a situation that his actions didn’t give any results as processes that were chosen as victims couldn’t complete the work that they intended to complete.

And if the application design or design of the database has some issues that caused the deadlock at the first place, it is highly likely that the deadlock could occur again when the operations that are the victims of the deadlock are restarted, which can end up in a situation that certain operations couldn’t be completed at all

Therefore, the awareness of the deadlock situation and its analysis are crucial and should be treated as a high priority

As for ApexSQL Monitor, all of its performance metrics are highly configurable, and each metric allows for specifying what alert actions should be executed automatically when a critical value is reached. By using the built-in deadlock per second metric, it is possible to monitor the number and frequency of the deadlocks that occur on the monitored SQL Server and to be alerted when that occurs. But for providing detailed information about the deadlocks that occurred on the monitored SQL Server a built-in alert action profile is designed to capture and store details of each and every deadlock when the deadlock alert is triggered. More details on how to correctly configure and use this ApexSQL monitor feature are available in the SQL Server deadlock notifications Part 2 solution center article, but as quick info, the information about the deadlock is saved as a standard SQL Server .xld file and can be previewed in a graphical form

Image may be NSFW.
Clik here to view.

or in the even more detailed textual form using the Microsoft XML Notepad

Image may be NSFW.
Clik here to view.
Baselining

Another feature irreplaceable in any advanced SQL Server performance monitoring and issue analysis process is the ability of the performance monitoring application to calculate the baseline for collected performance data based on its historical values. There are some significant advantages that baselining of SQL Server performance data provides for in many situations over the standard method of predefining alert threshold values when monitoring SQL Server performance. Moreover, monitoring of some fundamental wait types cannot be even done in a proper way without baselining, as it is the only way that allows correct interpretation of collected performance data. Unfortunately, baselining is a complicated job, and even though it can be performed manually, it requires serious experience from a DBA and a significant effort has to be made in order to create it as a sustainable method.

For those who are interested in the baselining basics and how that can be done manually, there is a series of useful articles on that subject that can serve as a good start

How to detect SQL Server performance issues using baselines Part 1 Introduction How to detect SQL Server performance issues using baselines Part 2 Collecting metrics and reporting

For those who prefer an easier, and more reliable and sustainable baselining ability, baseline-based analysis of performance metrics and alerting can opt for an application such as ApexSQL Monitor. ApexSQL Monitor has built-in ability to calculate a baseline for all SQL Server performance metrics which also includes calculating baselines for wait statistic data per monitored wait type. This solution also considers the ability to calculate standard deviations used as a basis for alerts thresholds calculation. For accurate calculation of standard deviations, ApexSQL Monitor uses the highly sophisticated Welford’s calculation method. On top of that, ApexSQL Monitor can convey the calculated baseline values and thresholds graphically in ApexSQL Monitor charts directly

Image may be NSFW.
Clik here to view.

To learn more about how to properly use and interpret the baseline in performance monitoring can read the following articles:

How to detect SQL Server performance issues using baselines Part 3 How to master SQL Server performance baselining to avoid false positives and/or missing alerts

Besides the ability to calculate the baseline, ApexSQL Monitor has the ability to fine tune already calculated baselines. The application even allows calculating baselines using historical data for a considerable period of times (limited only with the applied data retention policy), there might still be a need for manually smoothing out data spikes, various statistical outliers, and incongruities that might cause the inaccurate perception of historical data and thus inaccurate alerting.

T