WMI Provider for Server Events Concepts | Microsoft Docs

Table of Contents
WMI Provider for Server Events Concepts
Sample: Creating a SQL Server Agent Alert with the WMI Provider
Sample: Using the WMI Event Provider with the .NET Framework
Understanding the WMI Provider for Server Events
Using WQL with the WMI Provider for Server Events
WMI Provider for Server Events Classes and Properties
Working with the WMI Provider for Server Events
WMI Provider for Server Events Concepts
3/24/2017 • 1 min to read • Edit Online
The WMI Provider for Server Events lets you use Windows Management Instrumentation (WMI) to monitor events
in an instance of SQL Server.
In This Section
Understanding the WMI Provider for Server Events
Provides an overview of the provider architecture and how SQL Server Agent can be programmed to work with it.
Working with the WMI Provider for Server Events
Explains the factors that you need to consider before programming with the provider.
Using WQL with the WMI Provider for Server Events
Explains the WMI Query Language (WQL) syntax and how to use it when you program against the provider.
Sample: Creating a SQL Server Agent Alert by Using the WMI Provider for Server Events
Provides an example of using the WMI Provider to return trace event information on which to create a SQL Server
Agent alert.
Sample: Use the WMI Event Provider with the .NET Framework
Provides an example of using the WMI Provider to return event data in a C# application.
WMI Provider for Server Events Classes and Properties
Introduces the event classes and properties that make up the programming mode of the provider.
Sample: Creating a SQL Server Agent Alert with the
WMI Provider
3/29/2017 • 3 min to read • Edit Online
One common way to use the WMI Event Provider is to create SQL Server Agent alerts that respond to specific
events. The following sample presents a simple alert that saves XML deadlock graph events in a table for later
analysis. SQL Server Agent submits a WQL request, receives WMI events, and runs a job in response to the event.
Notice that, although several Service Broker objects are involved in processing the notification message, the WMI
Event Provider handles the details of creating and managing these objects.
Example
First, a table is created in the AdventureWorks database to hold the deadlock graph event. The table contains two
columns: The AlertTime column holds the time that the alert runs, and the DeadlockGraph column holds the XML
document that contains the deadlock graph.
Then, the alert is created. The script first creates the job that the alert will run, adds a job step to the job, and targets
the job to the current instance of SQL Server. The script then creates the alert.
The job step retrieves the TextData property of the WMI event instance and inserts that value into the
DeadlockGraph column of the DeadlockEvents table. Notice that SQL Server implicitly converts the string into
XML format. Because the job step uses the Transact-SQL subsystem, the job step does not specify a proxy.
The alert runs the job whenever a deadlock graph trace event would be logged. For a WMI alert, SQL Server Agent
creates a notification query using the namespace and WQL statement specified. For this alert, SQL Server Agent
monitors the default instance on the local computer. The WQL statement requests any DEADLOCK_GRAPH event in the
default instance. To change the instance that the alert monitors, substitute the instance name for MSSQLSERVER in
the @wmi_namespace for the alert.
NOTE
For SQL Server Agent to receive WMI events, Service Broker must be enabled in msdb and AdventureWorks2012.
USE AdventureWorks ;
GO
IF OBJECT_ID('DeadlockEvents', 'U') IS NOT NULL
BEGIN
DROP TABLE DeadlockEvents ;
END ;
GO
CREATE TABLE DeadlockEvents
(AlertTime DATETIME, DeadlockGraph XML) ;
GO
-- Add a job for the alert to run.
EXEC msdb.dbo.sp_add_job @job_name=N'Capture Deadlock Graph',
@enabled=1,
@description=N'Job for responding to DEADLOCK_GRAPH events' ;
GO
-- Add a jobstep that inserts the current time and the deadlock graph into
-- the DeadlockEvents table.
EXEC msdb.dbo.sp_add_jobstep
@job_name = N'Capture Deadlock Graph',
@step_name=N'Insert graph into LogEvents',
@step_id=1,
@on_success_action=1,
@on_fail_action=2,
@subsystem=N'TSQL',
@command= N'INSERT INTO DeadlockEvents
(AlertTime, DeadlockGraph)
VALUES (getdate(), N''$(ESCAPE_SQUOTE(WMI(TextData)))'')',
@database_name=N'AdventureWorks' ;
GO
-- Set the job server for the job to the current instance of SQL Server.
EXEC msdb.dbo.sp_add_jobserver @job_name = N'Capture Deadlock Graph' ;
GO
-- Add an alert that responds to all DEADLOCK_GRAPH events for
-- the default instance. To monitor deadlocks for a different instance,
-- change MSSQLSERVER to the name of the instance.
EXEC msdb.dbo.sp_add_alert @name=N'Respond to DEADLOCK_GRAPH',
@wmi_namespace=N'\\.\root\Microsoft\SqlServer\ServerEvents\MSSQLSERVER',
@wmi_query=N'SELECT * FROM DEADLOCK_GRAPH',
@job_name='Capture Deadlock Graph' ;
GO
Testing the Sample
To see the job run, provoke a deadlock. In SQL Server Management Studio, open two SQL Query tabs and connect
both queries to the same instance. Run the following script in one of the query tabs. This script produces one result
set and finishes.
USE AdventureWorks ;
GO
BEGIN TRANSACTION ;
GO
SELECT TOP(1) Name FROM Production.Product WITH (XLOCK) ;
GO
Run the following script in the second query tab. This script produces one result set and then blocks, waiting to
acquire a lock on Production.Product .
USE AdventureWorks ;
GO
BEGIN TRANSACTION ;
GO
SELECT TOP(1) Name FROM Production.Location WITH (XLOCK) ;
GO
SELECT TOP(1) Name FROM Production.Product WITH (XLOCK) ;
GO
Run the following script in the first query tab. This script blocks, waiting to acquire a lock on Production.Location .
After a short time-out, SQL Server will choose either this script or the script in the sample as the deadlock victim
and end the transaction.
SELECT TOP(1) Name FROM Production.Location WITH (XLOCK) ;
GO
After provoking the deadlock, wait several moments for SQL Server Agent to activate the alert and run the job.
Examine the contents of the DeadlockEvents table by running the following script:
SELECT * FROM DeadlockEvents ;
GO
The DeadlockGraph column should contain an XML document that shows all the properties of the deadlock graph
event.
See Also
WMI Provider for Server Events Concepts
Sample: Using the WMI Event Provider with the .NET
Framework
3/24/2017 • 1 min to read • Edit Online
The following sample creates an application in C# that uses the WMI Event Provider to return event data for all data
definition language (DDL) events that occur on a default installation instance of SQL Server.
Example
The example compiles by using the following command file:
set compiler_path=C:\WINNT\Microsoft.NET\Framework\v2.0.50110
%compiler_path%\csc %1
using System;
using System.Management;
class SQLWEPExample
{
public static void Main(string[] args)
{
string query = @"SELECT * FROM DDL_EVENTS " ;
// Default namespace for default instance of SQL Server
string managementPath =
@"\\.\root\Microsoft\SqlServer\ServerEvents\MSSQLSERVER";
ManagementEventWatcher watcher =
new ManagementEventWatcher(new WqlEventQuery (query));
ManagementScope scope = new ManagementScope (managementPath);
scope.Connect();
watcher.Scope = scope;
Console.WriteLine("Watching...");
while (true)
{
ManagementBaseObject obj = watcher.WaitForNextEvent();
Console.WriteLine("Event!");
foreach (PropertyData data in obj.Properties)
{
Console.Write("{0}:", data.Name);
if (data.Value == null)
{
Console.WriteLine("<null>");
}
else
{
Console.WriteLine(data.Value.ToString());
}
}
Console.WriteLine("-----");
Console.WriteLine();
Console.WriteLine();
}
}
}
See Also
WMI Provider for Server Events Concepts
Understanding the WMI Provider for Server Events
3/24/2017 • 3 min to read • Edit Online
The WMI Provider for Server Events lets you use the Windows Management Instrumentation (WMI) to monitor
events in SQL Server. The provider works by turning SQL Server into a managed WMI object. Any event that can
generate an event notification in SQL Server can be leveraged by the WMI by using this provider. Additionally, as a
management application that interacts with the WMI, SQL Server Agent can respond to these events, increasing the
scope of events covered by SQL Server Agent over earlier releases.
Management applications such as SQL Server Agent can access SQL Server events using the WMI Provider for
Server Events by issuing WMI Query Language (WQL) statements. WQL is a simplified subset of structured query
language (SQL), with some WMI-specific extensions. In using WQL, an application retrieves an event type against a
specific database or database object. The WMI Provider for Server Events translates the query into an event
notification, effectively creating an event notification in the target database. For more information about how event
notifications work in SQL Server, see WMI Provider for Server Events Concepts. The events that can be queried are
listed in WMI Provider for Server Events Classes and Properties.
When an event occurs that triggers the event notification to send a message, the message goes to a predefined
target service in msdb that is named SQL/Notifications/ProcessWMIEventProviderNotification/v1.0. The
service puts the event into a predefined queue in msdb that is named WMIEventProviderNotificationQueue.
(Both the service and the queue are created dynamically by the provider when it first connects to SQL Server.) The
provider then reads the event data from this queue and transforms it into managed object format (MOF) before
returning it to the application. The following illustration shows this process.
For example, consider the following WQL Query:
SELECT * FROM DDL_DATABASE_LEVEL_EVENTS
WHERE DatabaseName = 'AdventureWorks'
In response to this query, the WMI Provider for Server Events creates the equivalent event notification in the target
database:
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
In this example, SQLWEP_76CF38C1_18BB_42DD_A7DC_C8820155B0E9 is a Transact-SQL identifier that is made up of the
prefix SQLWEP_ and a GUID. SQLWEP creates a new GUID for each identifier. The value
A7E5521A-1CA6-4741-865D-826F804E5135 in the TO SERVICE clause is the GUID that identifies the broker instance in
the msdb database.
For more information about how to work with WQL, see Using WQL with the WMI Provider for Server Events.
Management applications direct the WMI Provider for Server Events to an instance of SQL Server by connecting to
a WMI namespace that is defined by the provider. The Windows WMI service maps this namespace to the provider
DLL, Sqlwep.dll, and loads it into memory. The provider manages a WMI namespace for Server Events for each
instance of SQL Server, and the format is: \\.\root\Microsoft\SqlServer\ServerEvents\instance_name, where
instance_name defaults to MSSQLSERVER. For more information about how to connect to a WMI namespace for an
instance of SQL Server, see Using WQL with the WMI Provider for Server Events.
The provider DLL, Sqlwep.dll, is loaded only one time into the WMI host service of the operating system of the
server, regardless of how many instances of SQL Server are on the server.
For an example of a SQL Server Agent management application that uses the WMI Provider for Server Events, see
Sample: Creating a SQL Server Agent Alert Using the WMI Provider for Server Events. For an example of a
management application that uses the WMI Provider for Server Events in managed code, see Sample: Using the
WMI Event Provider in Managed Code. More information is also available about WMI in the Microsoft .NET
Framework SDK.
See Also
WMI Provider for Server Events Concepts
Using WQL with the WMI Provider for Server Events
3/24/2017 • 7 min to read • Edit Online
Management applications access SQL Server events using the WMI Provider for Server Events by issuing WMI
Query Language (WQL) statements. WQL is a simplified subset of structured query language (SQL), with some
WMI-specific extensions. In using WQL, an application retrieves an event type against a specific instance of SQL
Server, a database, or a database object (the only object currently supported is queue). The WMI Provider for Server
Events translates the query into an event notification that is created in the target database for database-scoped or
object-scoped event notifications, or in the master database for server-scoped event notifications.
For example, consider the following WQL query:
SELECT * FROM DDL_DATABASE_LEVEL_EVENTS WHERE DatabaseName = 'AdventureWorks'
From this query, the WMI Provider tries to produce the equivalent of this event notification on the target server:
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
The argument in the FROM clause of the WQL query ( DDL_DATABASE_LEVEL_EVENTS ) can be any valid event upon
which an event notification can be created. The arguments in the SELECT and WHERE clauses can specify any event
property associated with an event or its parent event. For a list of valid events and event properties, see Event
Notifications (Database Engine).
The following WQL syntax is supported explicitly by the WMI Provider for Server Events. Additional WQL syntax
may be specified, but it is not specific to this provider and is parsed instead by the WMI host service. For more
information about the WMI Query Language, see the WQL documentation on the Microsoft Developer Network
(MSDN).
Syntax
SELECT { event_property [ ,...n ] | * }
FROM event_type
WHERE where_condition
Arguments
event_property
Is a property of an event. Examples include PostTime, SPID, and LoginName. Look up each event listed in WMI
Provider for Server Events Classes and Properties to determine which properties it holds. For example, the
DDL_DATABASE_LEVEL_EVENTS event holds the DatabaseName and UserName properties. It also inherits the
SQLInstance, LoginName, PostTime, SPID, and ComputerName properties from its parent events.
, ...n
Indicates that event_property can be queried multiple times, separated by commas.
*
Specifies that all properties associated with an event are queried.
event_type
Is any event against which an event notification can be created. For a list of available events, see WMI Provider for
Server Events Classes and Properties. Note that event type names correspond to the same event_type |
event_group that can be specified when you manually create an event notification by using CREATE EVENT
NOTIFICATION. Examples of event type include CREATE_TABLE, LOCK_DEADLOCK, DDL_USER_EVENTS, and
TRC_DATABASE.
NOTE
Certain system stored procedures that perform DDL-like operations can also fire event notifications. Test your event
notifications to determine their responses to system stored procedures that are run. For example, the CREATE TYPE
statement and sp_addtype stored procedure will both fire an event notification that is created on a CREATE_TYPE event.
However, the sp_rename stored procedure does not fire any event notifications. For more information, seeDDL Events.
where_condition
Is a WHERE clause query predicate made up of event_property names and logical and comparison operators. The
where_condition determines the scope in which the corresponding event notification is registered in the target
database. It can also act as a filter to target a particular schema or object from which to query event_type. For more
information, see the Remarks section later in this topic.
Only the = operand can be used together with DatabaseName, SchemaName, and ObjectName. Other
expressions cannot be used with these event properties.
Remarks
The where_condition of the WMI Provider for Server Events syntax determines the following:
The scope by which the provider tries to retrieve the specified event_type: the server level, database level, or
object level (the only object currently supported is queue). Ultimately, this scope determines the type of
event notification created in the target database. This process called event notification registration.
The database, schema, and object, where appropriate, on which to register.
The WMI Provider for Server Events uses a bottom-up, first-fit algorithm to produce the narrowest possible
scope for the underlying EVENT NOTIFICATION. The algorithm tries to minimize internal activity on the
server and network traffic between the instance of SQL Server and the WMI host process. The provider
examines the event_type specified in the FROM clause and the conditions in the WHERE clause, and tries to
register the underlying EVENT NOTIFICATION with the narrowest possible scope. If the provider cannot
register at the narrowest scope, it tries to register at successively higher scopes until a registration finally
succeeds. If it reaches the highest scope the server-level) and fails, it returns an error to the consumer.
For example, if DatabaseName='AdventureWorks'is specified in the WHERE clause, the provider tries to
register an event notification in the AdventureWorks2012 database. If the AdventureWorks2012
database exists and the calling client has the required permissions to create an event notification in
AdventureWorks2012, the registration is successful. Otherwise, an attempt is made to register the event
notification at the server level. The registration succeeds if the WMI client has the required permissions.
However, under this scenario, events are not returned to the client until the AdventureWorks2012
database has been created.
The where_condition can also act as a filter to additionally limit the query to a specific database, schema, or
object. For example, consider the following WQL query:
SELECT * FROM ALTER_TABLE
WHERE DatabaseName = 'AdventureWorks' AND SchemaName = 'Sales'
AND ObjectType='Table' AND ObjectName = 'SalesOrderDetail'
Depending on the outcome of the registration process, this WQL query may be registered either at the database or
server level. However, even if it is registered at the server level, the provider ultimately filters any ALTER_TABLE
events that do not apply to the AdventureWorks.Sales.SalesOrderDetail table. In other words, the provider returns
only the properties of the ALTER_TABLE events that occur on that specific table.
If a compound expression such as DatabaseName='AW1' OR DatabaseName='AW2' is specified, an attempt is made to
register a single event notification at the server scope instead of two separate event notifications. The registration
succeeds if the calling client has permissions.
If SchemaName='X' AND ObjectType='Y' AND ObjectName='Z' are all specified in the WHERE clause, an attempt is made
to register the event notification directly on object Z in schema X . The registration succeeds if the client has
permissions. Note that currently, object-level events are supported only on queues, and only for the
QUEUE_ACTIVATION event_type.
Note that not all events can be queried at any particular scope. For example, a WQL query on a trace event such as
Lock_Deadlock, or a trace event group such as TRC_LOCKS, can only be registered at the server level. Similarly, the
CREATE_ENDPOINT event and the DDL_ENDPOINT_EVENTS event group can also be registered only at the server
level. For more information about the appropriate scope for registering events, see Designing Event Notifications.
An attempt to register a WQL query whose event_type can only be registered at the server level is always made at
the server level. Registration succeeds if the WMI client has permissions. Otherwise, an error is returned to the
client. In some cases, however, you can still use the WHERE clause as a filter for server-level events based on the
properties that correspond to the event. For example, many trace events have a DatabaseName property that can
be used in the WHERE clause as a filter.
Server-scoped event notifications are created in the master database and can be queried for metadata by using the
sys.server_event_notifications catalog view.
Database-scoped or object-scoped event notifications are created in the specified database and can be queried for
metadata by using the sys.event_notifications catalog view. (You must prefix the catalog view with the
corresponding database name.)
Examples
A. Querying for events at the server scope
The following WQL query retrieves all event properties for any
instance of SQL Server.
SERVER_MEMORY_CHANGE
trace event that occurs on the
SELECT * FROM SERVER_MEMORY_CHANGE
B. Querying for events at the database scope
The following WQL query retrieves specific event properties for any event that occurs in the
database and exists under the DDL_DATABASE_LEVEL_EVENTS event group.
SELECT SPID, SQLInstance, DatabaseName FROM DDL_DATABASE_LEVEL_EVENTS
WHERE DatabaseName = 'AdventureWorks'
AdventureWorks
C. Querying for events at the database scope, filtering by schema and object
The following query retrieves all event properties for any ALTER_TABLE event that occurs on table
AdventureWorks.Sales.SalesOrderDetail .
SELECT * FROM ALTER_TABLE
WHERE DatabaseName = 'AdventureWorks' AND SchemaName = 'Sales'
AND ObjectType='Table' AND ObjectName = 'SalesOrderDetail'
See Also
WMI Provider for Server Events Concepts
Event Notifications (Database Engine)
WMI Provider for Server Events Classes and
Properties
3/24/2017 • 1 min to read • Edit Online
The following server events make up the programming model for the WMI Provider for Server Events. There are
two main categories of events that can be queried by issuing WQL queries against the provider. These are data
definition language (DDL) events and trace events. The QUEUE_ACTIVATION and BROKER_QUEUE_DISABLED
service broker events can also be queried. Note the inclusive nature of the following tree diagrams. The
DDL_ASSEMBLY_EVENTS event, for example, includes any ALTER_ASSEMBLY, CREATE_ASSEMBLY, and
DROP_ASSEMBLY event. Similarly, the TRC_FULL_TEXT event includes any FT_CRAWL_ABORTED,
FT_CRAWL_STARTED, and FT_CRAWL_STOPPED event. ALL_EVENTS covers all DDL events, trace events,
QUEUE_ACTIVATION, and BROKER_QUEUE_DISABLED.
To learn which properties can be queried from an event or event group, refer to the event schema. By default, the
event schema is installed in the following directory: C:\Program Files\Microsoft SQL
Server\130\Tools\Binn\schemas\sqlserver\2006\11\events\events.xsd.
Alternatively, you can refer to the event schema published at http://schemas.microsoft.com/sqlserver.
For example, by referring to the ALTER_DATABASE event, you will learn that its parent event is
DDL_SERVER_LEVEL_EVENTS and its properties are TSQLCommand and DatabaseName. The event also inherits
the properties SQLInstance, PostTime, ComputerName, SPID, and LoginName. The event has no children
events.
NOTE
System stored procedures that perform DDL-like operations can also fire event notifications. Test your event notifications to
determine their responses to system stored procedures that are run. For example, the CREATE TYPE statement and
sp_addtype stored procedure will both fire an event notification that is created on a CREATE_TYPE event. For more
information, seeDDL Events.
Data Definition Language Events and Event Groups
Trace Events and Event Groups
See Also
WMI Provider for Server Events Concepts
Using WQL with the WMI Provider for Server Events
Working with the WMI Provider for Server Events
3/24/2017 • 5 min to read • Edit Online
This topic provides guidelines you should consider before you program using the WMI Provider for Server Events.
Enabling Service Broker
The WMI Provider for Server Events works by translating WQL queries for events into event notifications in the
database that you target. An understanding of how event notifications work can be useful to you when
programming against the provider. For more information, see WMI Provider for Server Events Concepts.
In particular, because the event notifications created by the WMI Provider use SQL Server to send messages about
server events, this service must be enabled wherever the events are generated. If your program queries events on a
server instance, the Service Broker in msdb of that instance must be enabled, because that is the location of the
target Service Broker service (named SQL/Notifications/ProcessWMIEventProviderNotification/v1.0) that is created
by the provider. If your program queries events in a database or on a particular database object, the Service Broker
in that target database must be enabled. If the corresponding Service Broker is not enabled after your application is
deployed, any events generated by the underlying event notification are sent to the queue of the service used by
the event notification, but are not returned to your WMI management application until Service Broker is enabled.
The following query determines which service brokers are enabled on a server instance, and the broker instance
GUID:
SELECT name, is_broker_enabled, service_broker_guid FROM sys.databases;
The service broker GUID of msdb is of particular interest because that is the location of the target service of the
provider.
To enable Service Broker in a database, use the ENABLE_BROKER SET option of the ALTER DATABASE statement.
Specifying a Connection String
Applications direct the WMI Provider for Server Events to an instance of SQL Server by connecting to a WMI
namespace defined by the provider. The Windows WMI service maps this namespace to the provider DLL,
Sqlwep.dll, and loads it into memory. Each instance of SQL Server has its own WMI namespace, which defaults to:
\\.\root\Microsoft\SqlServer\ServerEvents\instance_name. instance_name defaults to MSSQLSERVER in a default
installation of SQL Server.
Permissions and Server Authentication
To access the WMI Provider for Server Events, the client on which a WMI management application originates must
correspond to Windows authenticated login or group in the instance of SQL Server specified in the application's
connection string of the application.
Permissions and Event Notification Scope
The WMI Provider for Server Events translates WQL queries into event notifications in the target database. Because
of this, the calling application must have not only the required minimum permissions to access the provider, but
must also have the correct permissions in the database to create the required event notifications. The following are
the permissions:
To create an event notification that is scoped to the database, at a minimum, CREATE DATABASE DDL EVENT
NOTIFICATION permission in the current database is required.
To create an event notification on a DDL statement that is scoped to the server, at a minimum, CREATE DDL
EVENT NOTIFICATION permission in the server is required.
To create an event notification on a trace event, at a minimum, CREATE TRACE EVENT NOTIFICATION
permission in the server is required.
To create an event notification that is scoped to a queue, at a minimum, ALTER permission on the queue is
required.
For information about how WQL queries are scoped, see Using WQL with the WMI Provider for Server
Events.
To illustrate scope, consider a WMI Provider application that includes the following WQL query:
SELECT * FROM ALTER_TABLE
WHERE DatabaseName = "AdventureWorks2012"
AND SchemaName = "Person"
AND ObjectName = "Person"
AND ObjectType = "TABLE";
The WMI provider translates this query into an event notification that is created in the AdventureWorks2012
database. This means that the caller must have the required permissions to create such an event notification,
specifically CREATE DATABASE DDL EVENT NOTIFICATION permission in the AdventureWorks2012 database.
If a WQL query specifies an event notification scoped at the server level, for example by issuing the query SELECT *
FROM ALTER_TABLE, the calling application must have the server-level CREATE DDL EVENT NOTIFICATION
permission. Note that server-scoped event notifications are stored in the master database. You can use the
sys.server_event_notifications catalog view to see their metadata.
NOTE
The scope of the event notification that is created by the WMI Provider (server, database, or object) ultimately depends on
the outcome of the permissions verification process that is used by the WMI provider. This is affected by the permission set
of the user that is calling the provider and on the verification of the database that is being queried.
In the previous example, the provider first tries to create an event notification scoped to the database ( ON DATABASE ). If the
provider verifies that the database exists and that the caller has the required permissions to create an event notification on it,
the registration is successful. If it is not successful, the provider tries to create an event notification on the server ( ON SERVER
). Assuming that this attempt is successful, all ALTER_TABLE events that occur on the server are sent from the SQL Server
process to the WMI Service process. However, the provider filters out any events that do not apply to the AdventureWorks
database. Although this process potentially increases the amount of network traffic necessary for the scope of the event, this
process also enables you with the flexibility to register WQL queries on databases before they are created, and then receive
event data after the database is created and DDL activity starts on it.
Permissions and Message Verification
The WMI Provider does not send messages for event notifications if both of the following conditions are true:
The user that created the event notification through the WMI Provider no longer exists in the database, or no
longer has the required permission to create a similar event notification.
The event notifications are created on the following events:
DROP_LOGIN
ALTER_LOGIN
DROP_USER
ALTER_USER
ADD_ROLE_MEMBER
DROP_ROLE_MEMBER
ADD_SERVER_ROLE_MEMBER
DROP_SERVER_ROLE_MEMBER
DENY or REVOKE (Applies only to 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
permissions.)
Working with Event Data on the Client Side
After the WMI Provider for Server Events creates the required event notification in the target database, the event
notification sends event data to the target service in msdb that is named
SQL/Notifications/ProcessWMIEventProviderNotification/v1.0. The target service puts the event into a queue
in msdb that is named WMIEventProviderNotificationQueue. (Both the service and the queue are dynamically
created by the provider when it first connects to SQL Server.) The provider then reads the XML event data from this
queue and transforms it into managed object format (MOF) before returning it to the client application. The MOF
data is made up of the properties of the event that is requested by the WQL query as a Common Information
Model (CIM) class definition. Each property has a corresponding CIM type. For example, the SPID property is
returned as CIM type Sint32. The CIM types for each property are listed under each event class in WMI Provider for
Server Events Classes and Properties.
See Also
WMI Provider for Server Events Concepts