User Guide

There are several reasons for data loss during a scheduled purge:
•
Retention Settings on Loggers
Data inconsistencies and permanent data loss can occur if the number of days to retain the
data differs on the Loggers.
Assume that LoggerA is set to retain 7 days' worth of data, while LoggerB is set to retain 15
days worth of data.
If LoggerB is down for 6 days, a temporary data discrepancy exists when it is brought back
up, until the Recovery process synchronized the data from Logger A. However, if Logger B
is down for 10 days, when it comes back up, it can synchronize only the last 7 days worth
of data, based on LoggerA's retention setting. Three days are lost permanently from LoggerB.
Note that the data might be lost from the system permanently, if the historical data was copied
to the HDS database associated with LoggerA. Although this appears as a discrepancy in the
reports that are run from HDS servers that connect to side B, the system is functioning in a
predictable manner. This can be considered as an issue of perception.
To avoid this situation, make sure that the retention settings are the same on both Loggers
are the same.
•
Scheduled Purge and Peripheral Gateway Failure
If multiple Peripheral Gateways (PGs) are configured, and if one of the PG goes down for a
brief period, then it is possible to lose historical data permanently.
Assume that there are three Peripheral Gateways (PGs) in the system and that one goes down
for a day and then comes back online. When that PG comes back online, it sends historical
data for activity that occurred prior to it going offline.
If the scheduled purge mechanism activates and determines that the oldest one hour of data
needs to be purged, it is possible that the purge will delete data that was sent by the PG after
it came online but before it was replicated to the HDS.
Permanent data loss can occur the HDS is down and the scheduled purge on the Logger
deletes data that has not yet been replicated to the HDS.
Emergency Purge
The emergency purge mechanism is triggered when the Logger Central Database becomes full
or reaches a configured threshold size. Its objective is to free up space by purging data from the
historical tables so that the database has more free space than the allowed minimum.
The emergency purge goes through each historical table in a predefined order one at a time and
purges one hour's worth of data from the table. As data is purged from each historical table, a
check is made to verify if the free space is more than the minimum threshold value. Once
adequate space has been recovered, the emergency purge procedure stops. Otherwise, it continues
through to the next historical table and keeps looping as necessary.
Reporting Guide for Cisco Unified ICM Enterprise & Hosted Release 7.2(1)
147
Chapter 10: Reporting Implications of Data Loss and Component Failover
Preventing Data Loss from Logger and HDS Failure