Colaboración : Cisco Unified Contact Center Enterprise

Resuelva problemas los problemas UCCE cuando los datos no se escriben al HDS

18 Junio 2016 - Traducción Automática
Otras Versiones: PDFpdf | Comentarios

Introducción

Este documento describe cómo resolver problemas un problema con la versión 10.x del Cisco Unified Contact Center Enterprise (UCCE) cuando los datos no se escriben al Historical Data Server (HDS).

Contribuido por la pavana Dave, ingeniero de Cisco TAC.

Problema

Después de que se convierta un evento de la purgación (entre 12:30 y la hora del servidor de 12:35), la tabla de la recuperación el espacio en blanco y los datos puebla no más en el HDS del maderero. En algunos casos, el DiffDay en el maderero es mayor que el valor de la retención cuando usted ve el resumen usado espacio.

Causa

Esta sección describe cómo determinar la causa del problema.

  Nota: El nombre de instancia que se utiliza para los ejemplos en este documento es el laboratorio, que se puede intercambiar con el <instance>.

Para los pasos de Troubleshooting inicial, usted debe verificar la salud de la base de datos vía el DBA ICM en los madereros y los distribuidores que encuentran este problema. Usted debe también verificar las claves de registro básicas para las purgaciones. Para verificar el tamaño de la base de datos y el uso, navegue al DBA ICM, haga clic con el botón derecho del ratón el <instance>_<component>, y haga clic las propiedades. Verifique que esto no esté en o por encima del 80%. Marque esta información sobre el maderero, el HDS, y la estación de trabajo administrativa (AW) también.

Después, usted puede marcar el resumen del uso del espacio en el DBA ICM:

  1. <instance>_<component> del click derecho.

  2. Navegue a los datos > al resumen usado espacio del menú cerca del top de la página.

  3. Desmarque las tablas vacías de la visualización y visualice las casillas de verificación de las tablas temporales.

    Si usted ve el HDS que no contiene los datos actuales, la última vez que los datos fueron recibidos en la mayor parte de las tablas indica el tiempo que ocurrió el problema.

Marque las configuraciones del registro básicas de la purgación y de la replicación en el maderero:

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

Marque las configuraciones del registro básicas de la purgación y de la replicación en el distribuidor:

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 este momento, si los datos se verifican y corrigen, el siguiente paso es tirar de los registros de la replicación del distribuidor y del maderero. El valor de la traza se fija a 3 en el pórtico de diagnóstico del marco, que tira de los registros pronto después. Los registros deben mostrar los datos similares a los dos ejemplos siguientes.

Aquí están los registros de la replicación del maderero:

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

Aquí están los registros de la replicación del distribuidor:

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

Para entender mejor las claves de la replicación y la ninguna entrada coincidente que aparece en los registros, las interrogaciones del Lenguaje de consulta estructurado (SQL) se funcionan con para más información sobre todos los madereros y distribuidores.

Aquí están las consultas SQL:

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

Aquí están los resultados de la consulta SQL:

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

Note que las claves de la recuperación para el maderero A y el distribuidor que A está separada perceptiblemente adicional que se espera y que eso en el lado B. Además, los datos más recientes sobre el distribuidor A hacen juego aproximadamente la ubicación de los informes que falta de los datos que primero fueron observados. También observe la discrepancia en la distancia máxima del RecoveryKey entre la tabla de las interrogaciones y los registros.

Usted puede ver la tabla de la recuperación para determinar las claves se salvan que.

Aquí está la consulta SQL:

select max(RecoveryKey) from Recovery

Aquí están los resultados de la consulta SQL:

HDSA - 7369090330048
RogA - EMPTY

En la salida, usted puede ver que el maderero A aparece VACÍO, sin la clave de la recuperación. Puesto que estos datos son inesperados, usted debe entonces verificar los datos en la tabla de la recuperación del maderero A.

Aquí está la consulta SQL:

select * from Recovery

Cuando se funciona con esta interrogación, los resultados son en blanco, que indica que no hay datos en la tabla de la recuperación. En este momento, usted debe evaluar de nuevo las entradas de registro. Cuando se exportan los dos lados y se hace una comparación, se nota la discrepancia.

Aquí están las entradas de registro para el maderero 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

Aquí están las entradas de registro para el maderero 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

Como se muestra en el maderero A, el valor de los días de la recuperación se fija para 0x1e, que es el valor (HEXADECIMAL) hexadecimal para 30. En el maderero B, el valor de los días se fija para 0xe42, que es el valor hex para 3,650. Sobre el estudio adicional con las entradas de registro predeterminadas en el laboratorio, éste parece ser el problema. Esto también hace juego el síntoma del problema, que ocurre aproximadamente una vez al mes.

Solución

Nota: Cisco recomienda que usted realiza las acciones que se describen en esta sección durante una ventana de mantenimiento.

Para resolver este problema, usted debe poner al día la clave de registro a 0xe42 (3,650), que es la clave predeterminada:

  1. Fije las claves de registro a 0xE42 (3,650).

  2. Recomience el servicio para el maderero A.

  3. Recomience el servicio para el distribuidor A.

  4. Recomience los servicios para el maderero y el distribuidor B, si procede.

Nota: Este problema está actualmente bajo investigación del equipo de desarrollo y se sigue en el Id. de bug Cisco CSCuu26777.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.