User Guide

While this recovery process is going on, the reporting database on Logger A up may have
temporary data holes, which will be filled when the recovery process completes.
•
A permanent data hole can happen during an Emergency Purge. For example, there can be
permanent data loss if an emergency purge deletes records on one Logger that have not been
sent to the other Logger or to the HDS.
It is possible to monitor and tune Unified ICM to minimize the occurrence of data loss.
Fault Tolerance
One way to protect your system is to follow Best Practices for duplexed Unified ICM fault
tolerance, as presented in the ICM Administrator Guide.
Data Retention and Backups
Another way to safeguard against loss is to configure the amount of time that data is stored on
the Logger Central Database and in the HDS in relation to the schedule for HDS backups.
The Central database stores data for less time than the HDS. For example, you might store two
weeks of data on the Logger and a year of data on the HDS.
When the HDS recovers after going offline, it retrieves all of the data on the Logger for the
interval for which data is missing from the backup. You must manually restore the rest of the
data from the last HDS backup.
The amount of data retained on the Logger should cover, at a minimum, the time period between
HDS backups. For example, if the Logger stores data for two weeks, then you need to back up
at least every other week to ensure that you can recover all historical data.
CPU Utilization
It is possible that the process on one of the Loggers is slow because of space issues or an overload
of the SQL Server. In this situation, the data on the Logger with the slower SQL Server will lag
in persistence of the historical data with respect to the other Logger. This causes the HDS on
the corresponding side to lag as well.
As a consequence, if both the sides have an HDS set up and the same reports are run from both
HDSs, the reports might differ. This is usually a temporary inconsistency, since the condition
that causes the SQL server process to slow might be remedied. Autogrowing of the database
and load conditions often remediate. The Loggers and the HDSs eventually catch up and are in
sync. Running the reports later will result in consistent reports.
However, it the database server runs of disk space, the situation is quite serious and might cause
data to be out of sync for a longer duration until the problem is remedied. A permanent loss of
data can occur when data is purged from the peer Logger and never replicated on the slower
side.
Scheduled Purge and Retention Settings on Loggers
The goal of the scheduled purge is to free up database space by purging the oldest data.
Reporting Guide for Cisco Unified ICM Enterprise & Hosted Release 7.2(1)
146
Chapter 10: Reporting Implications of Data Loss and Component Failover
Preventing Data Loss from Logger and HDS Failure