Compartir a través de


Trabajar con el proveedor WMI para eventos de servidor

En este tema se proporcionan instrucciones que deben tenerse en cuenta antes de programar con el proveedor WMI para eventos del servidor.

Habilitar Service Broker

El proveedor WMI para eventos del servidor funciona traduciendo las consultas WQL para los eventos en notificaciones de eventos en la base de datos de destino. Entender la forma en que funcionan las notificaciones de eventos puede resultar de gran utilidad a la hora de programar con el proveedor. Para obtener más información, vea Notificaciones de eventos (motor de base de datos).

En concreto, debido a que las notificaciones de eventos creadas por el proveedor WMI usan SQL Server para enviar mensajes sobre eventos del servidor, este servicio debe estar habilitado dondequiera que se generen los eventos. Si su programa consulta los eventos en una instancia del servidor, Service Broker debe habilitarse en la base de datos msdb de dicha instancia, porque ésa es la ubicación del servicio Service Broker de destino (denominado SQL/Notifications/ProcessWMIEventProviderNotification/v1.0) creado por el proveedor. Si su programa consulta eventos en una base de datos o en un objeto de base de datos determinado, Service Broker debe habilitarse en dicha base de datos de destino. Si el Service Broker correspondiente no está habilitado una vez implementada la aplicación, los eventos generados por la notificación de eventos subyacentes se envían a la cola del servicio usada por la notificación de eventos, pero no se devuelven a la aplicación de administración WMI hasta que se habilita Service Broker.

La consulta siguiente determina qué Service Broker está habilitado en una instancia del servidor y el GUID de la instancia del Service Broker:

SELECT name, is_broker_enabled, service_broker_guid FROM sys.databases;

El GUID del Service Broker de msdb tiene especial interés porque se trata de la ubicación del servicio de destino del proveedor.

Para habilitar Service Broker en una base de datos, use la opción ENABLE_BROKER SET de la instrucción ALTER DATABASE.

Especificar una cadena de conexión

Las aplicaciones dirigen el proveedor WMI para eventos del servidor a una instancia de SQL Server mediante la conexión a un espacio de nombres WMI definido por el proveedor. El servicio WMI de Windows asigna este espacio de nombres al archivo DLL del proveedor, Sqlwep.dll, y lo carga en memoria. Cada instancia de SQL Server tiene su propio espacio de nombres WMI, cuyo valor predeterminado es: \\.\raíz\Microsoft\SqlServer\ServerEvents\instance_name. instance_name toma el valor predeterminado MSSQLSERVER en una instalación predeterminada de SQL Server.

Permisos y autenticación del servidor

Para obtener acceso al proveedor WMI para eventos del servidor, el cliente donde se origina una aplicación de administración WMI debe corresponderse con el grupo o el inicio de sesión autenticado de Windows de la instancia de SQL Server especificada en la cadena de conexión de la aplicación.

Permisos y ámbito de las notificaciones de eventos

El proveedor WMI para eventos del servidor traduce las consultas WQL en notificaciones de eventos en la base de datos de destino. Por ello, la aplicación que realiza la llamada no sólo debe disponer de los permisos mínimos necesarios para obtener acceso al proveedor, sino que también debe disponer de los permisos correctos en la base de datos para crear las notificaciones de eventos necesarias. A continuación se indican los permisos necesarios:

  • Para crear una notificación de eventos en el ámbito de la base de datos se requiere, como mínimo, el permiso CREATE DATABASE DDL EVENT NOTIFICATION en la base de datos actual.

  • Para crear una notificación de eventos en una instrucción DDL incluida en el ámbito del servidor se requiere, como mínimo, el permiso CREATE DDL EVENT NOTIFICATION en el servidor.

  • Para crear una notificación de eventos en un evento de seguimiento se requiere, como mínimo, el permiso CREATE TRACE EVENT NOTIFICATION en el servidor.

  • Para crear una notificación de eventos en el ámbito de una cola se requiere, como mínimo, el permiso ALTER en la cola.

Para obtener información sobre la forma en que se especifica el ámbito de las consultas WQL, vea Usar WQL con el proveedor WMI para eventos de servidor.

Como ejemplo del ámbito, considere una aplicación del proveedor WMI que incluya la siguiente consulta WQL:

SELECT * FROM ALTER_TABLE
WHERE DatabaseName = "AdventureWorks" 
    AND SchemaName = "Person"
    AND ObjectName = "Contact"
    AND ObjectType = "TABLE"

El proveedor WMI traduce esta consulta en una notificación de eventos que se crea en la base de datos AdventureWorks. Esto significa que el autor de la llamada debe tener los permisos necesarios para crear este tipo de notificación de eventos, concretamente el permiso CREATE DATABASE DDL EVENT NOTIFICATION en la base de datos AdventureWorks.

Si una consulta WQL especifica una notificación de eventos que pertenece al nivel del servidor, por ejemplo, emitiendo la consulta SELECT * FROM ALTER_TABLE, la aplicación que realiza la llamada debe tener el permiso CREATE DDL EVENT NOTIFICATION del nivel de servidor. Tenga en cuenta que las notificaciones de eventos con ámbito en el servidor se almacenan en la base de datos master. Puede usar la vista de catálogo sys.server_event_notifications para ver los metadatos.

[!NOTA]

El ámbito de la notificación de eventos creada por el proveedor WMI (servidor, base de datos u objeto) depende en última instancia del resultado del proceso de comprobación de permisos utilizado por el proveedor WMI. Esto último se ve afectado por el conjunto de permisos del usuario que está llamando al proveedor y por la comprobación de la base de datos que se está consultando.

En el ejemplo anterior, el proveedor intenta crear primero una notificación de eventos limitada al ámbito de la base de datos (ON DATABASE). Si el proveedor comprueba que la base de datos existe y que el autor de la llamada dispone de los permisos necesarios para crear una notificación de eventos en la misma, el registro se realizará correctamente. En caso contrario, el proveedor intentará crear una notificación de eventos en el servidor (ON SERVER). Suponiendo que este intento sea correcto, todos los eventos ALTER_TABLE que se producen en el servidor se envían desde el proceso de SQL Server hasta el proceso del servicio WMI. Sin embargo, el proveedor filtra cualquier evento que no se aplique a la base de datos AdventureWorks. Aunque este proceso puede aumentar la cantidad de tráfico de red necesaria para el ámbito del evento, este proceso también ofrece la flexibilidad de registrar consultas WQL en las bases de datos antes de que se creen y, a continuación, recibir los datos de eventos una vez creada la base de datos e iniciada la actividad DDL en la misma.

Permisos y comprobación de mensajes

El proveedor WMI no envía mensajes para las notificaciones de eventos si se cumplen las dos condiciones siguientes:

  • El usuario que creó la notificación de eventos a través del proveedor WMI ya no existe en la base de datos o ya no dispone del permiso necesario para crear una notificación de eventos similar.

  • Las notificaciones de eventos se crean en los eventos siguientes:

    • DROP_LOGIN

    • ALTER_LOGIN

    • DROP_USER

    • ALTER_USER

    • ADD_ROLE_MEMBER

    • DROP_ROLE_MEMBER

    • ADD_SERVER_ROLE_MEMBER

    • DROP_SERVER_ROLE_MEMBER

    • DENY o REVOKE (sólo se aplica a los permisos ALTER DATABASE, ALTER ANY DATABASE EVENT NOTIFICATION, CREATE DATABASE DDL EVENT NOTIFICATION, CONTROL SERVER, ALTER ANY EVENT NOTIFICATION, CREATE DDL EVENT NOTIFICATION o CREATE TRACE EVENT NOTIFICATION).

Trabajar con datos de eventos en el cliente

Después de que el proveedor WMI para eventos del servidor cree la notificación de eventos necesaria en la base de datos de destino, la notificación de eventos envía los datos de eventos al servicio de destino de la base de datos msdb, que se denomina SQL/Notifications/ProcessWMIEventProviderNotification/v1.0. El servicio de destino coloca el evento en una cola de msdb denominada WMIEventProviderNotificationQueue. (El proveedor crea dinámicamente tanto el servicio como la cola cuando se conecta por primera vez a SQL Server.) A continuación, el proveedor lee los datos de eventos XML de la cola y los convierte al formato de objetos administrados (MOF, Managed Object Format) antes de devolvérselos a la aplicación cliente. Los datos MOF se componen de las propiedades del evento solicitado por la consulta WQL como una definición de clase del Modelo de información común (CIM). Cada propiedad tiene un tipo CIM correspondiente. Por ejemplo, la propiedad SPID se devuelve como un tipo CIM Sint32. Los tipos CIM de cada propiedad se muestran debajo de cada clase de eventos en Proveedor WMI de clases y propiedades de eventos de servidor.