Introducción
Este documento describe cómo reparar una replicación lenta del maderero DB al HDS.
Contribuido por Steve Hartman, ingeniero de Cisco TAC.
Prerrequisitos
Requisitos
Cisco recomienda que tenga conocimiento sobre estos temas:
Lenguaje de consulta estructurado (SQL)
Cisco Unified Contact Center Enterprise (UCCE)
Componentes Utilizados
La información que contiene este documento se basa en estas versiones de software:
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.
Problema
La actualización lenta de los datos históricos del maderero al HDS puede llevar a partir de 30 minutos varias horas. Esto no incluye las actualizaciones lentas después de que hayan ejecutado a un comando recovery truncado de la tabla SQL en el HDS. Esto está por naturaleza, un proceso lento y puede tomar hasta 24hrs hasta la RESYNC con el maderero basado en los datos, el volumen de llamada, la potencia de procesamiento y la velocidad de la red de la cantidad entre el HDS y el maderero.
El HDS puede estar constantemente detrás del maderero a lo largo de 1 día, de varios días, de las semanas o aún de los meses y actúa en condiciones normales.
Verificación
la 1ra indicación es el trabajo de la purgación TCD fallará porque los registros de transacciones serán llenos. Es también posible que eso que fallará por otros motivos que prevendrá el HDS DB para realizar la función purgadora y para permitir que el DB crezca y cree una tensión en el sistema.
la 2da indicación podría ser que la fecha máxima/la hora de la tabla tiene una diferencia entre el maderero y el HDS. Para verificar esto, usted puede funcionar con estas consultas SQL en el maderero y el HDS y comparar la fecha/los tiempos. Éstos son algunas de las tablas más con frecuencia actualizadas que deben ser marcadas y ser correspondidas con.
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
Una razón que sucede ésta es porque es el LogWatch golpea con el pie adentro y se detiene brevemente el flujo de datos al HDS cuando el registro de transacciones DB alcanza el valor por defecto del 40% lleno. él inquietudes cuando el registro de transacciones cae debajo de esta marca. Para ver si LogWatch ha alcanzado este límite y se ha detenido brevemente el flujo de datos, revise los registros RPL para esta Mensajería:
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
En las situaciones poco comunes, usted puede también ver que el proceso de replicación causa un crash y crea un mini volcado. Este mensaje indica que los registros de transacciones son llenos:
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
Solución
Para recuperarse del problema donde se detiene brevemente LogWatch el flujo de datos, usted puede aumentar el saque % a partir de la 40% a un número más elevado. El típicamente 60% es un buen punto de partida pero no más el que 80%.
Para realizar este cambio, edite el registro y modifique la clave siguiente: Distribuidor \ RealTimeDistributor \ CurrentVersion \ maderero \ CurrentVersion \ SQLServer \ LogWatch \ BackOffPercent y servicios del distribuidor del ciclo.
Si los registros de transacciones son llenos, después los registros de transacciones HDS DB se deben aumentar al accomidate el volumen de datos que es procesado. No hay número “mágico” aquí pero el comienzo con 2gig para el tamaño del registro y el incremento por 2 hasta que el registro sea bastante grande manejar el volumen de datos su sistema está procesando.
El otro registro de transacciones a investigar es el registro de los temporeros DB donde la guía del estacionamiento UCCE recomienda un punto de partida de 400MB y no debe exceder 2GB bajo la mayoría de implementaciones, incluso en los clientes en grandes cantidades.
Comentarios