Hello Dojo,
We are planning to move an element in a DMS with a clustered database (CassandraCluster + Elasticsearch) via the following procedure:
- Export an element to a .dmimport package.
- Delete the original element.
- Import the .dmimport package to the target DMA.
I’m not sure about the behavior when an element is deleted: is its trend and alarm data deleted from Cassandra and Elastic?
If the data is deleted, this means we need to include trend and alarm data in the DELT package, which may not be possible if the element has a very large alarm and trend history.
If the data is left in the database until the TTL expires, will re-importing an element with alarm and trend history cause duplication of alarms or issues with trend data written twice into the database?
Hi Alexander,
When an element is deleted, ElementData, LoggertableData, Spectrum data, latchstates and Alarms are deleted. Trending and other data rely on the Time To Live to expire.
However this is not a problem for the flow you described. During the import step, the Primary key for this data will be the same, thus overwriting the existing record. The only quirk you may encounter is that trenddata is longer available than expected (I.e. 1 months since the import, rather than 1 month since the creation of the value).
Kind regards,
I performed a test (lab setup running DataMiner version 10.5.11):
- Alarms are deleted when an element is deleted. If alarms were not included in the DELT package, they are lost.
- Trending data stays in Cassandra cluster when an element is deleted. If trending data was not included in the DELT package, trending remains accessible after re-importing the same element.
- If trending data is included in the package, re-importing the element results in duplicate trend datapoints (checked with Query Executer in System Center), because the “tu” field (uuid) is different for each datapoint. That doesn’t seem to have any impact on trend display or on the data retrieved by Trend Data Inspector.