Colaboração : Cisco Unified Contact Center Enterprise

Pesquise defeitos edições UCCE quando os dados não são redigidos ao HDS

18 Junho 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Feedback

Introdução

Este documento descreve como pesquisar defeitos uma edição com a versão 10.x do Cisco Unified Contact Center Enterprise (UCCE) quando os dados não são redigidos ao Historical Data Server (HDS).

Contribuído pelo Pavan Dave, engenheiro de TAC da Cisco.

Problema

Depois que um evento da remoção (entre 12:30 AM e tempo de servidor de 12:35 AM), a tabela da recuperação se torna a placa e os dados já não povoam no HDS do registador. Em alguns casos, o DiffDay no registador é maior do que o valor da retenção quando você vê o sumário usado espaço.

Causa

Esta seção descreve como determinar a causa da edição.

  Nota: O nome de instância que é usado para os exemplos durante todo este documento é o laboratório, que pode ser intercambiado com <instance>.

Para as etapas do Troubleshooting inicial, você deve verificar a saúde do banco de dados através do DBA ICM nos registadores e nos distribuidores que encontram este problema. Você deve igualmente verificar as chaves de registro básicas para remoções. A fim verificar o tamanho de banco de dados e o uso, navegue ao DBA ICM, clicar com o botão direito o <instance>_<component>, e clique propriedades. Verifique que isto não é a ou acima de 80%. Verifique esta informação no registador, no HDS, e na estação de trabalho administrativa (AW) também.

Em seguida, você pode verificar o sumário do uso do espaço no DBA ICM:

  1. Clicar com o botão direito o <instance>_<component>.

  2. Navegue aos dados > ao sumário usado espaço do menu perto da parte superior da página.

  3. Desmarcar as tabelas vazias do indicador e indique caixas de seleção das tabelas provisórias.

    Se você vê o HDS que não contém os dados atuais, a última vez que os dados estiveram recebidos na maioria das tabelas indica o tempo que a edição ocorreu.

Verifique as configurações de registro básicas da remoção e da replicação no registador:

Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\LoggerA\
Recovery\CurrentVersion\Purge\Schedule\Schedule
Class Name: <NO CLASS>
Last Write Time: 12/8/2014 - 1:41 PM
Value 0
Name: Schedule
Type: REG_SZ
Data&colon; 00:30 M,T,W,Th,F,S,Su


Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\LoggerA\
NodeManager\CurrentVersion\Processes\rpl
Class Name:        <NO CLASS>
Last Write Time:   11/15/2014 - 1:15 PM
Value 10
  Name:            ImageArgs
  Type:            REG_SZ
  Data&colon;            /db lab_sideA /server /name ROGGER105A/replicationport 41026
/recoveryport 41028

Verifique as configurações de registro básicas da remoção e da replicação no distribuidor:

Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\
Distributor\RealTimeDistributor\CurrentVersion\Recovery\
CurrentVersion\Purge\Schedule\Schedule
Class Name: <NO CLASS>
Last Write Time: 2/11/2015 - 11:07 PM
Value 0
Name: Schedule
Type: REG_SZ
Data&colon; 00:30 M,T,W,Th,F,S,Su


Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\
Distributor\NodeManager\CurrentVersion\Processes\rpl
Class Name: <NO CLASS>
Last Write Time: 2/11/2015 - 11:07 PM
Value 10
Name: ImageArgs
Type: REG_SZ
Data&colon; /db lab_hds /client /name ROGGER105A /replicationport
41026 /recoveryport 41028

Neste momento, se os dados são verificados e corrigem, a próxima etapa é puxar os logs da replicação do distribuidor e do registador. O valor do traço é ajustado a 3 no pórtico diagnóstico da estrutura, que puxa os logs logo em seguida. Os logs devem mostrar os dados similares aos dois exemplos seguintes.

Estão aqui os logs da replicação do registador:

14:40:55:861 la-rpl Trace: No MATCHING entry for table t_Termination_Call_Detail,
FromRecoveryKey = 7369086520649.0 and ToRecoveryKey = 7369085626000.0

Estão aqui os logs da replicação do distribuidor:

14:29:52:607 dis-rpl Trace: Sent Replicated request to the Server for table
t_Termination_Call_Detail, FromRecoveryKey = 7369086520649.0 and
ToRecoveryKey = 7369085626000.0

A fim não compreender melhor as chaves da replicação e a nenhuma entrada de compatibilidade que aparece nos logs, as perguntas da língua de consulta estruturada (SQL) são executadas para obter mais informações sobre de todos os registadores e distribuidores.

Estão aqui as perguntas SQL:

select max(RecoveryKey) from t_Termination_Call_Detail
select max(DateTime) from t_Termination_Call_Detail

Estão aqui os resultados da pergunta SQL:

RogA - 7369086557263
HDSA - 7369086520649
RogA - 2015-04-06 15:01:47.990
HDSA - 2015-04-05 00:28:19.000

Observe que as chaves da recuperação para o registador A e o distribuidor que A está um separado significativamente mais adicional do que é esperado e do que isso no lado B. Além disso, os dados os mais recentes no distribuidor A combinam aproximadamente o lugar dos relatórios faltantes dos dados que foram observados primeiramente. Igualmente note a discrepância na distância máxima do RecoveryKey entre a tabela das perguntas e os logs.

Você pode ver a tabela da recuperação a fim determinar as chaves que são armazenadas.

Está aqui a pergunta SQL:

select max(RecoveryKey) from Recovery

Estão aqui os resultados da pergunta SQL:

HDSA - 7369090330048
RogA - EMPTY

Na saída, você pode ver que o registador A parece VAZIO, sem a chave da recuperação. Desde que estes dados são inesperados, você deve então verificar os dados na tabela da recuperação do registador A.

Está aqui a pergunta SQL:

select * from Recovery

Quando esta pergunta é executada, os resultados estão vazios, que indica que não há nenhum dados na tabela da recuperação. Neste momento, você deve reavaliar as entradas de registro. Quando os dois lados são exportados e uma comparação está feita, a discrepância está observada.

Estão aqui as entradas de registro para o registador A:

Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\
LoggerA\Recovery\CurrentVersion\Purge\Retain\System\Recovery
Class Name:        <NO CLASS>
Last Write Time:   12/8/2014 - 1:39 PM
Value 0
  Name:            Days
  Type:            REG_DWORD
  Data&colon;      0X0000001e

Estão aqui as entradas de registro para o registador B:

Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\
LoggerB\Recovery\CurrentVersion\Purge\Retain\System\Recovery
Class Name: <NO CLASS>
Last Write Time: 12/8/2014 - 1:39 PM
Value 0
Name: Days
Type: REG_DWORD
Data&colon; 0X00000e42

Como mostrado no registador A, o valor dos dias da recuperação é ajustado para 0x1e, que é (ENCANTAR) o valor hexadecimal para 30. No registador B, o valor dos dias é ajustado para 0xe42, que é o valor de HEX para 3,650. Em cima de uma revisão mais adicional com as entradas de registro do padrão no laboratório, esta parece ser a edição. Isto igualmente combina o sintoma da edição, que ocorre aproximadamente uma vez por mês.

Solução

Nota: Cisco recomenda que você executa as ações que são descritas nesta seção durante uma janela de manutenção.

A fim resolver esta edição, você deve atualizar a chave de registro a 0xe42 (3,650), que é o chave padrão:

  1. Ajuste as chaves de registro a 0xE42 (3,650).

  2. Reinicie o serviço para o registador A.

  3. Reinicie o serviço para o distribuidor A.

  4. Reinicie os serviços para o registador e o distribuidor B, se aplicável.

Nota: Esta edição está atualmente sob a investigação pelo equipe de desenvolvimento e é seguida na identificação de bug Cisco CSCuu26777.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.