Sathya,
Before we start on this discussion, lets discuss how exactly Purging happens within the database:
Assuming the customer has data for 50 months and want to purge the data for 40 months. So, the customer configures the schedule purge configuration to "purge data greater than" 10 months. Then UCCX will check the data which is greater than 10 months and will initiate a purge. Now, whenever a purge is initiated, a purge session is initiated in the back-end. So now, we have one purge session in a running state already. Next day again, as we can't achieve to purge 40 months data in 1 day through purge. It will again check the data which will be greater than 10 months and initiate another purge that will cause another purge session to create.
If one session is there its fine, the informix will concentrate on executing that session but for multiple sessions informix has to make arrangements on running different sessions due to this purging can take forever and customers think it is really not happening as it will take a good amount of time to come down below the set threshold specially in a working Call Center environment (which is actively taking calls and performing verious operations adding to the database) wherein the rate of data insertion to the Historical Tables is much higher than the rate of data purging.
You can run the below command on CLI at various intervals to get the approximate idea of the oldest data from the Contact Call Detail table and see if the time is changing or not which will exactly tell you if the purging is happening or not:
run uccx sql db_cra select min(startdatetime) from contactcalldetail
Asssuming the output of above command tells us that the remaining data is 46 months old then go to Tools ->Historical reporting -> Schedule Purge Configuration and set below configuration something as the attached screenshot so that UCCX had a relatively smaller amount of time frame for which it needs to perform the purging. Keep playing with the purge schedule configuration based on the output of above command at different intervals till the time DB size does not come to a point wherein you just have the data for the actual period that you require i.e., 1 year, 2 year whatever as per your needs.
You can run below command from CLI to check the rate at which data is actually purging:
admin:file tail activelog /uccx/log/db/uccxspl.trace
trace expression :2015-11-12 11:02:40.000 Purge iteration from: 2014-12-09 13:00:00
trace expression :2015-11-12 11:02:40.000 Purge iteration till: 2014-12-09 14:00:00
trace expression :2015-11-12 11:13:32.000 Purge iteration from: 2014-12-09 14:00:00
trace expression :2015-11-12 11:13:32.000 Purge iteration till: 2014-12-09 15:00:00
The above snippet shows UCCX is able to delete 1 hour of data in approximately 10 minutes. This rate can differ based on the actual size of databse and the activities which are currently going at that moment with your Call Center.
Last but not the least, there is a below defect which had been opened for this particular issue and if the above mentioned workaround does not bring the DB under control in the next few days, it will be good if you can open a TAC case and get the older records truncated manually:
https://tools.cisco.com/bugsearch/bug/CSCuq24802/?reffering_site=dumpcr
Once the data had been purged, its gone forever. You cannot get it back. As far as Manual Purge is concerned, you should avoid it for now and see if Schedule Purge can bring the DB down following the above mentioned steps. At some point, if you decide to go for Manual Purge do it in after hours or when the Call Center is working at its lowest efficieny.
Regards
Deepak
- Rate Helpful Posts -
