Ereignisbenachrichtigungen
Mit Ereignisbenachrichtigungen werden Informationen zu Ereignissen an einen Service Broker -Dienst gesendet. Ereignisbenachrichtigungen werden als Reaktion auf eine Vielzahl von DDL-Anweisungen (Transact-SQL Data Definition Language) und SQL-Ablaufverfolgungsereignissen ausgeführt, indem Informationen zu diesen Ereignissen an einen Service Broker-Dienst gesendet werden.
Ereignisbenachrichtigungen können für die folgenden Aufgaben verwendet werden:
Protokollieren und Prüfen von Änderungen oder Aktivitäten, die für die Datenbank auftreten.
Ausführen einer Aktion als Antwort auf ein Ereignis auf asynchrone statt auf synchrone Weise.
Ereignisbenachrichtigungen können eine Programmieralternative zu DDL-Triggern und zur SQL-Ablaufverfolgung bieten.
Vorteile von Ereignisbenachrichtigungen
Ereignisbenachrichtigungen werden asynchron außerhalb des Bereichs einer Transaktion ausgeführt. Im Gegensatz zu DDL-Triggern können Ereignisbenachrichtigungen deshalb in einer Datenbankanwendung als Reaktion auf Ereignisse verwendet werden, ohne Ressourcen zu belegen, die von der unmittelbaren Transaktion definiert werden.
Im Gegensatz zur SQL-Ablaufverfolgung kann mithilfe von Ereignisbenachrichtigungen eine Aktion innerhalb einer SQL Server -Instanz als Antwort auf ein Ereignis der SQL-Ablaufverfolgung ausgeführt werden.
Ereignisdaten können von Anwendungen, die zusammen mit SQL Server ausgeführt werden, zum Nachverfolgen des Fortschritts sowie zum Treffen von Entscheidungen verwendet werden. Die folgende Ereignisbenachrichtigung sendet z. B. bei jeder Ausgabe einer ALTER TABLE -Anweisung in der AdventureWorks2012 -Beispieldatenbank eine Benachrichtigung an einen bestimmten Dienst:
USE AdventureWorks2012;
GO
CREATE EVENT NOTIFICATION NotifyALTER_T1
ON DATABASE
FOR ALTER_TABLE
TO SERVICE '//Adventure-Works.com/ArchiveService' ,
'8140a771-3c4b-4479-8ac0-81008ab17984';
Konzepte der Ereignisbenachrichtigungen
Wenn eine Ereignisbenachrichtigung erstellt wird, werden eine oder mehrere Service Broker -Konversationen zwischen einer Instanz von SQL Server und dem von Ihnen angegebenen Zieldienst geöffnet. Die Konversationen bleiben in der Regel geöffnet, so lange die Ereignisbenachrichtigung als Objekt für die Serverinstanz vorhanden ist. In einigen Fehlerfällen können die Konversationen geschlossen werden, bevor die Ereignisbenachrichtigung gelöscht wird. Diese Konversationen werden niemals für Ereignisbenachrichtigungen freigegeben. Jede Ereignisbenachrichtigung besitzt ihre eigenen, exklusiven Konversationen. Das explizite Beenden einer Konversation verhindert, dass der Zieldienst weitere Nachrichten empfängt, und die Konversation wird bei der nächsten Auslösung der Ereignisbenachrichtigung nicht erneut geöffnet.
Ereignisinformationen werden als Variable vom Typ xml an den Service Broker-Dienst übermittelt, die Informationen über den Zeitpunkt eines Ereignisses, das betroffene Datenbankobjekt, die betroffene Transact-SQL-Batch-Anweisung und andere Informationen bereitstellt. Weitere Informationen zum XML-Schema, das von Ereignisbenachrichtigungen generiert wird, finden Sie unter EVENTDATA (Transact-SQL).
Ereignisbenachrichtigungen im Vergleich zur Trigger
In der folgenden Tabelle werden Trigger und Ereignisbenachrichtigungen verglichen und Unterschiede aufgezeigt.
| Trigger | Ereignisbenachrichtigungen |
|---|---|
| DML-Trigger reagieren auf DML-Ereignisse. DDL-Trigger reagieren auf DDL-Ereignisse (Data Definition Language, Datendefinitionssprache). | Ereignisbenachrichtigungen reagieren auf DDL-Ereignisse und eine Teilmenge von SQL-Ablaufverfolgungsereignissen. |
| Trigger können verwalteten Transact-SQL- oder CLR-Code (Common Language Runtime) ausführen. | Ereignisbenachrichtigungen führen keinen Code aus. Stattdessen senden xml sie Nachrichten an einen Service Broker-Dienst. |
| Trigger werden synchron innerhalb des Bereichs der Transaktionen verarbeitet, die ihre Auslösung bewirken. | Ereignisbenachrichtigungen können asynchron verarbeitet werden und werden nicht innerhalb des Bereichs der Transaktionen ausgeführt, die ihre Auslösung bewirken. |
| Der Consumer eines Triggers ist eng mit dem Ereignis verkoppelt, das seine Auslösung bewirkt. | Der Consumer einer Ereignisbenachrichtigung ist von dem Ereignis entkoppelt, das seine Auslösung bewirkt. |
| Trigger müssen auf dem lokalen Server verarbeitet werden. | Ereignisbenachrichtigungen können auf einem Remoteserver verarbeitet werden. |
| Für Trigger kann ein Rollback durchgeführt werden. | Für Ereignisbenachrichtigungen kann kein Rollback durchgeführt werden. |
| Die Namen von DML-Triggern stammen aus dem Bereich des Schemas. Die Namen von DDL-Triggern stammen aus dem Bereich der Datenbank oder des Servers. | Die Namen von Ereignisbenachrichtigungen stammen aus dem Bereich des Servers oder der Datenbank. Ereignisbenachrichtigungen für ein QUEUE_ACTIVATION-Ereignis stammen aus dem Bereich einer bestimmten Warteschlange. |
| DML-Trigger weisen den gleichen Besitzer wie die Tabellen auf, auf die sie angewendet werden. | Der Besitzer einer Ereignisbenachrichtigung für eine Warteschlange kann einen anderen Besitzer als das Objekt aufweisen, auf das diese angewendet wird. |
| Trigger unterstützen die EXECUTE AS-Klausel. | Ereignisbenachrichtigungen unterstützen die EXECUTE AS-Klausel nicht. |
DDL-Triggerereignisinformationen können mithilfe der EVENTDATA-Funktion erfasst werden, die einen xml Datentyp zurückgibt. |
Ereignisbenachrichtigungen senden xml Ereignisinformationen an einen Service Broker-Dienst. Die Informationen werden für das gleiche Schema formatiert, das auch die EVENTDATA-Funktion verwendet. |
| Metadaten zu Triggern sind in den sys.triggers - und sys.server_triggers -Katalogsichten enthalten. | Metadaten zu Ereignisbenachrichtigungen sind in den sys.event_notifications - und sys.server_event_notifications -Katalogsichten enthalten. |
Ereignisbenachrichtigungen im Vergleich zur SQL-Ablaufverfolgung
Die folgende Tabelle vergleicht das Verwenden von Ereignisbenachrichtigungen mit der SQL-Ablaufverfolgung zum Überwachen von Serverereignissen und führt die jeweiligen Merkmale auf.
| SQL-Ablaufverfolgung | Ereignisbenachrichtigungen |
|---|---|
| Die SQL-Ablaufverfolgung bewirkt keinen zusätzlichen Verwaltungsaufwand, der auf Transaktionen zurückzuführen ist. Die Verpackung der Daten ist effizient. | Durch das Erstellen der als XML formatierten Ereignisdaten und Senden der Ereignisbenachrichtigung entsteht zusätzlicher Verwaltungsaufwand. |
| Die SQL-Ablaufverfolgung kann beliebige Ablaufverfolgungs-Ereignisklassen überwachen. | Ereignisbenachrichtigungen können Untergruppen von Ablaufverfolgungs-Ereignisklassen und außerdem alle DDL-Ereignisse (Data Definition Language) überwachen. |
| Sie können anpassen, welche Datenspalten in einem Ablaufverfolgungsereignis generiert werden sollen. | Das Schema der durch Ereignisbenachrichtigungen zurückgegebenen Ereignisdaten im XML-Format ist fest. |
| Durch DDL generierte Ablaufverfolgungsereignisse werden unabhängig davon generiert, ob für die DDL-Anweisung ein Rollback durchgeführt wird. | Ereignisbenachrichtigungen werden nicht ausgelöst, wenn für das Ereignis in der zugehörigen DDL-Anweisung ein Rollback durchgeführt wird. |
| Das Verwalten des Zwischenflusses der Daten der Ablaufverfolgungsereignisse beinhaltet das Auffüllen und Verwalten von Ablaufverfolgungsdateien oder -tabellen. | Die Zwischenverwaltung der Ereignisbenachrichtigungsdaten erfolgt automatisch über Service Broker-Warteschlangen. |
| Die Ablaufverfolgung muss bei jedem Neustart des Servers ebenfalls neu gestartet werden. | Nach ihrer Registrierung sind Ereignisbenachrichtigungen serverzyklenübergreifend persistent und transaktiv. |
| Nach der Initiierung kann das Auslösen von Ablaufverfolgungen nicht mehr gesteuert werden. Beendigungszeiten und Filterzeiten können für das Angeben des Zeitpunkts ihrer Initiierung verwendet werden. Auf Ablaufverfolgungen wird durch Abrufen der entsprechenden Ablaufverfolgungsdatei zugegriffen. | Ereignisbenachrichtigungen können mithilfe der WAITFOR-Anweisung für die Warteschlange gesteuert werden, die die Nachricht empfängt, die von der Ereignisbenachrichtigung generiert wurde. Auf diese kann durch Abrufen der Warteschlange zugegriffen werden. |
| ALTER TRACE ist die Mindestberechtigung, die zum Erstellen einer Ablaufverfolgung erforderlich ist. Außerdem ist die Berechtigung zum Erstellen einer Ablaufverfolgungsdatei auf dem entsprechenden Computer erforderlich. | Die Mindestberechtigung hängt vom Typ der erstellten Ereignisbenachrichtigung ab. Die RECEIVE-Berechtigung wird auch für die entsprechende Warteschlange benötigt. |
| Ablaufverfolgungen können remote empfangen werden. | Ereignisbenachrichtigungen können remote empfangen werden. |
| Ablaufverfolgungsereignisse werden mithilfe gespeicherter Systemprozeduren implementiert. | Ereignisbenachrichtigungen werden mithilfe einer Kombination aus Database Engine und Service BrokerTransact-SQL-Anweisungen implementiert. |
| Auf Ablaufverfolgungsdaten kann über Programmcode durch Abfragen der entsprechenden Ablaufverfolgungstabelle, durch Analysieren der Ablaufverfolgungsdatei oder mithilfe der TraceReader-Klasse von SMO ( SQL Server Management Objects) zugegriffen werden. | Auf Ereignisdaten wird über Programmcode durch Ausgeben von XQuery für die als XML formatierten Ereignisdaten oder mithilfe der SMO-Ereignisklassen zugegriffen. |
Tasks der Ereignisbenachrichtigung
| Aufgabe | Thema |
|---|---|
| Beschreibt, wie Ereignisbenachrichtigungen erstellt und implementiert werden. | Implementieren von Ereignisbenachrichtigungen |
| Beschreibt, wie für Ereignisbenachrichtigungen, die Nachrichten an eine Service Broker-Instanz auf einem Remoteserver senden, die Dialogsicherheit von Service Broker konfiguriert wird. | Konfigurieren der Dialogsicherheit für Ereignisbenachrichtigungen |
| Beschreibt, wie Informationen zu Ereignisbenachrichtigungen zurückgegeben werden. | Abrufen von Informationen zu Ereignisbenachrichtigungen |