Introduction
Ce document décrit comment réparer une réplication lente de la base de données Logger DB vers HDS.
Contribué par Steve Hartman, ingénieur TAC Cisco.
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
SQL (Structured Query Language)
Cisco Unified Contact Center Enterprise (UCCE)
Components Used
Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :
- UCCE 9.x et versions ultérieures
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Problème
La mise à jour lente des données historiques du Logger vers le HDS peut prendre de 30 minutes à plusieurs heures. Cela n'inclut pas les mises à jour lentes après l'exécution d'une commande Truncate Table Recovery sur le HDS. Il s'agit par nature d'un processus lent qui peut prendre jusqu'à 24 heures pour se synchroniser à nouveau avec l'enregistreur en fonction de la quantité de données, du volume d'appels, de la puissance de traitement et de la vitesse du réseau entre le HDS et l'enregistreur.
HDS peut être constamment derrière le enregistreur sur une durée de 1 jour, plusieurs jours, semaines ou même des mois et fonctionne dans des conditions normales.
Vérification
La première indication est que le travail de purge TCD échouera car les journaux de transactions seront complets. Il est également possible qu'il échoue pour d'autres raisons, ce qui empêchera la base de données HDS d'exécuter la fonction de purge et permettra à la base de données de croître et de créer une contrainte sur le système.
2e indication possible : la date/heure maximale de la table a une différence entre le enregistreur et le HDS. Pour vérifier cela, vous pouvez exécuter ces requêtes SQL sur le Logger et HDS et comparer la date/les heures. Voici quelques-unes des tables les plus fréquemment mises à jour qui doivent être vérifiées et mises en correspondance.
select max (DateTime) from Call_Type_Interval
select max (DateTime) from Agent_Skill_Group_Interval
select max (DateTime) from Route_Call_Detail
select max (DateTime) from Termination_Call_Detail
select max (DateTime) from Skill_Group_Interval
Cela se produit notamment parce que le LogWatch est activé et met en pause le flux de données vers le HDS lorsque le journal de transactions de la base de données atteint la valeur par défaut de 40 % pleine. il se désactive lorsque le journal des transactions tombe sous cette marque. Pour voir si LogWatch a atteint cette limite et suspendu le flux de données, consultez les journaux RPL pour ce message :
dis-rpl Trace: Thread [6316] Function Replication is Paused by LogWatch in CheckForFunctionPause
dis-rpl Trace: Thread [7492] Function Recovery is Paused by LogWatch in CheckForFunctionPause
Dans de rares cas, vous pouvez également voir que le processus de réplication plante et crée un mini vidage. Ce message indique que les journaux des transactions sont complets :
dis-rpl Trace: Node Manager thread received shutdown message
dis-rpl Trace: CExceptionHandlerEx::GenerateMiniDump -- A Mini Dump File is available at logfiles\replication.exe_20140918030018994.mdmp
dis-rpl Trace: Thread [5232] Function Replication is Paused by LogWatch in CheckForFunctionPause
dis-rpl Unhandled Exception: Exception code: C0000005 ACCESS_VIOLATION
Fault address: 0043AD8E 01:00039D8E C:\icm\bin\replication.exe
terminating_call_detail
Registers:
EAX:00000004
EBX:00000178
ECX:00000000
EDX:00F23110
ESI:77E42014
EDI:77E62FBD
CS:EIP:001B:0043AD8E
SS:ESP:0023:0131FE54 EBP:0131FE60
DS:0023 ES:0023 FS:003B GS:0000
Flags:00010212
Call stack:
Address Frame
0043AD8E 0131FE60 EventInput::Flush+1E
004173D4 0131FEDC ICRDb::Shutdown+14
0040387A 0131FEE8 NodeManagerHandler+2A
00614F56 0131FFB8 NMResponderThread+256
77E6484F 0131FFEC GetModuleHandleA+DF
Solution
Pour récupérer du problème où LogWatch interrompt le flux de données, vous pouvez augmenter le pourcentage de retour de 40 % à un nombre supérieur. En règle générale, 60 % constitue un bon point de départ, mais pas plus de 80 %.
Pour effectuer cette modification, modifiez le Registre et modifiez la clé suivante : Distributor\RealTimeDistributor\CurrentVersion\Logger\CurrentVersion\SQLServer\LogWatch\BackOffPercent and cycle distributor services.
Si les journaux de transactions sont complets, les journaux de transactions de la base de données HDS doivent être augmentés pour tenir compte du volume de données traité. Il n'y a pas de nombre magique ici mais commencez par 2gig pour la taille du journal et incrémentez de 2 jusqu'à ce que le journal soit assez grand pour gérer le volume de données que le système traite.
L'autre journal des transactions à examiner est le journal de base de données temporaire dans lequel le guide de préparation UCCE recommande un point de départ de 400 Mo et ne doit pas dépasser 2 Go dans la plupart des déploiements, même pour les clients à volume élevé.
Commentaires