Compartir a través de


Trabajar con el proveedor WMI para eventos de servidor

En este tema se proporcionan instrucciones que debe tener en cuenta antes de programar el uso del proveedor WMI para eventos de servidor.

Habilitación de Service Broker

El proveedor WMI para eventos de servidor funciona mediante la traducción de consultas WQL para eventos en notificaciones de eventos en la base de datos de destino. Comprender cómo funcionan las notificaciones de eventos puede resultarle útil al programar con el proveedor. Para obtener más información, vea Conceptos del proveedor WMI para eventos de servidor.

En concreto, dado que las notificaciones de eventos creadas por el proveedor WMI usan SQL Server para enviar mensajes sobre eventos de servidor, este servicio debe habilitarse siempre que se generen los eventos. Si el programa consulta eventos en una instancia de servidor, service Broker en msdb de esa instancia debe habilitarse, ya que es la ubicación del servicio de Service Broker de destino (denominado SQL/Notifications/ProcessWMIEventProviderNotification/v1.0) creado por el proveedor. Si el programa consulta eventos en una base de datos o en un objeto de base de datos determinado, se debe habilitar Service Broker en esa base de datos de destino. Si la instancia de Service Broker correspondiente no está habilitada después de implementar la aplicación, los eventos generados por la notificación de eventos subyacente se envían a la cola del servicio utilizado por la notificación de eventos, pero no se devuelven a la aplicación de administración de WMI hasta que Service Broker esté habilitado.

La consulta siguiente determina qué agentes de servicio están habilitados en una instancia de servidor y el GUID de la instancia del agente:

SELECT name, is_broker_enabled, service_broker_guid FROM sys.databases;  

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

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

Especificar una cadena de conexión

Las aplicaciones dirigen el proveedor WMI para eventos de 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.dlly lo carga en memoria. Cada instancia de SQL Server tiene su propio espacio de nombres WMI, que tiene como valor predeterminado: \\.\root\Microsoft\SqlServer\ServerEvents\instance_name. instance_name valor predeterminado es MSSQLSERVER en una instalación predeterminada de SQL Server.

Permisos y autenticación de servidor

Para acceder al proveedor WMI para eventos de servidor, el cliente en el que se origina una aplicación de administración de WMI debe corresponder al inicio de sesión o grupo autenticados de Windows en la instancia de SQL Server especificada en la cadena de conexión de la aplicación.

Permisos y ámbito de notificación de eventos

El proveedor WMI para eventos de servidor convierte las consultas WQL en notificaciones de eventos en la base de datos de destino. Por este motivo, la aplicación que realiza la llamada no solo debe tener los permisos mínimos necesarios para acceder al proveedor, sino que también debe tener los permisos correctos en la base de datos para crear las notificaciones de eventos necesarias. A continuación se muestran los permisos:

  • Para crear una notificación de eventos cuyo ámbito sea la base de datos, como mínimo, se requiere 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 cuyo ámbito sea el servidor, como mínimo, se requiere el permiso CREATE DDL EVENT NOTIFICATION en el servidor.

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

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

Para obtener información sobre cómo se limitan las consultas WQL, vea Uso de WQL con el proveedor WMI para eventos de servidor.

Para ilustrar el ámbito, considere la posibilidad de usar una aplicación de proveedor WMI que incluya la siguiente consulta WQL:

SELECT * FROM ALTER_TABLE  
WHERE DatabaseName = "AdventureWorks2012"   
    AND SchemaName = "Person"  
    AND ObjectName = "Person"  
    AND ObjectType = "TABLE";  

El proveedor WMI traduce esta consulta en una notificación de eventos creada en la base de datos AdventureWorks2012 . Esto significa que el autor de la llamada debe tener los permisos necesarios para crear dicha notificación de eventos, específicamente el permiso CREATE DATABASE DDL EVENT NOTIFICATION en la base de datos AdventureWorks2012 .

Si una consulta WQL especifica un ámbito de notificación de eventos en el nivel de 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 de nivel de servidor. Tenga en cuenta que las notificaciones de eventos con ámbito de servidor se almacenan en la base de datos maestra. Puede usar la vista de catálogo de sys.server_event_notifications para ver sus metadatos.

Nota:

El ámbito de la notificación de eventos creada por el proveedor WMI (servidor, base de datos o objeto) depende en última instancia del resultado del proceso de comprobación de permisos que usa el proveedor WMI. Esto se ve afectado por el conjunto de permisos del usuario que llama al proveedor y en 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 en el á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 tiene los permisos necesarios para crear una notificación de eventos en ella, el registro se realiza correctamente. Si no se realiza correctamente, el proveedor intenta crear una notificación de eventos en el servidor (ON SERVER). Suponiendo que este intento es correcto, todos los ALTER_TABLE eventos que se producen en el servidor se envían desde el proceso de SQL Server al proceso de servicio WMI. Sin embargo, el proveedor filtra los eventos que no se aplican a la AdventureWorks base de datos. Aunque este proceso aumenta potencialmente la cantidad de tráfico de red necesario para el ámbito del evento, este proceso también le permite registrar consultas WQL en bases de datos antes de crearlas y, a continuación, recibir datos de eventos después de crear la base de datos y la actividad DDL se inicia en ella.

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 tiene el permiso necesario para crear una notificación de eventos similar.

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

    • DROP_LOGIN

    • ALTER_LOGIN

    • DROP_USER

    • ALTER_USER

    • ADD_ROLE_MEMBER

    • Eliminar miembro de rol

    • AGREGAR_MIEMBRO_ROL_SERVIDOR

    • ELIMINAR_MIEMBRO_DEL_ROL_DEL_SERVIDOR

    • DENY o REVOKE (solo se aplica a ALTER DATABASE, ALTER ANY DATABASE EVENT NOTIFICATION, CREATE DATABASE DDL EVENT NOTIFICATION, CONTROL SERVER, ALTER ANY EVENT NOTIFICATION, CREATE DDL EVENT NOTIFICATION, OR CREATE TRACE EVENT NOTIFICATION).

Trabajar con datos de eventos en el lado cliente

Una vez que el proveedor WMI para eventos de servidor crea la notificación de eventos necesaria en la base de datos de destino, la notificación de eventos envía datos de eventos al servicio de destino en msdb denominado SQL/Notifications/ProcessWMIEventProviderNotification/v1.0. El servicio de destino coloca el evento en una cola en msdb que se denomina WMIEventProviderNotificationQueue. (Tanto el servicio como la cola se crean dinámicamente por el proveedor cuando se conecta por primera vez a SQL Server). A continuación, el proveedor lee los datos de eventos XML de esta cola y los transforma en formato de objeto administrado (MOF) antes de devolverlos a la aplicación cliente. Los datos MOF se componen de las propiedades del evento solicitados por la consulta WQL como definición de clase Common Information Model (CIM). Cada propiedad tiene un tipo CIM correspondiente. Por ejemplo, la SPID propiedad se devuelve como tipo Sint32CIM . Los tipos CIM de cada propiedad se enumeran en cada clase de eventos del proveedor WMI para clases y propiedades de eventos de servidor.

Véase también

Conceptos del proveedor WMI para eventos de servidor