Vivek,
I recently ran into this problem when implementing CCB. After reaching an a greement with Cisco DE we decided that modification of the ecc variable array size within the logger DB was the safest direction to go.
1.) UpDate Logger Databases
....1a.) execute SQL query on LOGGER-A
.
UPDATE t_Expanded_Call_Variable
SET MaximumArraySize=5
FROM t_Expanded_Call_Variable
WHERE ExpandedCallVariableID='xxxx' <-- VarID of
FromExtVXML.
....1b.) execute SQL query on LOGGER-B
.
UPDATE t_Expanded_Call_Variable
SET MaximumArraySize=5
FROM t_Expanded_Call_Variable
WHERE ExpandedCallVariableID='xxxx' <-- VarID of
FromExtVXML.
3.) Stop all processes on VRU PG's (a &
then start them back up. This will force the VRU PG's to absorbe the new ECC array size.
.
In my contact center I have 2 VRUPG pairs that service 4-PIMS (one for each CVP CallServer) I was able to use SIP proxy to route traffic to only 2 CVP Call servers at the sister site while I stopped and started the procs on the VRUPG's at the "A" site. I then repeated the same process for the "B" site thus insuring that no service inturruptions occured. I'm in a very large HA architecture and this was fairly simple.
If you are in a smaller deployment you will have to schedule some downtime to restart the VRUPG's (5 min max) to stop the ICM processes on both VRUPG's at the same time.
