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 requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
SQL (SQL)
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 un SQL ? Tronquez la reprise de Tableau ? la commande a é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 de l'exécuter purgeant la fonction et permettront au DB pour se développer et pour créer une tension sur le système.
la 2ème indication a pu être que la table ? le date/heure maximum s a une différence entre l'enregistreur et le HDS. Pour vérifier ceci se produit, 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 DB ? le log de transaction s 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 CheckForFunctionPausedis-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 messagedis-rpl Trace: CExceptionHandlerEx::GenerateMiniDump -- A Mini Dump File is available at logfiles\replication.exe_20140918030018994.mdmpdis-rpl Trace: Thread [5232] Function Replication is Paused by LogWatch in CheckForFunctionPausedis-rpl Unhandled Exception: Exception code: C0000005 ACCESS_VIOLATIONFault address: 0043AD8E 01:00039D8E C:\icm\bin\replication.exeterminating_call_detailRegisters:EAX:00000004EBX:00000178ECX:00000000EDX:00F23110ESI:77E42014EDI:77E62FBDCS:EIP:001B:0043AD8ESS:ESP:0023:0131FE54 EBP:0131FE60DS:0023 ES:0023 FS:003B GS:0000Flags:00010212Call stack:Address Frame0043AD8E 0131FE60 EventInput::Flush+1E004173D4 0131FEDC ICRDb::Shutdown+140040387A 0131FEE8 NodeManagerHandler+2A00614F56 0131FFB8 NMResponderThread+25677E6484F 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 y a non ? Magic ? le nombre 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