Voz y Comunicaciones unificadas : Cisco Unity

Replicación del SQL Server para la Conmutación por falla del Cisco Unity

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


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 siente bien al 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:		<servername>
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:		<servername> 
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:

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 <job>, 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 <job>.

  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
Reinicialice las suscripciones que tienen los errores de la validación de datos. Reinicializa todas las suscripciones que tengan los errores de la validación de datos. Respuesta de la REPL-alerta
Chequeo de los agentes de la replicación Detecta los agentes de la replicación que no registran el historial activamente. REPL-chequeo
SVRNAME-UnityDb-UnityDbPublication-SVRNAME-3 Distribución del UnityDb REPL-distribución
La distribución limpia: UnityDistributionDb Removes replicó las transacciones de la base de datos de la distribución. Limpieza de la REPL-distribución
El historial del agente limpia: UnityDistributionDb Quita el historial del agente de la replicación de la base de datos de la distribución. Limpieza del REPL-historial
SVRNAME-UnityDb-3 UnityDb LogReader REPL-LogReader
[SVRNAME].9 Las colas de lectura para las suscripciones de puesta al día hechas cola. REPL-QueueReader
SVRNAME-UnityDb-UnityDbPublication-3 Foto del UnityDb REPL-foto
La suscripción expirada limpia Detecta y quita las suscripciones expiradas de las bases de datos publicadas. Limpieza de la REPL-suscripción

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 Precaución: Si el número de transacciones unreplicated es muy grande, los comandos OSQL pudieron tardar un tiempo prolongado para completar y para 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 la base 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 la base 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 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 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 la página de Bienvenida, haga clic después.

  25. En la página de publicación de la neutralización, haga clic , 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 la página de Bienvenida, haga clic después.

  4. En de la página del especificar la Función del servidor, haga clic al servidor primario, y haga clic después.

  5. En el ingresar el nombre de su página 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 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 su página 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 la página de Bienvenida, haga clic después.

  6. En de la página del especificar la Función del servidor, haga clic al servidor secundario, y haga clic después.

  7. En el ingresar el nombre de su página 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 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 su página 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 <servername>.

  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 <servername>, 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í:

    http://www.cisco.com/c/dam/en/us/support/docs/unified-communications/unity/91961-sql-svr-rep-cu-failover-01.gif

  10. Bajo 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.

    http://www.cisco.com/c/dam/en/us/support/docs/unified-communications/unity/91961-sql-svr-rep-cu-failover-02.gif

    http://www.cisco.com/c/dam/en/us/support/docs/unified-communications/unity/91961-sql-svr-rep-cu-failover-03.gif

  11. Semejantemente, realice los pasos a partir del 8 a 10 para el servidor secundario. Aquí en el servidor secundario bajo 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 <job>.

  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:

    1. 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.

    2. Haga clic con el botón derecho del ratón el trabajo y haga clic el trabajo del comienzo.

    3. 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


Document ID: 91961