Replicación del SQL Server para la Conmutación por falla del Cisco Unity Contenido Introducción prerrequisitos Requisitos Componentes Utilizados Convenciones Replicación del monitor Causas del error de la réplica de SQL Utilice el registro de acontecimientos para monitorear el servicio SQLSERVERAGENT Utilice el registro de acontecimientos para monitorear los trabajos de la replicación Utilice al administrador de empresa del SQL Server para monitorear los trabajos de la replicación SQLSERVERAGENT Determine si hasta que finalice la replicación se están procesando las transacciones Recomience los trabajos de la replicación Comience los trabajos de la replicación que no pudieron comenzar Inhabilite y vuelva a permitir la replicación Inhabilite a la falla automática, y pare el archivo y la réplica de SQL Configure la Conmutación por falla en el servidor primario Configure la Conmutación por falla en el servidor secundario Problema de la falla de Unity Problema: Reciba los errores de la réplica de SQL cada 10-15 minutos Solución Cambie que considera para poseer los trabajos de la replicación Cambie la cuenta que posee los trabajos de la replicación Otras mejoras para la supervisión de la replicación SQLSERVERAGENT: 208: '''' Programado SQL Server del chequeo de los agentes de la replicación del '''' del trabajo Información Relacionada

Introducción Cuando se configura la Conmutación por falla, el Cisco Unity utiliza la replicación 2000 del Microsoft SQL server para replicar los datos del servidor activo al servidor inactivo. Si ocurre la Conmutación por falla, la replicación de los datos se asegura de que la configuración actual y los datos del suscriptor esté disponibles en el servidor secundario y de que, después del failback, los cambios realizados en el secundario mientras que era activo se replican de nuevo al primario. La replicación es realizada por los trabajos de la replicación del SQL Server, que son funcionados con por el servicio SQLSERVERAGENT. Cuando la replicación del SQL Server se rompe, las transacciones de la replicación se guardan en las tablas del registro de auditoría en el servidor activo así que los datos se pueden replicar al servidor inactivo cuando se restablece la replicación. Si la replicación está quebrada durante un largo período, las tablas del registro de auditoría pueden llegar a ser grandes. Esto puede causar la degradación del rendimiento, que a su vez puede causar la respuesta pobre TUI y puede incluso hacer la Conmutación por falla ocurrir. Por otra parte, la base de datos del Cisco Unity en el servidor inactivo no tiene configuración más posterior y los datos del suscriptor cuando se convierte en el servidor activo.

prerrequisitos Requisitos Aseegurese que usted ha completado los requisitos para la Conmutación por falla del Cisco Unity antes de que usted configure la Conmutación por falla del Cisco Unity.

Componentes Utilizados La información en este documento se basa en el Cisco Unity 4.0(3) 5.x directo. 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.

Convenciones Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Monitoree la replicación Causas del error de la réplica de SQL La replicación puede fallar si el servicio SQLSERVERAGENT no puede comenzar y/o si los trabajos de la replicación que el servicio ejecuta el fall para comenzar. Estos errores pueden ocurrir cuando el SQL Server recomienza (por ejemplo, cuando se reinicia el servidor del Cisco Unity) como resultado de los problemas de sincronización, de las correcciones, o de la aplicación de las directivas de la Seguridad o del ordenador.

Utilice el registro de acontecimientos para monitorear el servicio SQLSERVERAGENT Si el servicio SQLSERVERAGENT no puede comenzar, un evento se abre una sesión el registro de evento del sistema. Por ejemplo: Event Type: Error Event Source: Service Control Manager Event Category: None Event ID: 7001 Date: 5/4/2007 Time: 10:58:47 PM User: N/A Computer: Description: The SQLSERVERAGENT service depends on the MSSQLSERVER service which failed to start because of the following error: The account name is invalid or does not exist, or the password is invalid for the account name specified.

Además, el Cisco Unity detecta el problema y registra este evento en el registro de eventos de aplicación. Se recomienda que usted crea el correo electrónico o las notificaciones del localizador basadas en este evento usando cualquier servicio del monitoreo de evento. Por ejemplo, el servicio del monitoreo de evento del Cisco Unity. Event Type: Warning Event Source: CiscoUnity_NodeMgr Event Category: Run Event ID: 1006 Date: 1/1/2007 Time: 9:00:00 AM User: N/A Computer: Description: The SQL Server Agent service is not running. It must be running in order for replication to take place.

Utilice el registro de acontecimientos para monitorear los trabajos de la replicación Cuando los trabajos que el servicio SQLSERVERAGENT ejecuta el fall para comenzar, por abandono, ningún evento se abren una sesión el registro de acontecimientos. Cisco recomienda que usted: Complete los pasos en el SQL Server de la configuración para registrar un evento cuando un trabajo de la replicación no puede comenzar la sección de este documento para configurar el SQL Server para registrar un evento en el registro de eventos de aplicación cuando los trabajos de la replicación no pueden comenzar. Cree el correo electrónico o las notificaciones del localizador basadas en estos eventos usando cualquier servicio del monitoreo de evento. Por ejemplo, el servicio del monitoreo de evento del Cisco Unity. SQL Server de la configuración para registrar un evento cuando un trabajo de la replicación no puede comenzar Complete estos pasos: 1. Comience al administrador de empresa del SQL Server. 2. En el panel izquierdo del administrador de empresa, amplíe el Microsoft SQL servers > el grupo de SQL Server > (local) (Windows NT) > agente de la Administración > del SQL Server, y haga clic los trabajos. 3. En el panel derecho, haga clic con el botón derecho del ratón el nombre del trabajo y elija las propiedades > las notificaciones. Vea el cuadro 1 para una lista de los trabajos de la replicación comenzada por el servicio SQLSERVERAGENT.

4. En el cuadro de diálogo Propiedades del , vaya a la lengueta de las notificaciones. 5. Marque la escritura a la casilla de verificación del registro de acontecimientos de la aplicación de Windows. 6. Haga Click en OK para cerrar el cuadro de diálogo Propiedades del . 7. Relance los pasos 3 a 6 para el resto de los trabajos para los cuales usted quiere registrar los eventos. Cuadro 1 — Trabajos de la replicación comenzados por el servicio SQLSERVERAGENT Trabajo de la replicación

Descripción

Categoría

Reinicializa todas las Reinicialice las suscripciones que suscripciones que tengan los tienen los errores de la validación errores de la validación de de datos. datos.

Respuesta de la REPL-alerta

Detecta los agentes de la replicación que no registran el historial activamente.

REPL-chequeo

Chequeo de los agentes de la replicación

SVRNAME-UnityDbUnityDbPublication-SVRNAME- Distribución del UnityDb 3

REPLdistribución

La distribución limpia: UnityDistributionDb

Removes replicó las transacciones de la base de datos de la distribución.

Limpieza de la REPLdistribución

El historial del agente limpia: UnityDistributionDb

Quita el historial del agente Limpieza del de la replicación de la base de REPL-historial datos de la distribución.

SVRNAME-UnityDb-3

UnityDb LogReader

[SVRNAME].9

Las colas de lectura para las REPLsuscripciones de puesta al día QueueReader hechas cola.

SVRNAME-UnityDbUnityDbPublication-3

Foto del UnityDb

La suscripción expirada limpia

Detecta y quita las Limpieza de la suscripciones expiradas de las REPL-suscripción bases de datos publicadas.

REPL-LogReader

REPL-foto

Utilice al administrador de empresa del SQL Server para monitorear los trabajos de la replicación SQLSERVERAGENT Utilice al administrador de empresa para determinar si los trabajos de la replicación tienen éxito Complete estos pasos: 1. En el servidor primario, comience al administrador de empresa del SQL Server. 2. En el panel izquierdo del administrador de empresa, amplíe el Microsoft SQL servers > el grupo de SQL Server > (local) (Windows NT) > agente de la Administración > del SQL Server y haga clic los trabajos. 3. En el panel derecho, cada trabajo tiene un icono que indique su éxito o error. Cualquier trabajo con un icono del rojo-punto ha fallado. Para cualquier trabajos que fallen, si es el valor de la Columna de estado: Ejecución — El icono rojo-doc. no se ha puesto al día con el estado final. Espere hasta que se haya puesto al día el icono. Para cualquier otro valor, haga clic con el botón derecho del ratón en el Nombre de trabajo, y haga clic el historial de trabajo de la visión para visualizar la razón que el trabajo falló.

Determine si hasta que finalice la replicación se están procesando las transacciones Durante una caída del sistema de la replicación, las transacciones de la replicación pueden acumular hasta que haya más que puede ser procesado mientras que el sistema maneja un volumen de la llamada normal. (La mayoría del ejemplo común de esto es un descanso ODBC en que los servidores primarios y secundarios del Cisco Unity intentan conectar con uno otro.) Después de la caída del sistema, cuando usted permite los trabajos de la replicación de ejecutarse durante un rato relativamente lento (tal como noche excesiva o durante un fin de semana), los trabajos de

la replicación pueden a menudo claro la reserva de las transacciones unreplicated. Sin embargo, si hay muchas transacciones unreplicated, las tentativas por el SQL Server de replicar los datos pueden dar lugar a un descanso. Si está funcionando la replicación pero el número de transacciones unreplicated no ha caído perceptiblemente para el final de un fin de semana, usted puede ser que necesite inhabilitar y después volver a permitir la replicación. Vea la neutralización y vuelva a permitir la sección de la replicación de este documento para más información. Utilice los comandos OSQL en esta sección de determinar si el número de transacciones unreplicated es inusualmente grande después de una interrupción y si se están procesando las más viejas transacciones. (Para un sistema con un gran número de suscriptores de Cisco Unity y mucha actividad, las transacciones que se extienden en los centenares pueden ser comunes. Las transacciones que se extienden en los millares son tema de inquietud.) Precaución: Si el número de transacciones unreplicated es muy grande, los comandos OSQL pudieron tardar un tiempo prolongado de completar y de poner la considerable carga adicional en el servidor. Complete estos pasos para visualizar una lista ordenada de las fechas en los expedientes pendientes de la replicación, que usted puede utilizar para determinar cómo es viejo es la más vieja transacción: 1. En el servidor secundario, elija el Start (Inicio) > Run (Ejecutar). 2. Ejecute el cmd. 3. En el comando prompt, funcione con este comando para comenzar el OSQL y preguntar las bases de datos Unitydb: Nota: Este comando se envuelve a una segunda línea debido a las razones espaciales.

OSQL -E -d Unitydb -Q "SELECT distinct insertdate FROM MSreplication_queue ORDER BY insertdate"

Nota: El Switches del OSQL es con diferenciación entre mayúsculas y minúsculas (por ejemplo, - E). Complete estos pasos para obtener un recuento total de los expedientes pendientes de la replicación. Usted puede funcionar con estos expedientes diariamente para determinar si el número de transacciones unreplicated es creciente o que encoge: 1. En el servidor secundario, elija el Start (Inicio) > Run (Ejecutar). 2. Ejecute el cmd. 3. En el comando prompt, funcione con este comando para comenzar el OSQL y preguntar las bases de datos Unitydb:

OSQL -E -d Unitydb -Q "SELECT count(*) FROM MSreplication_queue"

Nota: El Switches del OSQL es con diferenciación entre mayúsculas y minúsculas (por ejemplo, - E). Complete estos pasos para determinar si los datos del servidor primario están replegados al servidor secundario: 1. En el servidor primario, elija el Start (Inicio) > Run (Ejecutar). 2. Ejecute el cmd. 3. En el comando prompt, funcione con este comando para comenzar el OSQL y preguntar la base de datos de UnityDistributionDb: Nota: Este comando se envuelve a una segunda línea debido a las razones espaciales.

OSQL -E -d UnityDistributionDb -Q "SELECT SUM(UndelivCmdsInDistDB) FROM MSdistribution_status"

Trabajos de la replicación del reinicio Generalmente, si el servicio SQLSERVERAGENT o el que está de los trabajos de la replicación no puede comenzar, es debido a un problema de sincronización durante el lanzamiento. Usted puede restablecer generalmente la replicación cuando usted comienza cualquier trabajo que no pudiera comenzar.

Comience los trabajos de la replicación que no pudieron comenzar Complete estos pasos: 1. Comience al administrador de empresa del SQL Server. 2. En el panel izquierdo del administrador de empresa, amplíe el Microsoft SQL servers > el grupo de SQL Server > (local) (Windows NT) > agente de la Administración > del SQL Server y haga clic los trabajos.

3. Haga clic con el botón derecho del ratón el trabajo que no pudo comenzar y hacer clic el trabajo del comienzo. 4. Si el valor de la Columna de estado no cambia a la ejecución, revise el historial de trabajo. Haga clic con el botón derecho del ratón el trabajo, y haga clic el historial de trabajo de la visión. Cuando la causa del error se corrige, relance el paso 3 para comenzar el trabajo.

Inhabilite y vuelva a permitir la replicación Si el número de transacciones unreplicated es tan grande que los trabajos de la replicación miden el tiempo en varias ocasiones hacia fuera, y si éste evita que la replicación reduzca perceptiblemente el número de expedientes unreplicated, usted debe inhabilitar y después volver a permitir la replicación. Complete estos tres procedimientos para lograr esto: 1. Inhabilite a la falla automática, y pare el archivo y la réplica de SQL 2. Configure la Conmutación por falla en el servidor primario 3. Configure la Conmutación por falla en el servidor secundario Precaución: Si usted inhabilita y vuelve a permitir la replicación, las transacciones unreplicated (eventualmente) en el primario y los servidores secundarios se borran, y la base de datos del Cisco Unity en el servidor primario se replica al servidor secundario. Si hay algunos cambios unreplicated en el servidor secundario, se pierden esos cambios.

Falla automática de la neutralización, y archivo y réplica de SQL de la parada Complete estos pasos: 1. Si el servidor primario es activo, proceda al paso 5. Si el servidor primario no es activo, en el servidor secundario elija Start > Programs > monitor del Cisco Unity > de la Conmutación por falla. 2. Haga clic el failback. 3. Haga Click en OK para confirmar que usted quiere fallar de nuevo al servidor primario. 4. Cierre el monitor de la Conmutación por falla. 5. En el servidor primario, en el menú Start (Inicio) de Windows, elija los programas > el monitor del Cisco Unity > de la Conmutación por falla. 6. Haga clic en Advanced. 7. Marque la casilla de verificación de la falla automática y del failback de la neutralización. 8. El Haga Click en OK y cierra el monitor de la Conmutación por falla. 9. En el servidor primario, en el menú Start (Inicio) de Windows, elija el Programs (Programas) > Administrative Tools (Herramientas administrativas) > Services (Servicios). 10. En el panel derecho, haga doble clic AvCsNodeMgr. 11. En la ficha general, haga clic la parada. 12. En la lista de tipos de lanzamiento, haga clic discapacitado. 13. Haga clic en OK. 14. Cierre la ventana de los servicios. Precaución: Porque se inhabilita el servicio de Node Manager, la replicación de archivos para. Se vuelve a permitir la replicación cuando la operación de la falla normal reanuda. 15. En el servidor secundario, en el menú Start (Inicio) de Windows, elija el Programs (Programas) > Administrative Tools (Herramientas administrativas) > Services (Servicios). 16. En el panel derecho, haga doble clic AvCsNodeMgr. 17. En la ficha general, haga clic la parada. 18. En la lista de tipos de lanzamiento, haga clic discapacitado.

19. Haga clic en OK. 20. Cierre la ventana de los servicios. 21. En el servidor primario, en el menú Start (Inicio) de Windows, elija el Programs (Programas) > Microsoft SQL Server > Enterprise Manager. 22. En el panel izquierdo de la ventana de la Raíz de la consola, hojee al nodo de la replicación para el servidor primario. Típicamente, el nodo es tres niveles bajo nodo del Microsoft SQL servers. 23. Haga clic con el botón derecho del ratón el nodo de la replicación, y haga clic la publicación de la neutralización. El Asisitente de la publicación y de la distribución de la neutralización aparece. 24. En las páginas de Bienvenida, haga clic después. 25. En la página de publicación de la neutralización, haga clic sí, después haga clic después. 26. Al caer del confirmar de las publicaciones pagine, haga clic después. 27. En la página que completa, clic en Finalizar. 28. Cuando el proceso es completo, haga clic la AUTORIZACIÓN. 29. Cierre la ventana de la Raíz de la consola. 30. Salga al administrador de empresa.

Configure la Conmutación por falla en el servidor primario Complete estos pasos: 1. En el explorador Explorador de Windows, hojee al CommServer directory (Directorio CommServer). 2. Haga doble clic FailoverConfig.exe para comenzar al asistente para falla general del Cisco Unity de la configuración. 3. En las páginas de Bienvenida, haga clic después. 4. En de la página del especificar la Función del servidor, haga clic el servidor primario, y haga clic después. 5. En el ingresar el nombre de sus páginas del servidor, tecleo hojea, selecciona el nombre del servidor secundario, y hace clic la AUTORIZACIÓN. La dirección IP para el servidor secundario se completa automáticamente. 6. Haga clic en Next (Siguiente). 7. En la página de la información de la cuenta de la Conmutación por falla del ingresar, el tecleo hojea, y clic doble el nombre de la cuenta de servicios del Message Store. Ésta es la cuenta que el servicio de la Conmutación por falla abre una sesión como. La cuenta que usted selecciona debe tener el derecho de actuar como parte del sistema operativo y de abrir una sesión como servicio, y debe ser un miembro del grupo de los administradores locales. Precaución: Usted debe especificar la misma cuenta en el primario y los servidores secundarios. 8. En el campo de contraseña, ingrese la contraseña para la cuenta que el servicio de la Conmutación por falla abre una sesión como, y el tecleo después. 9. En el comenzar que configura sus páginas del servidor, haga clic la configuración. El Asisitente verifica las configuraciones y configura la Conmutación por falla en el servidor primario. Si el Asisitente no acaba la configuración con éxito, un mensaje de error explica porqué el Asisitente falló. Salga al Asisitente, corrija el problema, y haga clic la configuración otra vez. 10. En la página que completa, clic en Finalizar.

Conmutación por falla de la configuración en el servidor secundario Complete estos pasos:

1. En la barra de tareas de Windows, haga doble clic el reloj del sistema. El cuadro de diálogo Propiedades de la fecha/de la hora aparece. 2. Fije la hora a la misma hora y minuto como se muestra en el servidor primario, y la AUTORIZACIÓN del tecleo. 3. En el explorador Explorador de Windows, hojee al CommServer directory (Directorio CommServer). 4. Haga doble clic FailoverConfig.exe para comenzar al asistente para falla general del Cisco Unity de la configuración. 5. En las páginas de Bienvenida, haga clic después. 6. En de la página del especificar la Función del servidor, haga clic el servidor secundario, y haga clic después. 7. En el ingresar el nombre de sus páginas del servidor, tecleo hojea, selecciona el nombre del servidor primario, y hace clic la AUTORIZACIÓN. La dirección IP para el servidor primario se completa automáticamente. 8. Haga clic en Next (Siguiente). 9. En la página de la información de la cuenta de la Conmutación por falla del ingresar, el tecleo hojea, y clic doble el nombre de la cuenta de servicios del Message Store. Ésta es la cuenta que el servicio de la Conmutación por falla abre una sesión como. La cuenta que usted selecciona debe tener el derecho de actuar como parte del sistema operativo y de abrir una sesión como servicio, y debe ser un miembro del grupo de los administradores locales. Precaución: Usted debe especificar la misma cuenta en el primario y los servidores secundarios. 10. En el campo de contraseña, ingrese la contraseña para la cuenta que el servicio de la Conmutación por falla abre una sesión como y tecleo después. 11. En el comenzar que configura sus páginas del servidor, haga clic la configuración. El Asisitente verifica las configuraciones y configura la Conmutación por falla en el servidor secundario. Si el Asisitente no acaba la configuración con éxito, un mensaje de error explica porqué el Asisitente falló. Salga al Asisitente, corrija el problema, y haga clic la configuración otra vez. 12. En la página que completa, clic en Finalizar.

Problema de la falla de Unity Problema: Reciba los errores de la réplica de SQL cada 10-15 minutos En el visor de eventos, se recibe este mensaje de error: Event Type: Warning Event Source: CiscoUnity_NodeMgr Event Category: Run Event ID: 1014 Date: 6/25/2010 Time: 12:32:37 PM User: N/A Computer: AXLDUM01 Description: Error getting status of SQL Server replication between the primary and secondary machines. Unable to get status of SQL Server subscription to publication UnityDbPublication for AXLDUM02. Error = 0x80045510. This may be a temporary condition. If not, recreate the subscription and the publication snapshot to restore replication.

Solución Realice estos pasos para resolver este problema: 1. En el menú Start (Inicio) de Windows del servidor primario, vaya al Programs (Programas) > Microsoft SQL Server > Enterprise Manager. 2. En el panel de la izquierda, amplíe el Microsoft SQL servers > el grupo de SQL Server. 3. En el panel de la izquierda, bajo grupo de SQL Server, haga clic el . 4. En el menú Herramientas del administrador de empresa del SQL Server, haga clic la replicación > la publicación y la distribución de la neutralización. 5. En la recepción a la ventana del Asistente de la publicación y de la distribución de la neutralización, haga clic después.

6. En el cuadro de diálogo de publicación de la neutralización, haga clic sí, inhabilite la publicación en el , y haga clic después. Entonces, realice los pasos que aparecen en la pantalla para inhabilitar la publicación en el servidor primario. 7. Vuelva a efectuar al Asisitente de la configuración de failover del Cisco Unity en el servidor primario. Nota: Esté seguro de utilizar la cuenta correcta del Cisco Unity (el Unity instala) para ejecutar el FCW. 8. Vaya a los programas > al Microsoft SQL server > a la utilidad de Client Network en el servidor primario. 9. Conforme a la ficha general, confirme que los protocolos habilitados por la orden están de TCP/IP y de los Conductos mencionados como se muestra aquí:

10. Bajo la lengueta del alias, el tecleo agrega, fijó el nombre de la máquina del servidor de Unity secundario en el servidor alias, y la AUTORIZACIÓN del tecleo.

11. Semejantemente, realice los pasos a partir del 8 a 10 para el servidor secundario. Aquí en el servidor secundario bajo la lengueta del alias, el tecleo agrega y fijó el nombre del servidor de Unity primario como servidor alias, y la AUTORIZACIÓN del tecleo. 12. Vuelva a efectuar al Asisitente de la configuración de failover del Cisco Unity en el servidor secundario.

Cambie que considera para poseer los trabajos de la replicación Por abandono, el Dominio de Windows considera para poseer los trabajos de la replicación. Esto agrega una cierta complejidad introduciendo las dependencias en la autenticación de Windows y en la comunicación del establecimiento de una red. El SQL Server tiene dos cuentas incorporadas que no sean cuentas del Dominio de Windows y sean únicas al SQL Server. Para reducir las dependencias, cambie la propiedad de los trabajos de la replicación a una de estas cuentas del SQL Server: La cuenta sa es la cuenta administrativa del SQL Server incorporado. Esta cuenta tiene un nivel elevado de acceso. Se crea la cuenta del distributor_admin cuando se configura la replicación. Esta cuenta tiene un nivel inferior del acceso que la cuenta sa.

Cambie la cuenta que posee los trabajos de la replicación Complete estos pasos: 1. Comience al administrador de empresa del SQL Server. 2. En el panel izquierdo del administrador de empresa, amplíe el Microsoft SQL servers > el grupo de SQL Server > (local) (Windows NT) > agente de la Administración > del SQL Server, y haga clic los trabajos. 3. Para el primer trabajo de la replicación enumerado en el cuadro 1, haga clic con el botón derecho del ratón en el trabajo, y haga clic las propiedades. 4. En la ficha general, en la lista del propietario, haga clic el nombre de la cuenta que usted quiere para poseer el trabajo. Cisco recomienda que usted elige la cuenta del distributor_admin. 5. Haga Click en OK para cerrar el cuadro de diálogo Propiedades del . 6. Relance los pasos 3 a 5 para el resto de los trabajos en el cuadro 1. 7. Recomience todos los trabajos de la replicación: a. Para el primer trabajo de la replicación enumerado en el cuadro 1, haga clic con el botón derecho del ratón el trabajo y haga clic el trabajo de la parada. b. Haga clic con el botón derecho del ratón el trabajo y haga clic el trabajo del comienzo. c. Relance los pasos a y b para el resto de los trabajos en el cuadro 1.

Otras mejoras para la supervisión de la replicación Un problema excepcional con los trabajos de la replicación del SQL Server de la supervisión es que algunos trabajos comienzan solamente una vez, cuando se comienzan el SQL Server y el servicio SQLSERVERAGENT. Como consecuencia, si los trabajos fallan, hacen solamente un evento ser registrados. (Otros trabajos de la replicación comienzan, parada “van a dormir,” y después a recomenzar. Estos trabajos registran un error cada vez que no pueden comenzar.)

Para monitoree continuamente el estatus de los trabajos que comienzan solamente una vez, el grupo de ingeniería del Cisco Unity agrega la supervisión de los trabajos de la replicación a la supervisión existente del servicio SQLSERVERAGENT, según lo descrito anterior en este documento. Esta mejora se sigue con el Id. de bug Cisco CSCsi50517 (clientes registrados solamente).

SQLSERVERAGENT: 208: '''' Programado SQL Server del chequeo de los agentes de la replicación del '''' del trabajo En el visor de eventos, se recibe este messge del error: SQLSERVERAGENT: 208: SQL Server Scheduled Job ''''Replication agents checkup'''' (0x8666D34A10837246B4030EA4E93E50BC) - Status: Failed - Invoked on: 2009-08-19 03:30:01 - Message: The job failed. The owner () of job Replication agents checkup does not have server access.

Complete estos pasos para resolver este problema: 1. Abra el parámetro Enterprise SQL y marque los trabajos que fallan. 2. Abra las propiedades y verifiquelas que el propietario es distributor_admin solamente. 3. Recomience los trabajos.

Información Relacionada Troubleshooting de Cisco IP Telephony Notas Técnicas de Troubleshooting

© 1992-2015 Cisco Systems Inc. Todos los Derechos Reservados. Fecha de Generación del PDF: 18 Octubre 2015 http://www.cisco.com/cisco/web/support/LA/102/1027/1027825_sql-svr-rep-cu-failover.html