Usar WQL con el proveedor WMI para eventos de servidor
Las aplicaciones de administración tienen acceso a los eventos de SQL Server que utilizan el proveedor WMI de eventos de servidor emitiendo instrucciones WQL (Lenguaje de consulta de WMI). WQL es un subconjunto simplificado de lenguaje de consulta estructurado (SQL), con algunas extensiones específicas de WMI. Al utilizar WQL, una aplicación recupera un tipo de evento con una instancia concreta de SQL Server, una base de datos o un objeto de base de datos (el único objeto actualmente admitido es la cola). El proveedor WMI de eventos de servidor convierte la consulta en una notificación de eventos que se crea en la base de datos de destino para las notificaciones de eventos de ámbito de base de datos y de ámbito de objeto, o en la base de datos maestra para las notificaciones de eventos de ámbito de servidor.
Por ejemplo, considere la siguiente consulta WQL:
SELECT * FROM DDL_DATABASE_LEVEL_EVENTS WHERE DatabaseName = 'AdventureWorks'
En esta consulta, el proveedor WMI intenta generar el equivalente de esta notificación de eventos en el servidor de destino:
USE AdventureWorks ;
GO
CREATE EVENT NOTIFICATION SQLWEP_76CF38C1_18BB_42DD_A7DC_C8820155B0E9
ON DATABASE
WITH FAN_IN
FOR DDL_DATABASE_LEVEL_EVENTS
TO SERVICE
'SQL/Notifications/ProcessWMIEventProviderNotification/v1.0',
'A7E5521A-1CA6-4741-865D-826F804E5135';
GO
El argumento de la cláusula FROM de la consulta WQL (DDL_DATABASE_LEVEL_EVENTS) puede ser cualquier evento válido en el que se pueda crear una notificación de eventos. Los argumentos de las cláusulas SELECT y WHERE pueden especificar cualquier propiedad de evento asociada a un evento o a su evento principal. Para obtener una lista de eventos y propiedades de evento válidos, vea Proveedor WMI de clases y propiedades de eventos de servidor.
El proveedor WMI de eventos de servidor admite explícitamente la sintaxis WQL siguiente. Se puede especificar sintaxis WQL adicional, pero no es específica de este proveedor y es analizada en su lugar por el servicio de host de WMI. Para obtener más información acerca del Lenguaje de consulta de WMI, vea la documentación de WQL en Microsoft Developer Network (MSDN).
Sintaxis
SELECT { event_property [ ,...n ] | * }
FROM event_type
WHERE where_condition
Argumentos
event_property
Es una propiedad de un evento. Entre los ejemplos se incluyen PostTime, SPID y LoginName. Busque todos los eventos enumerados en Clases y propiedades del proveedor WMI de eventos de servidor para determinar qué propiedades contienen. Por ejemplo, el evento DDL_DATABASE_LEVEL_EVENTS contiene las propiedades DatabaseName y UserName. También hereda las propiedades SQLInstance, LoginName, PostTime, SPID y ComputerName de sus eventos principales.,...n
Indica que se puede consultar event_property varias veces, con separación por comas.*
Especifica que se consultan todas las propiedades asociadas a un evento.event_type
Es cualquier evento sobre el que se puede crear una notificación de eventos. Para obtener una lista de los eventos disponibles, vea Proveedor WMI de clases y propiedades de eventos de servidor. Observe que los nombres de event type corresponden al mismo event_type | event_group que se puede especificar al crear manualmente una notificación de eventos utilizando CREATE EVENT NOTIFICATION. Entre los ejemplos de event type se incluye CREATE_TABLE, LOCK_DEADLOCK, DDL_USER_EVENTS y TRC_DATABASE.[!NOTA]
Determinados procedimientos almacenados del sistema que realizan operaciones similares a DDL también pueden activar notificaciones de eventos. Pruebe las notificaciones de eventos para determinar su respuesta a los procedimientos almacenados del sistema que se ejecutan. Por ejemplo, la instrucción CREATE TYPE y el procedimiento almacenado sp_addtype activarán una notificación de evento que se crea en un evento CREATE_TYPE. Sin embargo, el procedimiento almacenado sp_rename no activa ninguna notificación de eventos. Para obtener más información, vea Eventos DDL.
where_condition
Es un predicado de consulta con una cláusula WHERE compuesto de nombres de event_property y operadores lógicos y de comparación. where_condition determina el ámbito en el que la notificación de eventos correspondiente se registra en la base de datos de destino. También puede actuar como un filtro para identificar un esquema u objeto determinado en el que se va a consultar el event_type. Para obtener más información, vea la sección Notas más adelante en este tema.Sólo se puede utilizar el operando = junto con DatabaseName, SchemaName y ObjectName. Otras expresiones no se pueden utilizar con estas propiedades de evento.
Notas
where_condition de la sintaxis del proveedor WMI de eventos de servidor determina lo siguiente:
El ámbito mediante el que el proveedor intenta recuperar el event_type especificado: el nivel de servidor, el nivel de base de datos o el nivel de objeto (el único objeto actualmente admitido es la cola). Finalmente, este ámbito determina el tipo de notificación de eventos creado en la base de datos de destino. Este proceso efectuó una llamada al registro de notificación de eventos.
La base de datos, el esquema y el objeto, según corresponda, en que registrarse.
El proveedor WMI de eventos de servidor usa un algoritmo ascendente de tipo "el primero que sea válido" para generar un ámbito lo más restringido posible para la EVENT NOTIFICATION subyacente. El algoritmo intenta minimizar la actividad interna en el tráfico del servidor y de la red entre la instancia de SQL Server y el proceso de host de WMI. El proveedor examina el event_type especificado en la cláusula FROM y las condiciones de la cláusula WHERE e intenta registrar la EVENT NOTIFICATION subyacente con el ámbito más restringido posible. Si el proveedor no se puede registrar en el ámbito más restringido, intenta registrarse en ámbitos superiores consecutivamente hasta que el registro resulta satisfactorio finalmente. Si llega al ámbito superior en el nivel de servidor y se produce un error, devuelve un error al consumidor.
Por ejemplo, si se especifica DatabaseName ='AdventureWorks' en la cláusula WHERE, el proveedor intenta registrar una notificación de eventos en la base de datos AdventureWorks. Si la base de datos AdventureWorks existe y el cliente que realiza la llamada tiene los permisos necesarios para crear una notificación de eventos en AdventureWorks, el registro es satisfactorio. De lo contrario, se intenta registrar la notificación de eventos en el nivel de servidor. El registro es satisfactorio si el cliente de WMI tiene los permisos necesarios. Sin embargo, en esta situación, los eventos no se devuelven al cliente hasta que no se haya creado la base de datos AdventureWorks.
where_condition puede actuar también como filtro para limitar más la consulta a una base de datos, esquema u objeto concretos. Por ejemplo, considere la siguiente consulta WQL:
SELECT * FROM ALTER_TABLE
WHERE DatabaseName = 'AdventureWorks' AND SchemaName = 'Sales'
AND ObjectType='Table' AND ObjectName = 'SalesOrderDetail'
Dependiendo del resultado del proceso de registro, esta consulta WQL se puede registrar en el nivel de base de datos o de servidor. Sin embargo, aunque se registre en el nivel del servidor, el proveedor filtra finalmente los eventos ALTER_TABLE que no se aplican a la tabla AdventureWorks.Sales.SalesOrderDetail. En otras palabras, el proveedor devuelve sólo las propiedades de los eventos ALTER_TABLE que se producen en esa tabla concreta.
Si se especifica una expresión compuesta como DatabaseName='AW1' OR DatabaseName='AW2', se intenta registrar una notificación de eventos única en el ámbito de servidor en lugar de dos notificaciones de eventos independientes. El registro es satisfactorio si el cliente que realiza la llamada tiene permisos.
Si se especifica SchemaName='X' AND ObjectType='Y' AND ObjectName='Z' en la cláusula WHERE, se intenta registrar la notificación de eventos directamente en el objeto Z del esquema X. El registro es satisfactorio si el cliente que realiza la llamada tiene permisos. Observe que, actualmente, los eventos en el nivel de objeto sólo se admiten en colas y sólo para el parámetro event_type QUEUE_ACTIVATION.
Observe que no todos los eventos se pueden consultar en cualquier ámbito determinado. Por ejemplo, una consulta WQL en un evento de seguimiento como Lock_Deadlock o un grupo de eventos de seguimiento como TRC_LOCKS, sólo se puede registrar en el nivel de servidor. De forma similar, el evento CREATE_ENDPOINT y el grupo de eventos DDL_ENDPOINT_EVENTS también se pueden registrar sólo en el nivel de servidor. Para obtener más información acerca del ámbito adecuado para registrar los eventos, vea Diseñar notificaciones de eventos. Los intentos de registrar consultas WQL cuyo event_type sólo se puede registrar en el nivel de servidor siempre se realizan en el nivel de servidor. El registro es satisfactorio si el cliente de WMI tiene permisos. De lo contrario, se devuelve un error al cliente. En algunos casos, sin embargo, puede utilizar todavía la cláusula WHERE como filtro para los eventos en el nivel de servidor basados en las propiedades que corresponden al evento. Por ejemplo, muchos eventos de seguimiento tienen una propiedad DatabaseName que se puede utilizar en la cláusula WHERE como filtro.
Las notificaciones de eventos de ámbito de servidor se crean en la base de datos maestra y se puede consultar si contienen metadatos utilizando la vista de catálogo sys.server_event_notifications.
Las notificaciones de eventos de ámbito de servidor o de ámbito de base de datos se crean en la base de datos especificada y se puede consultar si contienen metadatos utilizando la vista de catálogo sys.server_event_notifications. (Debe anteponer a la vista de catálogo el nombre de la base de datos correspondiente).
Ejemplos
A. Consultar eventos en el ámbito de servidor
La consulta WQL siguiente recupera todas las propiedades de evento de los eventos de seguimiento SERVER_MEMORY_CHANGE que se produzcan en la instancia de SQL Server.
SELECT * FROM SERVER_MEMORY_CHANGE
B. Consultar eventos en el ámbito de base de datos
La consulta WQL siguiente recupera propiedades de evento concretas de los eventos que se produzcan en la base de datos AdventureWorks y existan bajo el grupo de eventos DDL_DATABASE_LEVEL_EVENTS.
SELECT SPID, SQLInstance, DatabaseName FROM DDL_DATABASE_LEVEL_EVENTS
WHERE DatabaseName = 'AdventureWorks'
C. Consultar eventos en el ámbito de base de datos, filtrar por esquema y objeto
La consulta siguiente recupera todas las propiedades de evento de los eventos ALTER_TABLE que se produzcan en la tabla AdventureWorks.Sales.SalesOrderDetail.
SELECT * FROM ALTER_TABLE
WHERE DatabaseName = 'AdventureWorks' AND SchemaName = 'Sales'
AND ObjectType='Table' AND ObjectName = 'SalesOrderDetail'
Vea también