Introducción
Este documento describe cómo reparar una replicación lenta de Logger DB a HDS.
Colaborado por Steve Hartman, Ingeniero del TAC de Cisco.
Prerequisites
Requirements
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:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Problema
La lenta actualización de los datos históricos del registrador al HDS puede tardar de 30 minutos a varias horas. Esto no incluye actualizaciones lentas después de que se haya ejecutado un comando SQL Truncate Table Recovery en el HDS. Por naturaleza, se trata de un proceso lento y puede tardar hasta 24 horas en volver a sincronizarse con el registrador en función de la cantidad de datos, el volumen de llamadas, la potencia de procesamiento y la velocidad de red entre el HDS y el Logger.
HDS puede estar constantemente detrás del registrador durante 1 día, varios días, semanas o incluso meses y funciona en condiciones normales.
Verificación
La primera indicación es que el trabajo de depuración de TCD fallará porque los registros de transacciones estarán llenos. También es posible que falle por otras razones que evitarán que HDS DB realice la función de purga y que la base de datos crezca y cree una tensión en el sistema.
La segunda indicación podría ser que la fecha/hora máxima de la tabla tiene una diferencia entre el registrador y el HDS. Para verificarlo, puede ejecutar estas consultas SQL en el registrador y HDS y comparar la fecha/hora. Estas son algunas de las tablas que se actualizan con más frecuencia y que se deben comprobar y comparar.
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 de las razones por las que esto sucede es porque LogWatch se inicia y detiene el flujo de datos al HDS cuando el registro de transacciones de la base de datos alcanza el valor predeterminado del 40% completo. se desactiva cuando el registro de transacciones cae por debajo de esta marca. Para ver si LogWatch ha alcanzado este límite y ha puesto en pausa 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 situaciones poco frecuentes, también puede ver que el proceso de replicación falla y crea un mini volcado. Este mensaje indica que los registros de transacciones están 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 en el que LogWatch detiene el flujo de datos, puede aumentar el porcentaje de respaldo del 40% a un número mayor. Normalmente, el 60% es un buen punto de partida, pero no más del 80%.
Para realizar este cambio, edite el Registro y modifique la siguiente clave: Distributor\RealTimeDistributor\CurrentVersion\Logger\CurrentVersion\SQLServer\LogWatch\BackOffPercent and cycle distributor services.
Si los registros de transacciones están llenos, se deben aumentar los registros de transacciones de HDS DB para acelerar el volumen de datos que se procesan. Aquí no hay un número "mágico", pero comience con 2gig para el tamaño del registro y aumente en 2 hasta que el registro sea lo suficientemente grande como para manejar el volumen de datos que su sistema está procesando.
El otro registro de transacciones que se debe investigar es el registro de Temp DB, donde la guía de almacenamiento provisional de UCCE recomienda un punto de partida de 400 MB y no debe exceder los 2 GB en la mayoría de las implementaciones, incluso en clientes de grandes volúmenes.
Comentarios