Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.
Wenn es darum ging, die Zugriffe auf eine SQL Server-Datenbank zu tracken – sei es zur Performance-Messung oder zur Optimierung einer Datenbank – war bis vor kurzem der SQL Server Profiler die Anwendung der Wahl. Mittlerweile gibt es allerdings einen in das SQL Server Management Studio integrierten Objekttyp namens „Erweiterte Ereignisse“. In diesem Beitrag wollen wir Ihnen diesen Objekttyp vorstellen. Das einfache Beispiel zu diesem Zweck stammt aus einem anderen Beitrag namens „SQL Server-Zugriff ohne gespeichertes Kennwort“. Hier wollen wir herausfinden, unter welchem Benutzer ein Zugriff auf eine SQL Server-Datenbank von Access aus erfolgt, bei dem offensichtlich gar kein Benutzer angemeldet ist.
Die Erweiterten Ereignisse, die wir in der deutschen Version des SQL Server Management Studio finden, heißen im Englischen Extended Events oder – etwas stylischer – XEvents. Wir wollen daher in diesem Beitrag auch diese Bezeichnung wählen.
Die XEvents sind Ereignisse, die durch verschiedene Aktionen des SQL Servers ausgelöst werden und in die Sie eingreifen können, indem Sie verschiedene Informationen, die bei diesen Ereignissen anfallen, ausgeben oder speichern lassen.
Bis vor einigen SQL Server-Versionen war der SQL Server Profiler das Mittel der Wahl, wenn es um die Aufzeichnung und die Analyse von Ereignissen im SQL Server ging. Mit dem SQL Server 2008 wurden jedoch die XEvents eingeführt, die zunächst nur per T-SQL definiert werden konnten (ein Vorteil gegenüber den Ereignissen im Profiler), mittlerweile aber auch über die Benutzeroberfläche des SQL Server Management Studios angelegt werden können.
Access und XEvents
Für uns als Access-Entwickler werden die XEvents interessant, wenn wir eine Kombination aus Access-Frontend und SQL Server-Backend verwenden und hier den Datenverkehr zwischen dem Frontend und dem Backend analysieren wollen – sei es, um die Performance zu optimieren, die Menge der übertragenen Daten zu prüfen oder auch um andere Dinge herauszufinden – wie eben um das Problem zu lösen, dass uns im Beitrag SQL Server-Zugriff ohne gespeichertes Kennwort über den Weg gelaufen ist. Dort haben wir gerätselt, wie es sein kann, dass man mit einer Access-Anwendung auf die Tabellen einer SQL Server-Datenbank zugreifen kann, obwohl sich der geplante Benutzer überhaupt nicht angemeldet hat.
Was erfassen die XEvents
Wenn wir hier alle Daten beschreiben wollten, die XEvents erfassen können, würde das den Rahmen sprengen. Uns interessieren aber auch nur diejenigen Ereignisse, die beim Zugriff unserer Access-Anwendung auf das SQL Server-Backend ausgelöst werden.
Um das auf zunächst in Objektform zu fassen: Wir können Zugriffe auf die per ODBC verknüpften Tabellen erfassen, Zugriffe über Aktionsabfragen und Aufrufe von SQL Server-Objekten wie gespeicherte Prozeduren, Funktionen und Trigger.
Wo erfassen die XEvents die Ereignisse
Die mit XEvents erfassten Ereignisse können Sie beispielsweise in einer Datei speichern. Für unsere Zwecke gestaltete es sich allerdings als praktisch, die mit den Ereignissen erfassten Daten direkt im SQL Server Management Studio auszugeben.
XEvents im SQL Server Management Studio
In Visual Studio finden Sie die XEvents im Objekt-Explorer unter dem Eintrag Verwaltung|Erweiterte Ereignisse des Datenbankservers (siehe Bild 1).
Bild 1: Die XEvents im Objekt-Explorer
Darunter befindet sich ein Eintrag namens Sitzungen. Hier finden Sie bereits zwei Einträge: AlwaysOn_health und system_health. AlwaysOn_health wird in Zusammenhang mit der Ausfallsicherheit des SQL Servers verwendet.
Interessant ist letzterer Eintrag: system_health speichert alle möglichen Informationen über den Betrieb des SQL Servers.
Diese können beispielsweise von Microsoft beim Auftreten von Problemen zur Analyse herangezogen werden.
Eine Sitzung ist, wenn Sie zuvor bereits mit dem SQL Server Profiler gearbeitet haben, mit einer Ablaufverfolgung zu vergleichen.
Was wir untersuchen wollen
Wie weiter oben erwähnt, gab es bei einer Frontend-Datenbank das Problem, dass man sich vermeintlich ohne vorherige Anmeldung an eine Datenbank im SQL Server anmelden konnte. Wir wollen uns ansehen, welche Informationen beim Zugriff auf die SQL Server-Datenbank ausgetauscht werden, um herauszufinden, wo der Denkfehler liegt.
Neue XEvents-Sitzung anlegen
Damit Sie besser verstehen, wie eine XEvents-Sitzung funktioniert, legen wir am besten einfach einmal eine an. Dazu klicken Sie mit der rechten Maustaste auf das Element Sitzungen im Objekt-Explorer und wählen aus dem Kontextmenü den Eintrag Neue Sitzung… aus. Es erscheint der Dialog Neue Sitzung. Hier gibt es, wie bei den meisten Dialogen zum Anlegen oder Bearbeiten von SQL Server-Elementen, links die Seitenauswahl und rechts die Inhalte der jeweiligen Seite.
Auf der ersten Seite namens Allgemein geben wir den Namen der Sitzung an, hier Untersuchung Authentifizierung. Das Feld Vorlage lassen wir auf
Bild 2: Anlegen einer neuen XEvents-Sitzung
Ereignisse definieren
Damit wechseln wir auf die zweite Seite namens Ereignisse. Auf dieser Seite finden Sie links ein Listenfeld mit allen verfügbaren Ereignissen – sehr vielen Ereignissen. Wir benötigen nur sehr wenige davon. Damit wir diese finden, geben wir einen Teil des Namens in das Feld mit dem Inhalt Ereignisse suchen ein, zum Beispiel completed. Damit werden nur noch die in Bild 3 sichtbaren Ereignisse angezeigt. Klicken wir auf eines der Ereignisse, zeigt das Feld links unter der Liste die Beschreibung des Ereignisses an. Die Liste rechts unter der Liste liefert alle Ereignisfelder, also die Eigenschaften, die beim Eintreten des Ereignisses ausgegeben werden können.
Bild 3: Suchen nach den benötigten Ereignissen
Der erste Schritt ist nun, dass Sie die zu verfolgenden Ereignisse von der linken in die rechte Liste übertragen, zum Beispiel per Doppelklick auf den jeweiligen Eintrag. In diesem Fall wollen wir so die beiden Ereignisse rpc_completed und sql_statement_completed in die rechte Liste kopieren.
Danach suchen wir noch nach dem Ereignis, das beim Starten einer SQL-Anweisung ausgelöst wird, nämlich sql_statement_starting. Auch dieses fügen wir per Doppelklick der Liste auf der rechten Seite hinzu.
Nun wollen wir festlegen, welche Informationen wir beim Auslösen der Ereignisse erhalten möchten und unter welchen Bedingungen die Ereignisse ausgelöst werden. Bedingungen Nun: Ein SQL Server mit mehreren Access-Frontends erhält zur Laufzeit eine Menge Anfragen – Anfragen von verschiedenen Frontend-Rechnern und an verschiedene Backend-Datenbanken.
Also macht es Sinn, nur eine gewisse Auswahl an Ereignissen etwa nur für eine spezielle Datenbank oder einen speziellen Nutzer. Sie könnten auch nur Ereignisse für eine bestimmte Tabelle tracken.
Um diese Einstellungen vorzunehmen, wechseln wir mit der Schaltfläche Konfigurieren zum zweiten Teil der Seite Ereignisse. Hier finden wir in der linken Liste die im vorherigen Teil ausgewählten Ereignisse. In der rechten Liste finden wir drei Bereiche:
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
Testzugang
eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel
diesen und alle anderen Artikel mit dem Jahresabo