Hello Dojo,
(Dataminer 9.6 CU17 with MYSQL)
I had a customer that was having an issue with their alarm table being too large and they subsequently put a limit on this and now:
- The alarms table count was 341k and table size is small <300M so no issues with size
- However the alarm_property table was big ~10G and had a count of ~1.7M records.
The Dataminer Help gives the following information for the alarm_property table:
The properties (both general and custom) of the elements in an alarm state.
- Is there a reason why the alarm_property table would be so large compared to the alarms table?
- Is there a way to limit these alarm properties in the future?
Thank you for any insight into this table and the methods to remedy the situation!
Hey Ryan,
Alarm_property table gets populated based on the amount of properties that are linked to an element (either directly on the element/service, on the alarm, or as part of the viewtree,...).
For every alarmevent generated a list of these properties will be added to that event which will be written to the Alarm_property table, even if the property was empty at the time.
This means on a system where there are a number of properties defined on an element it is entirely possible for the alarm_property table to be much larger in number of rows. If these properties then have a large value then the size of the table can be huge.
In you case each alarmevent has on average 5-6 properties (which is fine), and the average size of your property is +-5.8 kb (which is on the larger end for a property).
For youe second question, the easiest way to ensure the Alarm_property table does not grow out of control is to correctly configure properties to not be included in alarm-filtering when there is no need for this. This can be done on the property with the following checkbox (disabled means it will not be saved to the database).
Do this for element/service and viewproperties.
The second way is to ensure the sanity of what is put into property-value so that they do not grow too large (we have seen systems in the past, were a script incorrectly appended the value of a property instead of replacing it).
Hey Miguel;
In MySQL every row in the Alarm_property table is linked to an AlarmID. When the cleaningthread happens to clean expired alarms to keep the alarms below the defined amount, it will also attempt to delete the properties that were associated to the alarms that are deleted.
However this is a seperate query and so it is possible for alarms to be deleted and the property delete to fail. These properties will then never be deleted which can cause a cascade effect of the table growing making subsequent deletes fail.
Brent, thanks for the explanaition. I have one more question:
We know the alarm entries are kept in the database for a fixed period of time (TTL) or until the total number of alarms reaches a predefined limit in MySQL.
However, are the entries in the alarm_property table automatically removed when the corresponding alarm is removed from the database?
If not, that could explain the huge number of entries in the alarm_properties table because the alarm entries would be removed regularly to meet the 300,000 maximum configured in MySQL while the entries in alarm_property table remain.
Please confirm what is the case.
Regards.