Cisco Cisco Unified Contact Center Enterprise 9.0(1) Guia Do Utilizador

Página de 238
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 is 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.
Permanent loss of historical data can occur if the emergency purge removes historical data that has not yet
made it to an HDS and has also not been replicated to the peer Logger that is “down” or in the recovery
process.
Database used percentage is displayed as a normal status message in the replication process every few minutes.
You can occasionally monitor this value to make sure that is does not grow too often or too fast. Emergency
purge occurs when the percentage used is greater than the configured value (usually 90%).
Data loss from PIM failure
The Peripheral Interface Manager (PIM) is the process on the Peripheral Gateway responsible for the actual
connection to the peripheral and for normalizing the CTI interface on behalf of Unified CCE.
If a PIM fails, if the link between the PIM and the ACD goes down, or if the ACD goes down, then all of the
reporting data that has been gathered for the peripheral associated with the PIM is deleted.
The state of all agents on that peripheral is set to logged out and is reported as such to the CallRouter.
The CallRouter has no way of determining what was going on at the ACD while the PIM was out of contact
with the ACD. When the PIM reconnects to the ACD, the ACDS does not send the PIM sufficient information
to allow the recording of accurate historical reporting data for the interval(s) in which the disconnect took
place.
When the PIM reconnects to the ACD, most ACDs do pass information to the PIM about each agent's
state and duration in that state. While this is not enough to allow accurate historical reporting data to be
recorded, it is enough to allow the CallRouter to make accurate call routing decisions.
Note
When the PG is duplexed, either the Side A or Side B PIM is active for each peripheral. If one side loses
connection, the other comes up and activates.
Reporting Guide for Cisco Unified Intelligent Contact Management and Unified Contact Center Enterprise & Hosted
Release 9.0(1)    
173
Data loss from PIM failure