Administrar eventos
Puede reenviar todos los mensajes de eventos que tengan o superen un nivel de gravedad de error específico a una instancia de SQL Server. Esto se denomina reenvío de eventos. El servidor de reenvío es un servidor dedicado que también puede ser un servidor maestro. Puede utilizar el reenvío de eventos para centralizar la administración de alertas para un grupo de servidores, con lo que se reduce la carga de trabajo de los servidores con un alto grado de utilización.
Un servidor que recibe eventos para un grupo de servidores distintos se denomina servidor de administración de alertas. En un entorno multiservidor, el servidor maestro se designa como servidor de administración de alertas.
Ventajas del uso de un servidor de administración de alertas
Entre las ventajas de configurar un servidor de administración de alertas se incluyen las siguientes:
Centralización. Es posible un control centralizado y una vista consolidada de los eventos de varias instancias de SQL Server desde un único servidor.
Escalabilidad. Se pueden administrar muchos servidores físicos como un servidor lógico. Puede agregar o quitar servidores en este grupo de servidores físicos, según sea necesario.
Eficacia. El tiempo de configuración disminuye gracias a que solo debe definir una vez las alertas y los operadores.
Desventajas del uso de un servidor de administración de alertas
Entre las desventajas de configurar un servidor de administración de alertas se incluyen las siguientes:
Aumento del tráfico. El reenvío de eventos a un servidor de administración de alertas puede aumentar el tráfico de la red. Este aumento se puede moderar si se limita el reenvío a eventos que superan un nivel de gravedad especificado.
Único punto de error. Si el servidor de administración de alertas se deja sin conexión, no se emite ninguna alerta para los eventos del grupo de servidores administrado.
Sobrecarga del servidor. La administración de alertas de los eventos reenviados provoca un aumento de la carga de procesamiento en el servidor de administración de alertas.
Directrices de uso de un servidor de administración de alertas
Al configurar un servidor de administración de alertas, siga las siguientes directrices:
Para recibir eventos reenviados, el servidor de administración de alertas debe ser una instancia predeterminada de SQL Server.
Evite ejecutar aplicaciones muy importantes o con un alto grado de uso en el servidor de administración de alertas.
Planee cuidadosamente el tráfico de red ocasionado por la configuración de muchos servidores para compartir el mismo servidor de administración de alertas. Si se produce una congestión, reduzca el número de servidores que utilizan un servidor de administración de alertas determinado.
Los servidores registrados en SQL Server Management Studio en un servidor concreto constituyen la lista de servidores disponibles entre los que ese servidor puede elegir el servidor de reenvío de alertas.
Defina alertas en la instancia local de SQL Server que requieran una respuesta específica del servidor, en lugar de reenviar las alertas al servidor de administración de alertas.
El servidor de administración de alertas considera a todos los servidores que le reenvían alertas como un único servidor lógico. Por ejemplo, un servidor de administración de alertas responde de la misma manera a un evento 605 del servidor A que a un evento 605 del servidor B.
Tras configurar el sistema de alertas, compruebe periódicamente si hay eventos del Agente SQL Server en el registro de aplicación de Microsoft Windows.
Las condiciones de error encontradas por el motor de alertas se escriben en el registro de aplicación Windows local con el nombre de origen "Agente SQL Server". Por ejemplo, si el Agente SQL Server no puede enviar una notificación de correo electrónico como se ha definido, se escribirá un evento en el registro de aplicación.
Si se desactiva una alerta definida localmente y se produce un evento que habría causado la activación de la alerta, el evento se reenviará al servidor de administración de alertas (si cumple la condición para el reenvío de alertas). Este reenvío permite al usuario activar y desactivar suplantaciones locales (alertas definidas localmente que también están definidas en el servidor de administración de alertas) según sea necesario, en el sitio local. También puede solicitar que se reenvíen siempre los eventos, aunque también se controlen mediante alertas locales.
A continuación se presentan tareas habituales para administrar eventos en un entorno multiservidor:
Para designar un servidor de administración de alertas
Para definir la respuesta a una alerta
Ejecutar trabajos desencadenados por eventos
Puede definir la ejecución de un trabajo en respuesta a una alerta. Por ejemplo, puede ejecutar un trabajo que solucione o diagnostique más exhaustivamente un problema detectado mediante la alerta.
[!NOTA]
Dado que un trabajo puede activar un evento, tenga cuidado de no crear un bucle recursivo de trabajos y alertas.