Collaboration : Cisco Unified Contact Center Enterprise

Dépannez les questions UCCE quand des données ne sont pas écrites au HDS

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (29 mai 2015) | Commentaires

Introduction

Ce document décrit comment dépanner une question avec la version 10.x du Cisco Unified Contact Center Enterprise (UCCE) quand des données ne sont pas écrites à Historical Data Server (HDS).

Contribué par Pavan Dave, ingénieur TAC Cisco.

Problème

Après qu'un événement de purge (entre 12:30 AM et moment de serveur de 12:35 AM), la table de reprise devienne le blanc et les données ne le remplit plus sur le HDS de l'enregistreur. Dans certains cas, le DiffDay sur l'enregistreur est plus grand que la valeur de retenir quand vous visualisez le résumé utilisé parespace.

Cause

Cette section décrit comment déterminer la cause de la question.

  Remarque: Le nom d'exemple qui est utilisé pour les exemples dans tout ce document est le laboratoire, qui peut être échangé avec le <instance>.

Pour les étapes de dépannage initiales, vous devriez vérifier les santés de base de données par l'intermédiaire du DBA missile aux performances améliorées sur les enregistreurs et les distributeurs qui rencontrent ce problème. Vous devriez également vérifier les clés de registre de base pour des purges. Afin de vérifier la taille de la base de données et l'utilisation, naviguez vers le DBA missile aux performances améliorées, cliquez avec le bouton droit le <instance>_<component>, et cliquez sur Properties. Vérifiez que ce n'est pas à ou au-dessus de 80%. Vérifiez ces informations sur l'enregistreur, le HDS, et le poste de travail d'administration (aw) aussi bien.

Ensuite, vous pouvez vérifier le résumé d'utilisation de l'espace sur le DBA missile aux performances améliorées :

  1. <instance>_<component> de clic droit.

  2. Naviguez vers les données > le résumé utilisé parespace du menu près du dessus de la page.

  3. Décochez les Tableaux vides d'affichage et affichez les cases de Tableaux provisoires.

    Si vous visualisez le HDS qui ne contient pas les données en cours, la dernière fois que les données ont été reçues sur la plupart des tables indique le temps que la question s'est produite.

Vérifiez les paramètres de registre de base de purge et de réplication sur l'enregistreur :

Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\LoggerA\
Recovery\CurrentVersion\Purge\Schedule\Schedule
Class Name: <NO CLASS>
Last Write Time: 12/8/2014 - 1:41 PM
Value 0
Name: Schedule
Type: REG_SZ
Data&colon; 00:30 M,T,W,Th,F,S,Su


Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\LoggerA\
NodeManager\CurrentVersion\Processes\rpl
Class Name:        <NO CLASS>
Last Write Time:   11/15/2014 - 1:15 PM
Value 10
  Name:            ImageArgs
  Type:            REG_SZ
  Data&colon;            /db lab_sideA /server /name ROGGER105A/replicationport 41026
/recoveryport 41028

Vérifiez les paramètres de registre de base de purge et de réplication sur le distributeur :

Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\
Distributor\RealTimeDistributor\CurrentVersion\Recovery\
CurrentVersion\Purge\Schedule\Schedule
Class Name: <NO CLASS>
Last Write Time: 2/11/2015 - 11:07 PM
Value 0
Name: Schedule
Type: REG_SZ
Data&colon; 00:30 M,T,W,Th,F,S,Su


Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\
Distributor\NodeManager\CurrentVersion\Processes\rpl
Class Name: <NO CLASS>
Last Write Time: 2/11/2015 - 11:07 PM
Value 10
Name: ImageArgs
Type: REG_SZ
Data&colon; /db lab_hds /client /name ROGGER105A /replicationport
41026 /recoveryport 41028

En ce moment, si les données sont vérifiées et corrigent, l'étape suivante est de tirer les logs de réplication du distributeur et de l'enregistreur. La valeur de suivi est placée à 3 sur le portique diagnostique de cadre, qui tire les logs peu ensuite. Les logs devraient afficher des données semblables aux deux prochains exemples.

Voici les logs de réplication d'enregistreur :

14:40:55:861 la-rpl Trace: No MATCHING entry for table t_Termination_Call_Detail,
FromRecoveryKey = 7369086520649.0 and ToRecoveryKey = 7369085626000.0

Voici les logs de réplication de distributeur :

14:29:52:607 dis-rpl Trace: Sent Replicated request to the Server for table
t_Termination_Call_Detail, FromRecoveryKey = 7369086520649.0 and
ToRecoveryKey = 7369085626000.0

Afin de ne comprendre mieux les clés de réplication et l'aucune entrée ASSORTIE qui apparaît dans les logs, des requêtes du SQL (SQL) sont exécutées pour plus d'informations sur tous les enregistreurs et distributeurs.

Voici les requêtes SQL :

select max(RecoveryKey) from t_Termination_Call_Detail
select max(DateTime) from t_Termination_Call_Detail

Voici les résultats de requête SQL :

RogA - 7369086557263
HDSA - 7369086520649
RogA - 2015-04-06 15:01:47.990
HDSA - 2015-04-05 00:28:19.000

Notez que les clés de reprise pour l'enregistreur A et le distributeur qu'A sont sensiblement davantage distant qu'est prévu et que cela du côté B. En outre, les données les plus récentes sur le distributeur A apparient approximativement l'emplacement des états manquants de données qui ont été observés la première fois. Notez également l'anomalie dans la distance maximum de RecoveryKey entre la table des requêtes et les logs.

Vous pouvez visualiser la table de reprise afin de déterminer les clés qui sont enregistrées.

Voici la requête SQL :

select max(RecoveryKey) from Recovery

Voici les résultats de requête SQL :

HDSA - 7369090330048
RogA - EMPTY

Dans la sortie, vous pouvez voir que l'enregistreur A semble VIDE, sans la clé de reprise. Puisque ces données sont inattendues, vous devriez alors vérifier les données dans la table de reprise de l'enregistreur A.

Voici la requête SQL :

select * from Recovery

Quand cette requête est exécutée, les résultats sont vides, qui indique qu'il n'y a aucune donnée dans la table de reprise. En ce moment, vous devriez réévaluer les entrées dans le registre. Quand les deux côtés sont exportés et une comparaison est faite, l'anomalie est notée.

Voici les entrées dans le registre pour l'enregistreur A :

Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\
LoggerA\Recovery\CurrentVersion\Purge\Retain\System\Recovery
Class Name:        <NO CLASS>
Last Write Time:   12/8/2014 - 1:39 PM
Value 0
  Name:            Days
  Type:            REG_DWORD
  Data&colon;      0X0000001e

Voici les entrées dans le registre pour l'enregistreur B :

Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\
LoggerB\Recovery\CurrentVersion\Purge\Retain\System\Recovery
Class Name: <NO CLASS>
Last Write Time: 12/8/2014 - 1:39 PM
Value 0
Name: Days
Type: REG_DWORD
Data&colon; 0X00000e42

Comme affiché sur l'enregistreur A, la valeur de jours de reprise est placée pour 0x1e, qui est la valeur (HEXADÉCIMALE) hexadécimale pour 30. Sur l'enregistreur B, la valeur de jours est placée pour 0xe42, qui est la valeur HEXADÉCIMALE pour 3,650. Sur davantage d'examen avec les entrées dans le registre par défaut dans le laboratoire, ceci semble être la question. Ceci apparie également le symptôme de la question, qui se produit approximativement une fois par mois.

Solution

Remarque: Cisco recommande que vous exécutiez les actions qui sont décrites dans cette section pendant une fenêtre de maintenance.

Afin de résoudre ce problème, vous devez mettre à jour la clé de registre à 0xe42 (3,650), qui est la clé par défaut :

  1. Placez les clés de registre à 0xE42 (3,650).

  2. Redémarrez le service pour l'enregistreur R.

  3. Redémarrez le service pour le distributeur R.

  4. Redémarrez les services pour l'enregistreur et le distributeur B, si c'est approprié.

Remarque: Cette question est actuellement à l'étude par l'équipe de développement et est dépistée dans l'ID de bogue Cisco CSCuu26777.


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 118980