Introduction
Este documento descreve como corrigir uma replicação lenta do Logger DB para HDS.
Contribuído por Steve Hartman, engenheiro do TAC da Cisco.
Prerequisites
Requirements
A Cisco recomenda que você tenha conhecimento destes tópicos:
Linguagem de Consulta Estruturada (SQL)
Cisco Unified Contact Center Enterprise (UCCE)
Componentes Utilizados
As informações neste documento são baseadas nestas versões 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
A atualização lenta dos dados históricos do logger para o HDS pode levar de 30 minutos a várias horas. Isso não inclui atualizações lentas depois que um comando SQL Truncate Table Recovery foi executado no HDS. Esse é, por natureza, um processo lento e pode levar até 24 horas para sincronizar novamente com o logger com base na quantidade de dados, volume de chamadas, potência de processamento e velocidade de rede entre o HDS e o Logger.
O HDS pode estar consistentemente atrás do logger ao longo de 1 dia, vários dias, semanas ou até mesmo meses e funciona em condições normais.
Verificar
A 1ª indicação é que o trabalho de limpeza do TCD falhará porque os logs de transação estarão cheios. Também é possível que ele falhe por outras razões que impedirão o BD HDS de executar a função de purgação e permitir que o BD cresça e crie uma tensão no sistema.
A segunda indicação pode ser que a data/hora máxima da tabela tem uma diferença entre o logger e o HDS. Para verificar isso, você pode executar essas consultas SQL no logger e no HDS e comparar a data/hora. Estas são algumas das tabelas mais frequentemente atualizadas que devem ser verificadas e correspondidas.
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 para isso acontecer é que o LogWatch é iniciado e pausa o fluxo de dados para o HDS quando o log de transações do DB atinge o padrão de 40% de cheio. ele se desfaz quando o log de transações cai abaixo dessa marca. Para ver se o LogWatch alcançou esse limite e pausou o fluxo de dados, consulte os registros 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
Em situações raras, você também pode ver que o processo de replicação trava e cria um mini dump. Esta mensagem indica que os logs de transação estão cheios:
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-se do problema em que o LogWatch interrompe o fluxo de dados, você pode aumentar a % de recuo de 40% para um número maior. Normalmente, 60% é um bom ponto de partida, mas não mais do que 80%.
Para executar essa alteração, edite o registro e modifique a seguinte chave: Distributor\RealTimeDistributor\CurrentVersion\Logger\CurrentVersion\SQLServer\LogWatch\BackOffPercent and cycle distributor services.
Se os registros de transação estiverem cheios, os registros de transação do BD HDS devem ser aumentados para acomodar o volume de dados sendo processados. Não há um número "mágico" aqui, mas comece com 2gig para o tamanho do log e aumente em 2 até que o log seja grande o suficiente para lidar com o volume de dados que o sistema está processando.
O outro registro de transações a ser investigado é o registro Temp DB, em que o guia de preparação do UCCE recomenda um ponto de partida de 400 MB e não deve exceder 2 GB na maioria das implantações, mesmo em clientes de alto volume.
Feedback