Compartir a través de

Notificaciones de eventos

Las notificaciones de eventos envían información sobre eventos a un servicio de Service Broker. Las notificaciones de eventos se ejecutan en respuesta a una variedad de Transact-SQL instrucciones de lenguaje de definición de datos (DDL) y eventos de seguimiento de SQL mediante el envío de información sobre estos eventos a un servicio de Service Broker.

Las notificaciones de eventos se pueden usar para hacer lo siguiente:

  • Registre y revise los cambios o la actividad que se producen en la base de datos.

  • Realice una acción en respuesta a un evento de forma asincrónica en lugar de sincrónica.

Las notificaciones de eventos pueden ofrecer una alternativa de programación a los desencadenadores DDL y el seguimiento de SQL.

Ventajas de las notificaciones de eventos

Las notificaciones de eventos se ejecutan de forma asincrónica, fuera del ámbito de una transacción. Por lo tanto, a diferencia de los desencadenadores DDL, las notificaciones de eventos se pueden usar dentro de una aplicación de base de datos para responder a eventos sin usar ningún recurso definido por la transacción inmediata.

A diferencia del seguimiento de SQL, las notificaciones de eventos se pueden usar para realizar una acción dentro de una instancia de SQL Server en respuesta a un evento de seguimiento de SQL.

Las aplicaciones que se ejecutan junto con SQL Server pueden usar datos de eventos para realizar un seguimiento del progreso y tomar decisiones. Por ejemplo, la siguiente notificación de evento envía un aviso a un servicio determinado cada vez que se emite una instrucción ALTER TABLE en la base de datos de ejemplo AdventureWorks2012.

USE AdventureWorks2012;  
GO  
CREATE EVENT NOTIFICATION NotifyALTER_T1  
ON DATABASE  
FOR ALTER_TABLE  
TO SERVICE '//Adventure-Works.com/ArchiveService' ,  
    '8140a771-3c4b-4479-8ac0-81008ab17984';

Conceptos de notificaciones de eventos

Cuando se crea una notificación de eventos, se abren una o varias conversaciones de Service Broker entre una instancia de SQL Server y el servicio de destino que especifique. Las conversaciones normalmente permanecen abiertas siempre que la notificación de eventos exista como un objeto en la instancia del servidor. En algunos casos de error, las conversaciones pueden cerrarse antes de que se quite la notificación de eventos. Estas conversaciones nunca se comparten entre las notificaciones de eventos. Cada notificación de eventos tiene sus propias conversaciones exclusivas. Finalizar una conversación impide explícitamente que el servicio de destino reciba más mensajes y la conversación no se volverá a abrir la próxima vez que se active la notificación de eventos.

La información de eventos se entrega al servicio Service Broker como una variable de tipo xml que proporciona información sobre cuándo se produce un evento, sobre el objeto de base de datos afectado, la instrucción por lotes Transact-SQL implicada y otra información. Para obtener más información sobre el esquema XML generado por las notificaciones de eventos, vea EVENTDATA (Transact-SQL).

Notificaciones de eventos frente a desencadenadores

En la tabla siguiente se comparan y contrastan los desencadenadores y las notificaciones de eventos.

Desencadenadores Notificaciones de eventos
Los desencadenadores DML responden a eventos del lenguaje de manipulación de datos (DML). Los desencadenadores DDL responden a eventos del lenguaje de definición de datos (DDL). Las notificaciones de eventos responden a eventos DDL y a un subconjunto de eventos de seguimiento de SQL.
Los desencadenadores pueden ejecutar código administrado Transact-SQL o Common Language Runtime (CLR). Las notificaciones de eventos no ejecutan código. En su lugar, envían xml mensajes a un servicio de Service Broker.
Los desencadenadores se procesan sincrónicamente, dentro del ámbito de las transacciones que hacen que se activen. Las notificaciones de eventos pueden procesarse de forma asincrónica y no se ejecutan dentro del ámbito de las transacciones que las desencadenan.
El consumidor de un desencadenador está estrechamente unido al evento que hace que se active. El consumidor de una notificación de un evento está desacoplado del evento que causa su activación.
Los desencadenadores se deben procesar en el servidor local. Las notificaciones de eventos se pueden procesar en un servidor remoto.
Los desencadenadores se pueden revertir. No se pueden revertir las notificaciones de eventos.
Los nombres de desencadenador DML tienen ámbito de esquema. Los nombres de los desencadenadores DDL tienen ámbito de base de datos o de servidor. Los nombres de notificación de eventos están definidos por el servidor o la base de datos. Las notificaciones de eventos para un evento QUEUE_ACTIVATION están limitadas a una cola específica.
Los desencadenadores DML tienen el mismo propietario que las tablas a las que se aplican. El propietario de una notificación de eventos en una cola puede tener un propietario diferente al del objeto sobre el cual se aplica.
Los desencadenadores admiten la cláusula EXECUTE AS. Las notificaciones de eventos no admiten la cláusula EXECUTE AS.
La información de eventos del desencadenador DDL se puede capturar mediante la función EVENTDATA, que devuelve un xml tipo de datos. Las notificaciones de eventos envían xml información de eventos a un servicio de Service Broker. La información tiene el formato del mismo esquema que el de la función EVENTDATA.
Los metadatos sobre los desencadenadores se encuentran en las vistas de catálogo sys.triggers y sys.server_triggers . Los metadatos sobre las notificaciones de eventos se encuentran en las vistas de catálogo de sys.event_notifications y sys.server_event_notifications .

Notificaciones de eventos vs. Seguimiento de SQL

En la tabla siguiente se comparan y contrastan las notificaciones de eventos y el seguimiento de SQL para supervisar eventos del servidor.

Seguimiento de SQL Notificaciones de eventos
El seguimiento de SQL no genera ninguna sobrecarga de rendimiento asociada a las transacciones. El empaquetado de datos es eficaz. Hay una sobrecarga de rendimiento asociada a la creación de los datos de eventos con formato XML y el envío de la notificación de eventos.
El seguimiento de SQL puede supervisar cualquier clase de evento de traza. Las notificaciones de eventos pueden supervisar un subconjunto de clases de eventos de seguimiento y también todos los eventos del lenguaje de definición de datos (DDL).
Puede personalizar las columnas de datos que se van a generar en un evento de seguimiento. Se ha corregido el esquema de los datos de eventos con formato XML devueltos por las notificaciones de eventos.
Los eventos de seguimiento generados por DDL siempre se generan, independientemente de si la instrucción DDL se revierte. Las notificaciones de eventos no se activan si el evento de la instrucción DDL correspondiente se revierte.
Administrar el flujo intermedio de datos de eventos de seguimiento implica rellenar y administrar archivos de seguimiento o tablas de seguimiento. La administración intermedia de los datos de notificación de eventos se realiza automáticamente a través de colas de Service Broker.
Los seguimientos deben reiniciarse cada vez que se reinicie el servidor. Después de registrarse, las notificaciones de eventos se conservan en los ciclos del servidor y se realizan transacciones.
Después de iniciarse, no se puede controlar la activación de seguimientos. Los tiempos de detención y los tiempos de filtro se pueden usar para especificar cuándo se inician. Para acceder a los seguimientos, consulte el archivo de seguimiento correspondiente. Las notificaciones de eventos se pueden controlar utilizando la instrucción WAITFOR en la cola que recibe el mensaje generado por la notificación de eventos. Se puede acceder a ellos sondeando la cola.
ALTER TRACE es el permiso mínimo necesario para crear un seguimiento. También se requiere permiso para crear un archivo de seguimiento en el equipo correspondiente. El permiso mínimo depende del tipo de notificación de eventos que se va a crear. El permiso RECEIVE también es necesario en la cola correspondiente.
Las trazas se pueden recibir de forma remota. Las notificaciones de eventos se pueden recibir de forma remota.
Los eventos de seguimiento se implementan mediante procedimientos almacenados del sistema. Las notificaciones de eventos se implementan mediante una combinación de instrucciones de motor de base de datos y servicio BrokerTransact-SQL.
Se puede acceder a los datos de eventos de seguimiento mediante programación consultando la tabla de seguimiento correspondiente, analizando el archivo de seguimiento o usando la clase TraceReader objetos de administración de SQL Server (SMO). Se accede a los datos de eventos mediante programación mediante la emisión de XQuery en los datos de eventos con formato XML o mediante las clases de eventos SMO.

Tareas de notificación de eventos

Tarea Tema
Describe cómo crear e implementar notificaciones de eventos. Implementar notificaciones de eventos
Describe cómo configurar la seguridad del cuadro de diálogo de Service Broker para las notificaciones de eventos que envían mensajes a un agente de servicio en un servidor remoto. Configurar la seguridad del cuadro de diálogo para las notificaciones de eventos
Describe cómo devolver información sobre las notificaciones de eventos. Obtener información sobre las notificaciones de eventos

Véase también

Desencadenadores DDL
Desencadenadores DML
Seguimiento de SQL