Introducción
Este documento describe los pasos para resolver problemas cuando el maderero A y B UCCE se pega en un estado de inicialización.
Contribuido por Pratham Prakash, ingeniero del software de Cisco.
Prerrequisitos
Requisitos
Cisco recomienda que tenga conocimiento sobre estos temas:
- Cisco UCCE
- Lenguaje de consulta estructurado (SQL) de Micrsoft
Componentes Utilizados
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.
Problema
El análisis del registro reveló que el maderero A y B UCCE está pegado en un estado de la inicialización. Los madereros en los ambos lados no se convertirán en active y los madereros mantienen el causar un crash con una conexión del bcp de la excepción agotado. Un ejemplo del mensaje de error para esta condición se puede encontrar en los archivos del 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
Esto está ocurriendo porque hay claves duplicadas encontradas en la tabla t_Persistent_Variable. Ninguno de los dos madereros A y B puede completar la inicialización.
Solución
Esta condición puede ocurrir al usar las variables persistentes en UCCE libera 10.x ThedDefect “tabla t_Persistent_Variable CSCuw02024 que borra y el re-agregar registra”.
Perform después de la solución alternativa
Paso 1. Fije la clave de registro siguiente en el lado A del ogger y el lado B del maderero del valor 1 a 0
HKEY_LOCAL_MACHINE \ software \ Geotel \ ICR \ Customerinstance \ LoggerB \ maderero \ HistoricalData \ persistente
Paso 2. Derribe un lado
1) trunca el Persistent_VariableTmp1, el Persistent_VariableTmp2 y las tablas t_Persistent_Variable en abajo el lado.
2) trunca el Persistent_VariableTmp1, el Persistent_VariableTmp2 y las tablas t_Persistent_Variable en el lado activo.
Paso 3 Servicio de registrador del reinicio en el ambambos lado A y el lado B
Paso 4 Realice la prueba para aseegurarse a los usuarios pueden realizar los cambios de configuración.
Paso 5 La llamada de prueba del lugar en el sistema para verificar las llamadas está trabajando.
Paso 6 Puede todavía ser neeccesary ejecutar el exit_router, fue encontrado que el sistema es en servicio, y los ambos lados del Routers completaron la transferencia del estado tomando la configuración del maderero del lado A. Aunque el sistema del Centro de contacto es que se ejecuta y de trabajo, todavía DB del maderero del lado B en el estado de inicialización. Esto ocurrió cuando la clave de la recuperación del maderero del lado B es maderero de retardamiento del lado A por la gran cantidad.
Paso 7 Ejecución del DB manual de los config de A --> B
Datos manuales realizados de los config de la exportación/de la importación de A --> B
Aunque el lastUpdatekey se corresponde con entre el Side a y B, el clgr del maderero B se quejó de un error de checksum. Realice el DB manual de los config del maderero sincronizan con el ICMDBA para prevenir el error de checksum.
Realizado más adelante debajo de los pasos para resolver el problema de la suma de comprobación
1. Cambio de configuración parado cambiando la clave de registro de DBMaintnenance a 1
2. Sostuvo la base de datos entera del maderero A en el MSSQL. Y transferido el respaldo DB al servidor del maderero B.
3. Base de datos caída del maderero B, y reconstruido la base de datos del maderero B.
4. Restableció el DB del maderero en el maderero B del respaldo DB del maderero A.
5. Respaldo accionado del servicio del maderero B.
6. Reajuste la clave de registro de DBMaintenance a 0
Verificado
1. Router rttest ha establecido con éxito la conexión MDS con los procesos del maderero B, incluyendo los etcs CLGR, HLGR, RCV.
2. El maderero B no sale del MDS debido al error de checksum de los datos.
3. Puesto que el maderero B ha estado en el estado de cierre normal por algunos días, el sistema ahora está sincronizando activamente los datos históricos con el HDS.
4. El cambio de configuración todavía está trabajando
Comentarios