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.
Requisitos
Cisco recomienda que tenga conocimiento sobre estos temas:
Lenguaje de consulta estructurado (SQL)
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 un SQL? ¿Recuperación truncada de la tabla? el comando se ha ejecutado 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 está actuando 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 evitará el HDS DB lo realice que purga la función y permitirá que el DB crezca y cree una tensión en el sistema.
¿la 2da indicación podía ser que la tabla? la fecha máxima/la hora s tiene una diferencia entre el maderero y el HDS. Para verificar esto está sucediendo, 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 DB? el registro de transacciones s 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 CheckForFunctionPausedis-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 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
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. ¿Hay no? ¿magia? el número 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