Administrar eventos
se aplica a:
SQL Serverazure SQL Managed Instance
Importante
En Instancia administrada de Azure SQL, la mayoría de las funcionalidades del Agente SQL Server, pero no todas, son compatibles actualmente. Consulte diferencias de T-SQL de Azure SQL Managed Instance con respecto a SQL Server para más información.
Puede reenviar a una instancia de SQL Server todos los mensajes de eventos que cumplan o superen un nivel de gravedad de error específico. 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 usar el reenvío de eventos para centralizar la administración de alertas para un grupo de servidores, lo que reduce la carga de trabajo en servidores muy usados.
Cuando un servidor recibe eventos para un grupo de otros servidores, el servidor que recibe eventos se denomina servidor de administración de alertas . En un entorno multiservidor, designa el servidor maestro como servidor de administración de alertas.
Ventajas de usar un servidor de administración de alertas
Entre las ventajas de configurar un servidor de administración de alertas se incluyen:
centralización. El control centralizado y una vista consolidada de los eventos de varias instancias de SQL Server son posibles desde un único servidor.
escalabilidad. Muchos servidores físicos se pueden administrar como un servidor lógico. Puede agregar o quitar servidores a este grupo de servidores físicos según sea necesario.
Eficiencia. Se reduce el tiempo de configuración, ya que necesita definir alertas y operadores solo una vez.
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:
aumento del tráfico. El reenvío de eventos a un servidor de administración de alertas puede aumentar el tráfico de red. Este aumento se puede moderar al restringir el reenvío de eventos a eventos que están por encima de un nivel de gravedad designado.
Punto único de falla. Si el servidor de administración de alertas deja de estar sin conexión, no se emiten alertas para ningún evento en el grupo administrado de servidores.
Carga del servidor. El control de alertas para los eventos reenviados provoca un aumento de la carga de procesamiento en el servidor de administración de alertas.
Directrices para usar un servidor de administración de alertas
Al configurar un servidor de administración de alertas, siga estas instrucciones:
Para recibir eventos reenviados, el servidor de administración de alertas debe ser una instancia predeterminada de SQL Server.
Evite ejecutar aplicaciones críticas o muy usadas en el servidor de administración de alertas.
Planee cuidadosamente el tráfico de red implicado en la configuración de muchos servidores para compartir el mismo servidor de administración de alertas. Si se produce un resultado de congestión, reduzca el número de servidores que usan un servidor de administración de alertas determinado.
Los servidores registrados en SQL Server Management Studio constituyen la lista de servidores disponibles para ser elegidos por ese servidor como 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 ve todos los servidores que lo reenvían como una unidad lógica. Por ejemplo, un servidor de administración de alertas responde de la misma manera a un evento 605 del servidor A y un evento 605 del servidor B.
Después de configurar el sistema de alertas, compruebe periódicamente el registro de aplicaciones de Microsoft Windows para ver los eventos del Agente SQL Server.
Las condiciones de error detectadas por el motor de alertas se escriben en el registro de aplicaciones de Windows local con un nombre de origen de "Agente SQL Server". Por ejemplo, si el Agente SQL Server no puede enviar una notificación por correo electrónico tal como se ha definido, se registra un evento en el registro de la aplicación.
Si se inactiva una alerta definida localmente y se produce un evento que habría provocado el desencadenamiento de la alerta, el evento se reenvía al servidor de administración de alertas (si satisface la condición de reenvío de alertas). Este reenvío permite desactivar y activar las anulaciones locales (alertas definidas localmente que también están definidas en el servidor de administración de alertas) según las necesidades del usuario en el sitio local. También puede solicitar que los eventos siempre se reenvíen, incluso si también se gestionan mediante alertas locales.
A continuación se muestran tareas comunes para administrar eventos en un entorno multiservidor:
Para designar un servidor de administración de alertas
Definir la respuesta a una alerta
Ejecución de los trabajos de Event-Triggered
Puede definir un trabajo que se va a ejecutar en respuesta a una alerta. Por ejemplo, puede ejecutar un trabajo que corrija o diagnostique aún más un problema detectado por la alerta.
Nota
Dado que un trabajo puede generar un evento, tenga cuidado de no crear un bucle de trabajo de alerta recursivo.