Introdução
Este original descreve como fixar uma replicação lenta do registador DB ao HDS.
Contribuído por Steve Hartman, engenheiro de TAC da Cisco.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
Língua de consulta estruturada (SQL)
Cisco Unified Contact Center Enterprise (UCCE)
As informações neste documento são baseadas nestas versões de software:
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.
Problema
A atualização lenta dos dados históricos do registador ao HDS pode tomar de 30 minutos a diversas horas. Isto não inclui atualizações lentas depois que um comando de recuperação truncado da tabela SQL foi executado no HDS. Isto é por natureza, um processo lento e pode tomar até 24hrs à re-sincronização com o registador baseado nos dados, no volume da chamada, na potência de processamento e na velocidade de rede de uma quantidade entre o HDS e o registador.
O HDS pode ser consistentemente atrás do registador no curso de 1 dia, de diversos dias, de semanas ou mesmo de meses e opera-se em condições normais.
Verificar
a?a indicação é o trabalho da remoção TCD falhará porque os log de transação estarão completos. É igualmente possível que isso que falhará por outras razões que impedirá o HDS DB para executar a função de remoção e para permitir que o DB cresça e crie uma tensão no sistema.
a?a indicação poderia ser que a data máxima/hora da tabela tem uma diferença entre o registador e o HDS. Para verificar isto, você pode executar estas perguntas SQL no registador e no HDS e comparar a data/tempos. Estes são algumas das tabelas mais frequentemente actualizadas que devem ser verificadas e combinado.
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
Uma razão que esta acontece é porque o LogWatch é retrocede dentro e pausa o fluxo dos dados ao HDS quando o log de transação do DB alcança o padrão de 40% completo. ele desconfortos quando o log de transação deixar cair abaixo desta marca. Para ver se LogWatch alcançou este limite e pausou o fluxo de dados, reveja os logs RPL para esta Mensagem:
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
Nas situações raras, você pode igualmente ver que o processo de replicação causa um crash e cria uma mini descarga. Esta mensagem indica que os log de transação estão completos:
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
Solução
Para recuperar da edição onde LogWatch pausa o fluxo dos dados, você pode aumentar o desembaraço % de 40% a um número mais alto. Tipicamente 60% é um bom ponto de início mas não mais de 80%.
Para executar esta mudança, edite o registro e altere a seguinte chave: Distribuidor \ RealTimeDistributor \ Versão atual \ registador \ Versão atual \ SQLServer \ LogWatch \ BackOffPercent e serviços do distribuidor do ciclo.
Se os log de transação estão completos, a seguir os log de transação HDS DB devem ser aumentados ao accomidate o volume de dados que está sendo processado. Não há nenhum número “mágico” aqui mas o começo com o 2gig para o tamanho do log e o incremento por 2 até que o log esteja grande bastante segurar o volume de dados seu sistema está processando.
O outro log de transação a investigar é o log do Temp DB onde o guia da plataforma UCCE recomenda um ponto de início de 400MB e não deve exceder 2GB sob a maioria de disposições, mesmo em clientes do volume alto.
Feedback