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
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
Feedback