Deadlocks can significantly reduce the performance of the applications and the response time for the users. This is usually reflecting a blocking situation which can last a long time. It is therefore very important to detect deadlocks and act rapidly to resolve them if necessary.
Surveillance table:
Max dead locks:
This monitor will look for deadlocks that occurred since the last check. It will cope with server restart up to a period of 2 hours of down time.
| Parameter | Description |
|---|---|
| Active | If checked, the rule is enabled and will be processed |
| Max dead locks | The threshold for the maximum number of deadlocks. You must use the multi-threshold syntax (G2W:1 W2M:5 etc…) |
| Auto clear | If set, the generated alarms will be automatically cleared from the console if the alarm condition is not fulfilled anymore |
| Alarm tag | This field allows to add custom text within the alarm message. %MSG% variable will contain the actual generated message and can be used such as: “my_prefix %MSG% my_suffix”. By default, tag will be used as prefix. |
| Alarm | Defines if the alerting is active for this rule. |
| Metric | Defines if the metric generation is active for this rule. |
| Report | If checked, this rule will be used for showing threshold and severity in the daily report |
| Active | Max messages | Auto clear | Alarm tag | Alarm | Metric | Report |
|---|---|---|---|---|---|---|
| true | G2M:1 | false | true | true | false |
Effect : A MAJOR alarm is sent if a deadlock is found since the last check