Índice

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Problema

Solução

Executado mais tarde abaixo das etapas para resolver a edição da soma de verificação

Verificado

Introdução

Este documento descreve as etapas para pesquisar defeitos quando o registador A e B UCCE é colado em um estado inicializando.

Contribuído por Pratham Prakash, coordenador do software Cisco.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

- Cisco UCCE

- Língua de consulta estruturada (SQL) de Micrsoft

Componentes Utilizados

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 análise do log revelou que o registador A e B UCCE está colado em um estado da iniciação.  Os registadores em ambos os lados não se transformarão active e os registadores mantêm-se causar um crash com uma conexão do bcp da exceção esgotado.  Um exemplo do Mensagem de Erro para esta circunstância pode ser encontrado nos arquivos de registro.

14:09:45:286 la-rcv Trace: SQL Server User Error: 2627, State 1, Severity: 14, Message:

Violation of PRIMARY KEY constraint 'XPKPeripheral_Interval'. Cannot insert duplicate key

in object 'dbo.t_Peripheral_Interval'. The duplicate key value is (Jul 3 2015 12:30PM,

5002, 300, 1).

14:09:45:335 la-rcv Trace: Duplicate key ignored because the record already exist in the

database.

14:09:45:335 la-rcv Trace: bcp_done failed

Isto está ocorrendo porque há umas chaves duplicadas encontradas na tabela t_Persistent_Variable. Nenhum registador A e B pode terminar a iniciação.

Solução

Esta circunstância pode ocorrer ao usar variáveis persistentes em UCCE libera 10.x ThedDefect “tabela t_Persistent_Variable CSCuw02024 que suprime e adicionar novamente grava”.

Perform depois da ação alternativa

Etapa 1. Ajuste a seguinte chave de registro no lado A do ogger e o lado B do registador do valor 1 a 0

HKEY_LOCAL_MACHINE \ software \ GeoTel \ ICR \ Customerinstance \ LoggerB \ registador \ HistoricalData \ persistente

Etapa 2. Derrube um lado

1) trunca o Persistent_VariableTmp1, o Persistent_VariableTmp2 e as tabelas t_Persistent_Variable para baixo no lado.

2) truncam o Persistent_VariableTmp1, o Persistent_VariableTmp2 e as tabelas t_Persistent_Variable no lado ativo.

Etapa 3 Serviço de logger do reinício no ambos os lados A e no lado B

Etapa 4 Execute o teste para certificar-se que os usuários podem fazer alterações de configuração.

A chamada de teste do lugar da etapa 5 no sistema para verificar atendimentos está trabalhando.

A etapa 6 pode ainda ser neeccesary executar o exit_router, encontrou-se que o sistema é em serviço, e os ambos os lados do Roteadores terminaram transferência do estado tomando a configuração do registador do lado A. Embora o sistema do Contact Center é sendo executado e de trabalho, DB do registador do lado B ainda no estado inicializando.  Isto ocorreu quando a chave da recuperação do registador do lado B é registador de retardamento do lado A pela quantia enorme.

Etapa 7 que executa o DB manual da configuração de A --> B

Dados manuais executados da configuração da exportação/importação de A --> B

Embora o lastUpdatekey é combinado entre o lado A e lado B, o clgr do registador B queixou-se de um erro de checksum. Execute a sincronização manual DB da configuração do registador com o ICMDBA para impedir o erro de checksum.

Executado mais tarde abaixo das etapas para resolver a edição da soma de verificação

1. Alteração de configuração parada mudando a chave de registro de DBMaintnenance a 1

2. Suportou o base de dados inteiro do registador A no MSSQL. E transferido o backup DB ao server do registador B.

3. Base de dados deixado cair do registador B, e recreado o base de dados do registador B.

4. Restaurou o DB do registador no registador B do backup DB do registador A.

5. Backup posto do serviço do registador B.

6. Restaure a chave de registro de DBMaintenance a 0

Verificado

1. O rttest de roteador estabeleceu com sucesso a conexão MDS com os processos do registador B, incluindo etcs CLGR, HLGR, RCV.

2. O registador B não sai do MDS devido ao erro de checksum dos dados.

3. Desde que o registador B esteve no estado de fechamento por alguns dias, o sistema é agora ativamente dados históricos em sincronismo com HDS.

4. A alteração de configuração ainda está funcionando