Crear el Seguimiento
Como administrador de bases de datos nos interesa automatizar el seguimiento de los servidores de bases de datos, de tal forma que podamos recoger lo que ha sucedido o que se nos informe al momento. Ya hemos visto qué eventos existen en las instancias de SQL Server. Ahora tenemos que usar la infraestructura estándar que nos ofrece para seguir algunos de ellos y guardarlos para poder hacer un informe diario.
Para implementar notificaciones de eventos, lo primero que tenemos que hacer es crear una cola. Es decir, lo primero que necesitamos es un lugar donde almacenar los mensajes y esto es estándar en SQL Server, que es una ventaja sobre otros sistemas de notificaciones de eventos.
Por defecto la base de datos es la actual y el esquema es el predeterminado del usuario que crea la cola. Las colas se crean disponibles por defecto y pueden empezar a recibir notificaciones. También se crean que no retengan los mensajes dado que mejora el rendimiento.
Una cola se puede asociar con un procedimiento almacenado. Cuando hay mensajes pendientes de procesar en la cola, SQL Server activa dicho procedimiento almacenado. Esto permite que se pueda dar una respuesta asincrónica, fuera de la transacción origen –como ya hemos dicho–, a eventos específicos. SQL Server puede incluso paralelizar este proceso lanzando varias instancias del procedimiento almacenado para que procese los mensajes sin que se acumulen. Como en este artículo nos interesa diseñar cómo hacer un seguimiento a los eventos, no utilizaremos esta parte de la tecnología.
En nuestro ejemplo, vamos a crear una cola con todas las opciones por defecto y sin un procedimiento almacenado, dado que consumiremos los mensajes una vez al día:
El siguiente paso es crear un servicio: «Un servicio de Service Broker es un nombre para una tarea o un conjunto de tareas específicos.» Es decir, tenemos una notificación, pero ¿cómo la enrutamos? O también, ¿hacia dónde la enrutamos?
Cuando se dice que un servicio se asocia a una cola, pero que una cola puede tener varios servicios, lo que estamos expresando es que hay varios caminos por los que puede recibir mensajes la cola. Aunque generalmente la relación es uno a uno por simplicidad.
El servicio se crea siempre en la base de datos actual y no se puede especificar un esquema.
Para recibir notificaciones, solo es necesario crear el servicio de destino, dado que Service Broker incluye «de fábrica» el tipo de mensaje y contrato para notificaciones de eventos. En efecto, al definir un servicio, podemos poner un contrato que especifica el tipo de mensajes que se van a enviar a la cola. Pero como estamos usando un estándar de SQL Server, el proceso se simplifica bastante al referenciar un contrato estándar para las notificaciones de eventos. Veámoslo:
¿Los servicios no servían para enrutar? Bueno, estamos viendo una versión simplificada de Service Broker: el servicio sirve para distintos tipos de mensajes, pero provee una estructura estándar para las notificaciones de eventos. Por lo tanto creamos una ruta en el servicio para definir la dirección a la que Service Broker envía los mensajes.
Como nuestras notificaciones de eventos tienen como destino un servicio en la misma instancia, ponemos ‘LOCAL’. El nombre del servicio tiene que ser exactamente igual al que hemos creado, pues se usa una comparación bit a bit para buscarlo. Tengamos en cuenta que Service Broker puede trabajar con bibliotecas externas –es el caso del correo electrónico de base de datos– o con otros servidores. Al no especificar BROKER_INSTANCE, la ruta coincide con todas las instancias de bróker.
Debemos aclarar que en este caso no sería necesaria la ruta pues por defecto el mensaje se entregaría localmente, pero lo añadimos para ver el ejemplo completo.
La definición nuestra sería:
Ya tenemos el receptor de los eventos y cómo mandárselos. Nos queda por fin definir qué eventos queremos seguir. Como vemos, hay que construir el edificio comenzando por la base y terminando con qué le vamos a mandar.
Los eventos pueden ser de servidor o de base de datos: en nuestro caso queremos el crecimiento de cualquier fichero, por lo que el ámbito es la instancia (ON SERVER). Como queremos un solo evento aunque se creen varias notificaciones –que no es nuestro caso–, utilizamos la cláusula WITH FAN_IN. Podemos pedir tipos de eventos, pero también grupos de eventos. Como hemos visto, el grupo incluye un evento que no necesitamos, por lo que especificamos los eventos.
Tenemos que especificar el servicio que hemos creado. Una cosa que tenemos que tener en cuenta es que SQL Server puede abrir una o más conversaciones al servicio destino, por lo que luego tendremos que circular por todas las conversaciones en caso de que haya más de una. Por último, hay que especificar la instancia de Service Broker, que al ser todo en la base de datos actual, podemos ponerlo así, ‘current database’.
Con esto ya tendríamos definido el seguimiento de los eventos de fichero:
Para comprobar los eventos creados, acudimos a las vistas del catálogo correspondientes:
La primera pertenece al catálogo de Service Broker y nos da los datos de cada cola de servicio. La segunda también es del mismo catálogo y nos da los servicios, donde está incluido el que acabamos de crear. La tercera nos da las rutas donde aparecen la creada por defecto para los eventos que no tienen definido un enrutamiento y la que hemos creado. Por último, como hemos creado una notificación de servidor, utilizamos la vista del catálogo de objetos para ver la notificación nuestra.
En caso de que hubiésemos creado una notificación de base de datos, dentro de la misma base de datos usaríamos sys.event_notifications.
Para ver los eventos que se están capturando, como son eventos de servidor, tenemos que usar:
En el presente artículo hemos visto los sencillos pasos que hay que dar para la creación de cualquier tipo de seguimiento de eventos mediante Service Broker, con un ejemplo para saber si se modifica el tamaño de un fichero. No hemos entrado en profundidad en las posibilidades de Service Broker y de las colas de SQL Server, pero sí hemos dado un empujón interesante para empezar a usarlo y bucear en sus posibilidades.
¿Cómo procesamos esas notificaciones? Veremos un ejemplo en nuestro siguiente artículo.
Ir a…
ÚLTIMAS NOTÍCIAS
Novedades de Global Mapper v26.017/09/2024 - 18:00
Madrid Tech Show 202416/09/2024 - 16:04
Novedades de Delphi 12.210/09/2024 - 17:58
Navicat BI – Libere el poder de los datos.10/09/2024 - 11:34
Dejar un comentario
¿Quieres unirte a la conversación?¡Siéntete libre de contribuir!