Introduction
Ce document décrit comment réparer une réplication lente de DB d'enregistreur à HDS.
Contribué par Steve Hartman, ingénieur TAC Cisco.
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
SQL (SQL)
Cisco Unified Contact Center Enterprise (UCCE)
Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :
Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.
Problème
La mise à jour lente des données historiques de l'enregistreur au HDS peut prendre de 30 minutes à plusieurs heures. Ceci n'inclut pas les mises à jour lentes après qu'une commande de reprise tronquée de Tableau SQL ait été exécutée sur le HDS. C'est par nature, un processus lent et peut prendre à 24hrs à la resync avec l'enregistreur basé sur la quantité de données, volume d'appels, capacité de traitement et vitesse du réseau entre le HDS et l'enregistreur.
HDS peut être uniformément derrière l'enregistreur au cours de 1 jour, de plusieurs jours, de semaines ou même de mois et actionne le dans des conditions normales.
Vérifiez
la 1ère indication est le travail de purge TCD échouera parce que les logs de transaction seront pleins. Il est également possible que cela il échouera pour d'autres raisons qui empêcheront le DB HDS pour remplir la fonction purgeante et pour permettre au DB pour se développer et pour créer une tension sur le système.
la 2ème indication pourrait être que le date/heure maximum de la table a une différence entre l'enregistreur et le HDS. Pour vérifier ceci, vous pouvez exécuter ces requêtes SQL sur l'enregistreur et le HDS et comparer la date/temps. Ce sont certaines des tables plus fréquemment à jour qui devraient être vérifiées et appariées.
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
Une raison que ceci se produit est parce que le LogWatch est donne un coup de pied dedans et fait une pause l'écoulement des données au HDS quand le log de transaction du DB atteint le par défaut de 40% plein. il malaises quand le log de transaction relâche au-dessous de cette marque. Pour voir si LogWatch a atteint cette limite et a fait une pause le flux de données, passez en revue les logs RPL pour cette Messagerie :
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 des situations rares, vous pouvez également voir que le processus de réplication tombe en panne et crée un mini vidage mémoire. Ce message indique que les logs de transaction sont pleins :
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 de la question où LogWatch fait une pause l'écoulement des données, vous pouvez augmenter le dégagement % de 40% à un nombre supérieur. En général 60% est un bon point commençant mais pas plus de 80%.
Pour exécuter cette modification, éditez le registre et modifiez la clé suivante : Services de distributeur de distributeur \ RealTimeDistributor \ CurrentVersion \ enregistreur \ CurrentVersion \ SQLServer \ LogWatch \ BackOffPercent et de cycle.
Si les logs de transaction sont pleins, alors les logs de transaction de DB HDS devraient être grimpés jusqu'à l'accomidate le volume de données étant traité. Il n'y a aucun nombre « magique » ici mais le début avec 2gig pour la taille de log et incrément par 2 jusqu'à ce que le log soit assez grand pour traiter le volume de données leur système traite.
L'autre log de transaction à étudier est le log de DB de Temp où le guide de mise en place UCCE recommande un point commençant de 400MB et ne devrait pas dépasser 2GB sous la plupart des déploiements, même sur les clients à fort débit.
Commentaires