Verwenden von WQL mit dem WMI-Anbieter für Serverereignisse
Verwaltungsanwendungen greifen mithilfe des WMI-Anbieters für Serverereignisse auf SQL Server-Ereignisse zu, indem WMI Query Language (WQL)-Anweisungen ausgestellt werden. WQL ist eine vereinfachte Teilmenge von Structured Query Language (SQL) mit einigen WMI-spezifischen Erweiterungen. Bei Verwendung von WQL ruft eine Anwendung einen Ereignistyp für eine bestimmte Instanz von SQL Server, einer Datenbank oder einem Datenbankobjekt ab (das derzeit einzige objekt wird in der Warteschlange unterstützt). Der WMI-Anbieter für Serverereignisse übersetzt die Abfrage in eine Ereignisbenachrichtigung, die in der Zieldatenbank für Benachrichtigungen mit Datenbankbereichs- oder Objektbereichsereignissen oder in der Masterdatenbank für Serverbereich-Ereignisbenachrichtigungen erstellt wird.
Betrachten Sie beispielsweise folgende WQL-Abfrage:
SELECT * FROM DDL_DATABASE_LEVEL_EVENTS WHERE DatabaseName = 'AdventureWorks'
Ausgehend von dieser Abfrage versucht der WMI-Anbieter, ein Äquivalent dieser Ereignisbenachrichtigung auf dem Zielserver zu produzieren:
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
Das Argument in der FROM
-Klausel der WQL-Abfrage (DDL_DATABASE_LEVEL_EVENTS
) kann ein beliebiges gültiges Ereignis sein, für das eine Ereignisbenachrichtigung erstellt werden kann. Für die Argumente in den Klauseln SELECT
und WHERE
können beliebige Ereigniseigenschaften angegeben werden, die mit einem Ereignis oder dessen übergeordnetem Ereignis verbunden sind. Eine Liste der gültigen Ereignisse und Ereigniseigenschaften finden Sie unter Ereignisbenachrichtigungen (Datenbank-Engine).For a list of valid events and event properties, see Event Notifications (Datenbank-Engine).
Die folgende WQL-Syntax wird explizit vom WMI-Anbieter für Serverereignisse unterstützt. Zusätzliche WQL-Syntaxelemente können angegeben werden; sie sind jedoch nicht anbieterspezifisch für diesen Anbieter, sondern werden stattdessen vom WMI-Hostdienst analysiert. Weitere Informationen zur WMI Query Language finden Sie in der WQL-Dokumentation im Microsoft Developer Network (MSDN).
Syntax
SELECT { event_property [ ,...n ] | * }
FROM event_type
WHERE where_condition
Argumente
event_property
Eine Ereigniseigenschaft. Beispiele hierfür sind PostTime
, SPID
und LoginName
. Suchen Sie nach jedem Ereignis, das im WMI-Anbieter für Serverereignisklassen und -eigenschaften aufgeführt ist, um zu bestimmen, welche Eigenschaften sie enthält. Beispielsweise enthält das DDL_DATABASE_LEVEL_EVENTS-Ereignis die Eigenschaften DatabaseName
und UserName
. Es erbt außerdem die Eigenschaften SQLInstance
, LoginName
, PostTime
SPID
und ComputerName
von den jeweils übergeordneten Ereignissen.
, ... n
Gibt an, dass event_property mehrmals abgefragt werden kann, getrennt durch Kommas.
*
Gibt an, dass alle einem Ereignis zugeordneten Eigenschaften abgefragt werden.
event_type
Jedes Ereignis, für das eine Ereignisbenachrichtigung erstellt werden kann. Eine Liste der verfügbaren Ereignisse finden Sie unter WMI-Anbieter für Serverereignisse Klassen und Eigenschaften. Beachten Sie, dass Ereignistypnamen dem gleichen event_type event_group | entsprechen, der angegeben werden kann, wenn Sie mithilfe von CREATE EVENT NOTIFICATION manuell eine Ereignisbenachrichtigung erstellen. Beispiele für Ereignistypen sind CREATE_TABLE, LOCK_DEADLOCK, DDL_USER_EVENTS und TRC_DATABASE.
Hinweis
Bestimmte gespeicherte Systemprozeduren, die DDL-ähnliche Vorgänge ausführen, können auch Ereignisbenachrichtigungen auslösen. Testen Sie die Ereignisbenachrichtigungen, um ihre Reaktion auf gespeicherte Systemprozeduren, die ausgeführt werden, zu bestimmen. Beispielsweise löst die CREATE TYPE-Anweisung und sp_addtype gespeicherte Prozedur eine Ereignisbenachrichtigung aus, die in einem CREATE_TYPE-Ereignis erstellt wird. Die gespeicherte sp_rename Prozedur löst jedoch keine Ereignisbenachrichtigungen aus. Weitere Informationen finden Sie unterDDL-Ereignisse.
where_condition
Ist ein WHERE-Klauseln-Abfrage-Prädikat aus event_property Namen und logischen und Vergleichsoperatoren. Die where_condition bestimmt den Bereich, in dem die entsprechende Ereignisbenachrichtigung in der Zieldatenbank registriert ist. Sie kann auch als Filter fungieren, um auf ein bestimmtes Schema oder Objekt abzuzielen, aus dem event_type abzufragen sind. Weitere Informationen finden Sie im Abschnitt "Hinweise" weiter unten in diesem Thema.
Nur der =
-Operand kann zusammen mit DatabaseName
, SchemaName
und ObjectName
verwendet werden. Andere Ausdrücke können nicht mit diesen Ereigniseigenschaften verwendet werden.
Hinweise
Die where_condition der Syntax des WMI-Anbieters für Serverereignisse bestimmt Folgendes:
Der Bereich, um den der Anbieter versucht, die angegebene event_type abzurufen: die Serverebene, die Datenbankebene oder die Objektebene (das einzige derzeit unterstützte Objekt ist Warteschlange). Letztlich bestimmt dieser Bereich den Typ der in der Zieldatenbank erstellten Ereignisbenachrichtigung. Dieser Prozess wird Ereignisbenachrichtigungsregistrierung genannt.
Die Datenbank, das Schema und das Objekt, auf der/dem registriert werden soll.
Der WMI-Anbieter für Serverereignisse verwendet einen Algorithmus, der von unten nach oben arbeitet und die erstbestmögliche Lösung benutzt, um den engstmöglichen Gültigkeitsbereich für das zugrunde liegende EVENT NOTIFICATION-Argument anzuwenden. Der Algorithmus versucht, interne Aktivitäten auf dem Server und den Netzwerkdatenverkehr zwischen der Instanz von SQL Server und dem WMI-Hostprozess zu minimieren. Der Anbieter untersucht die in der FROM-Klausel angegebenen event_type und die Bedingungen in der WHERE-Klausel und versucht, die zugrunde liegende EVENT NOTIFICATION mit dem schmalsten möglichen Bereich zu registrieren. Wenn der Anbieter sich nicht im engsten Gültigkeitsbereich registrieren kann, versucht er eine Registrierung in höheren Gültigkeitsbereichen, bis schließlich eine Registrierung erfolgreich ist. Wenn der höchste Bereich auf Serverebene erreicht ist und keine Registrierung zustande kam, wird dem Consumer ein Fehler zurückgegeben.
Wenn beispielsweise DatabaseName=**'AdventureWorks'**in der WHERE-Klausel angegeben ist, versucht der Anbieter, eine Ereignisbenachrichtigung in der AdventureWorks2012-Datenbank zu registrieren. Wenn die AdventureWorks2012-Datenbank vorhanden ist und der aufrufende Client über die erforderlichen Berechtigungen zum Erstellen einer Ereignisbenachrichtigung in AdventureWorks2012 verfügt, ist die Registrierung erfolgreich. Andernfalls wird versucht, die Ereignisbenachrichtigung auf Serverebene zu registrieren. Die Registrierung ist erfolgreich, wenn der WMI-Client die erforderlichen Berechtigungen hat. In diesem Szenario werden ereignisse jedoch erst an den Client zurückgegeben, wenn die AdventureWorks2012-Datenbank erstellt wurde.
Die where_condition kann auch als Filter fungieren, um die Abfrage zusätzlich auf eine bestimmte Datenbank, ein bestimmtes Schema oder ein Objekt zu beschränken. Betrachten Sie beispielsweise folgende WQL-Abfrage:
SELECT * FROM ALTER_TABLE
WHERE DatabaseName = 'AdventureWorks' AND SchemaName = 'Sales'
AND ObjectType='Table' AND ObjectName = 'SalesOrderDetail'
Abhängig vom Ergebnis des Registrierungsprozesses kann diese WQL-Abfrage entweder auf Datenbank- oder auf Serverebene registriert werden. Auch wenn sie auf Serverebene registriert ist, filtert der Anbieter schließlich alle ALTER_TABLE
-Ereignisse, die nicht auf die AdventureWorks.Sales.SalesOrderDetail
-Tabelle zutreffen. Mit anderen Worten gibt der Anbieter nur die Eigenschaften der ALTER_TABLE
-Ereignisse zurück, die in dieser Tabelle vorkommen.
Wird ein zusammengesetzter Ausdruck wie beispielsweise DatabaseName='AW1'
ORDatabaseName='AW2'
angegeben, wird versucht, statt zwei Ereignisbenachrichtigungen nur eine einzige Ereignisbenachrichtigung im Servergültigkeitsbereich zu registrieren. Die Registrierung ist erfolgreich, wenn der aufrufende Client die erforderlichen Berechtigungen hat.
Wenn SchemaName='X' AND ObjectType='Y' AND ObjectName='Z'
alle in der WHERE
Klausel angegeben sind, wird versucht, die Ereignisbenachrichtigung direkt im Objekt Z
im Schema X
zu registrieren. Die Registrierung ist erfolgreich, wenn der Client die erforderlichen Berechtigungen hat. Beachten Sie, dass derzeit Ereignisse auf Objektebene nur für Warteschlangen und nur für die QUEUE_ACTIVATION event_type unterstützt werden.
Beachten Sie, dass nicht bei allen Ereignissen ein bestimmter Gültigkeitsbereich abgefragt werden kann. Beispielsweise können die WQL-Abfrage für ein Ablaufverfolgungsereignis wie Lock_Deadlock oder eine Ablaufverfolgungsereignisgruppe wie TRC_LOCKS nur auf Serverebene registriert werden. Auch das CREATE_ENDPOINT-Ereignis und das DDL_ENDPOINT_EVENTS-Ereignis können nur auf Serverebene registriert werden. Weitere Informationen zum geeigneten Bereich für die Registrierung von Ereignissen finden Sie unter Entwerfen von Ereignisbenachrichtigungen. Ein Versuch, eine WQL-Abfrage zu registrieren, deren event_type nur auf Serverebene registriert werden kann, erfolgt immer auf Serverebene. Die Registrierung ist erfolgreich, wenn der WMI-Client die erforderlichen Berechtigungen hat. Andernfalls wird an den Client ein Fehler zurückgegeben. In bestimmten Fällen können Sie, abhängig von den Eigenschaften des Ereignisses, die WHERE-Klausel jedoch trotzdem als Filter für serverbasierte Ereignisse verwenden. Beispielsweise weisen zahlreiche Ablaufverfolgungsereignisse eine DatabaseName
-Eigenschaft auf, die in der WHERE-Klausel als Filter verwendet werden kann.
Serverweite Ereignisbenachrichtigungen werden in der Masterdatenbank erstellt und können mithilfe der sys.server_event_notifications Katalogansicht nach Metadaten abgefragt werden.
Ereignisbenachrichtigungen mit Datenbankbereich oder Objektbereich werden in der angegebenen Datenbank erstellt und können mithilfe der sys.event_notifications Katalogansicht nach Metadaten abgefragt werden. (Sie müssen der Katalogsicht den entsprechenden Datenbanknamen als Präfix hinzufügen.)
Beispiele
A. Abfragen von Ereignissen im Serverbereich
Die folgende WQL-Abfrage ruft alle Ereigniseigenschaften für jedes SERVER_MEMORY_CHANGE
Ablaufverfolgungsereignis ab, das in der Instanz von SQL Server auftritt.
SELECT * FROM SERVER_MEMORY_CHANGE
B. Abfragen von Ereignissen im Datenbankbereich
Die folgende WQL-Abfrage ruft bestimmte Ereigniseigenschaften für alle Ereignisse ab, die in der AdventureWorks
-Datenbank auftreten und in der DDL_DATABASE_LEVEL_EVENTS
-Ereignisgruppe existieren.
SELECT SPID, SQLInstance, DatabaseName FROM DDL_DATABASE_LEVEL_EVENTS
WHERE DatabaseName = 'AdventureWorks'
C. Abfragen von Ereignissen im Datenbankbereich mit Filtern nach Schema und Objekt
Die folgende Abfrage ruft alle Ereigniseigenschaften für alle ALTER_TABLE
-Ereignisse ab, die in der Tabelle AdventureWorks.Sales.SalesOrderDetail
auftreten.
SELECT * FROM ALTER_TABLE
WHERE DatabaseName = 'AdventureWorks' AND SchemaName = 'Sales'
AND ObjectType='Table' AND ObjectName = 'SalesOrderDetail'
Weitere Informationen
Konzepte des WMI-Anbieters für Serverereignisse
Ereignisbenachrichtigungen (Datenbank-Engine)