Freigeben über

Verwenden von WQL mit dem WMI-Anbieter für Serverereignisse

  • Artikel

Verwaltungsanwendungen greifen über den WMI-Anbieter für Serverereignisse auf SQL Server zu, indem sie WQL-Anweisungen (WMI Query Language) ausgeben. WQL ist eine vereinfachte Teilmenge von Structured Query Language (SQL) mit einigen WMI-spezifischen Erweiterungen. Unter Verwendung von WQL ruft eine Anwendung einen Ereignistyp aus einer spezifischen Instanz von SQL Server, einer Datenbank oder einem Datenbankobjekt ab. Das einzige zurzeit unterstützte Objekt ist queue. Der WMI-Anbieter für Serverereignisse übersetzt die Abfrage in eine Ereignisbenachrichtigung, die für Datenbankbereiche oder Objektbereiche in der Zieldatenbank bzw. für Serverbereiche in der master-Datenbank 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 Klassen und Eigenschaften für den WMI-Anbieter für Serverereignisse.

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. Überprüfen Sie die einzelnen, unter Klassen und Eigenschaften für WMI-Anbieter für Serverereignisse aufgeführten Ereignisse, um deren Eigenschaften zu ermitteln. 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, durch Trennzeichen getrennt, mehrmals abgefragt werden kann.

  • *
    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 Klassen und Eigenschaften für den WMI-Anbieter für Serverereignisse. Beachten Sie, dass event type-Namen dem gleichen event_type entsprechen. | event_group, die angegeben werden kann, wenn Sie mit CREATE EVENT NOTIFICATION manuell eine Ereignisbenachrichtigung erstellen. Beispiele für event type sind CREATE_TABLE, LOCK_DEADLOCK, DDL_USER_EVENTS und TRC_DATABASE.

    HinweisHinweis

    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. So lösen beispielsweise die CREATE TYPE-Anweisung und die gespeicherte Prozedur sp_addtype beide eine Ereignisbenachrichtigung aus, die bei einem CREATE_TYPE-Ereignis erstellt wird. Die gespeicherte Prozedur sp_rename hingegen löst keine Ereignisbenachrichtigungen aus. Weitere Informationen finden Sie unter DDL-Ereignisse.

  • where_condition
    Ein WHERE-Klausel-Prädikat, das aus event_property-Namen und logischen sowie Vergleichsoperatoren besteht. Der where_condition -Parameter bestimmt den Gültigkeitsbereich, in dem die entsprechende Ereignisbenachrichtigung in der Zieldatenbank registriert wird. Er kann zudem als Filter dienen, um ein bestimmtes Schema oder Objekt zu isolieren, aus dem ein event_type. abgefragt werden soll. 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-Syntax des WMI-Anbieters für Serverereignisse bestimmt Folgendes:

  • Den Gültigkeitsbereich, in dem der Anbieter den angegebenen event_type abzurufen versucht: Serverebene, Datenbankebene oder Objektebene (das einzige zurzeit unterstützte Objekt ist queue). 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, die interne Aktivität auf dem Server und bezüglich des Netzwerkverkehrs zwischen der Instanz von SQL Server und dem WMI-Hostprozess zu reduzieren. Der Anbieter untersucht den in der FROM-Klausel angegebenen event_type-Parameter und die Bedingungen der WHERE-Klausel und versucht anschließend, die zugrunde liegende EVENT NOTIFICATION mit dem engsten Gültigkeitsbereich 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 wird, 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 so lange nicht an den Client zurückgegeben, bis die AdventureWorks2012 -Datenbank erstellt wurde.

Der where_condition-Parameter kann auch als Filter fungieren, um die Abfrage auf eine bestimmte Datenbank, ein bestimmtes Schema oder 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 beispielsweise SchemaName='X' AND ObjectType='Y' AND ObjectName='Z' in der WHERE-Klausel angegeben werden, wird versucht, die Ereignisbenachrichtigung direkt für das Z-Objekt im X zu registrieren. Die Registrierung ist erfolgreich, wenn der Client die erforderlichen Berechtigungen hat. Beachten Sie, dass Ereignisse auf Objektebene gegenwärtig nur in Warteschlangen und nur für den 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 über den geeigneten Gültigkeitsbereich für das Registrieren von Ereignissen finden Sie unter Entwerfen von Ereignisbenachrichtigungen. Versuche, eine WQL-Abfrage zu registrieren, deren event_type-Parameter nur auf dem Server registriert werden kann, werden immer auf Serverebene durchgeführt. 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.

Ereignisbenachrichtigungen im Serverbereich werden in der master-Datenbank erstellt und können mithilfe der Katalogsicht sys.server_event_notifications nach Metadaten abgefragt werden.

Ereignisbenachrichtigungen im Serverbereich oder im Objektbereich werden in der angegebenen Datenbank erstellt und können mithilfe der sys.event_notifications-Katalogsicht 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 alle SERVER_MEMORY_CHANGE-Ablaufverfolgungsereignisse ab, die in der Instanz von SQL Server auftreten.

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'

Siehe auch

Konzepte

Konzepte des WMI-Anbieters für Serverereignisse

Andere Ressourcen

Ereignisbenachrichtigung (Datenbankmodul)