<\/p>\n
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.<\/b><\/p>\n
Die Erweiterten Ereignisse<\/b>, die wir in der deutschen Version des SQL Server Management Studio finden, h<\/b>eißen im Englischen Extended Events <\/b>oder – etwas stylischer – XEvents<\/b>. Wir wollen daher in diesem Beitrag auch diese Bezeichnung wählen.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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 <\/b>ü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.<\/p>\nWas erfassen die XEvents<\/h2>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
In Visual Studio finden Sie die XEvents im Objekt-Explorer unter dem Eintrag Verwaltung|Erweiterte Ereignisse <\/b>des Datenbankservers (siehe Bild 1).<\/p>\n
![\"Die](\"..\/fileadmin\/_temp_\/2018_05\/pic_1158_001.png\")
<\/p>\n
Bild 1: Die XEvents im Objekt-Explorer<\/span><\/b><\/p>\n Darunter befindet sich ein Eintrag namens Sitzungen<\/b>. Hier finden Sie bereits zwei Einträge: AlwaysOn_health <\/b>und system_health<\/b>. AlwaysOn_health <\/b>wird in Zusammenhang mit der Ausfallsicherheit des SQL Servers verwendet.<\/p>\n Interessant ist letzterer Eintrag: system_health<\/b> speichert alle möglichen Informationen über den Betrieb des SQL Servers. <\/p>\n Diese können beispielsweise von Microsoft beim Auftreten von Problemen zur Analyse herangezogen werden.<\/p>\n Eine Sitzung ist, wenn Sie zuvor bereits mit dem SQL Server Profiler gearbeitet haben, mit einer Ablaufverfolgung zu vergleichen.<\/p>\n 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.<\/p>\n 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 <\/b>im Objekt-Explorer und wählen aus dem Kontextmenü den Eintrag Neue Sitzung… <\/b>aus. Es erscheint der Dialog Neue Sitzung<\/b>. 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.<\/p>\n Auf der ersten Seite namens Allgemein<\/b> geben wir den Namen der Sitzung an, hier Untersuchung Authentifizierung<\/b>. Das Feld Vorlage <\/b>lassen wir auf Bild 2: Anlegen einer neuen XEvents-Sitzung<\/span><\/b><\/p>\n Damit wechseln wir auf die zweite Seite namens Ereignisse<\/b>. 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 <\/b>ein, zum Beispiel completed<\/b>. 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. <\/p>\n <\/p>\n Bild 3: Suchen nach den benötigten Ereignissen<\/span><\/b><\/p>\n 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 <\/b>und sql_statement_completed <\/b>in die rechte Liste kopieren.<\/p>\n Danach suchen wir noch nach dem Ereignis, das beim Starten einer SQL-Anweisung ausgelöst wird, nämlich sql_statement_starting<\/b>. Auch dieses fügen wir per Doppelklick der Liste auf der rechten Seite hinzu.<\/p>\n 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.<\/p>\n 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.<\/p>\n Um diese Einstellungen vorzunehmen, wechseln wir mit der Schaltfläche Konfigurieren <\/b>zum zweiten Teil der Seite Ereignisse<\/b>. Hier finden wir in der linken Liste die im vorherigen Teil ausgewählten Ereignisse. In der rechten Liste finden wir drei Bereiche:<\/p>\n Wir wollen globale Felder für alle drei Ereignisse ausgeben. Da wir ermitteln wollen, welcher Benutzer beim Auslösen des Zugriffs auf die Datenbank an diese angemeldet ist, wollen wir die globalen Felder username<\/b>, nt_username <\/b>und zusätzlich mit sql_text <\/b>den Text der ausgeführten Anweisung ausgeben. Um diese für alle drei Ereignisse festzulegen, markieren wir die Ereignisse im Listenfeld links und setzen dann einen Haken bei den gewünschten globalen Feldern. Dies sieht dann wie in Bild 4 aus.<\/p>\n Bild 4: Festlegen der globalen Felder, die beim Auslösen der Ereignisse ausgegeben werden sollen<\/span><\/b><\/p>\n Wir wollen nur die Ereignisse sehen, die für die Datenbank Suedsturm_SQL <\/b>ausgelöst werden. Dazu aktivieren wir den Bereich Filter (Prädikat)<\/b>. Um den Filter hinzuzufügen, klicken Sie auf die erste leere Zeile in diesem Bereich. Dann wählen Sie unter Feld eines der globalen Felder oder der Ereignisfelder aus, die per Kombinationsfeld zur Auswahl angeboten werden – in diesem Fall sqlserver.database_name<\/b>. Die erste Zeile mit dem neuen Filter sieht anschließend wie in Bild 5 aus.<\/p>\n Bild 5: Setzen eines Filters für die zu trackenden Ereignisse<\/span><\/b><\/p>\n Im Bereich Ereignisfelder <\/b>finden wir erst einmal keine Einträge vor, wenn wir noch alle drei ausgewählten Ereignisse markiert haben. Der Grund ist, dass es keine gemeinsamen Ereignisfelder für diese Kombination aus Ereignissen gibt. Erst, wenn wir nur eines der Ereignisse markieren, erscheinen hier einige Listeneinträge (siehe Bild 6). Für unser Beispiel brauchen wir keine der hier aufgeführten Eigenschaften zu tracken.<\/p>\n Bild 6: Setzen der auszugebenden Ereignisfelder<\/span><\/b><\/p>\n Damit können wir die Seite verlassen und zur Seite Datenspeicher <\/b>wechseln. Hier können Sie festlegen, ob die getrackten Informationen in einer Datei gespeichert werden sollen oder an einer anderen Stelle. Wir haben weiter vorn schon angegeben, dass wir die Ereignisinformationen direkt live bei der Aufzeichnung sehen wollen, also müssen wir keine weiteren Angaben machen.<\/p>\n Nun können wir den Dialog mit einem Klick auf OK<\/b> schließen und dafür sorgen, dass das Tracking der Ereignisse direkt gestartet wird. Nach dem Schließen des Dialogs wird im SQL Server Management Studio ein Fenster mit dem Titel Live Data <\/b>eingeblendet.<\/p>\n Wir starten nun unsere Access-Anwendung, die wir mit dem Backend verknüpfen wollen und verwenden den Login-Dialog, um uns mit den Daten Benutzer3\/password <\/b>anzumelden. Danach können wir gleich den Blick auf das SQL Server Management Studio richten, wo sich stramme 108 Ereignisse angesammelt haben (siehe Bild 7). Die obere Liste enthält die einzelnen Ereignisse samt Bezeichnung und Zeitstempel der Ausführung. Die untere Liste zeigt die Eigenschaften für das aktuell im oberen Bereich markierte Ereignis an.<\/p>\n Bild 7: Eigenschaften des ersten Ereignisses beim Anmelden an die Datenbank<\/span><\/b><\/p>\n Wir wollen diese nicht einzeln analysieren, sondern uns die relevanten Informationen anschauen. In diesem Fall die Eigenschaft username<\/b>, die korrekt den Wert Benutzer3 <\/b>enthält – also den Benutzer, unter dem wir uns per SQL Server-Authentifizierung am SQL Server angemeldet haben.<\/p>\n Und nun wird es interessant: Wir schließen die Access-Anwendung und öffnen diese erneut. Auf diese Weise beenden wir die Access-Session und löschen somit theoretisch auch die Anmeldung dieser Session am SQL Server. Im Beitrag SQL Server-Zugriff ohne gespeichertes Kennwort <\/b>haben wir ja an dieser Stelle festgestellt, dass wir trotz fehlender Anmeldung auf die Daten der Tabelle zugreifen konnten. Nun wollen wir wissen, ob wir mit dem gleichen Benutzer angemeldet werden wir zuvor oder welcher Benutzer in diesem Fall verwendet wird.<\/p>\n Dazu öffnen wir nun eine Tabelle, beispielsweise tblAnreden<\/b>. Leider bietet die Liste der Ereignisse keine Möglichkeit zum Leeren, daher müssen wir uns an der Uhrzeit orientieren, um die neu hinzugefügten Ereignisse von denen der vorherigen Aktion unterscheiden zu können. Dennoch finden wir schnell eines der zuletzt ausgelösten Ereignisse und die entsprechenden Eigenschaften. Und hier ist des Rätsels Lösung: Der aktuelle Benutzer beim Zugriff auf die Datenbank ist der aktuell angemeldete Windows-Benutzer. Der SQL Server versucht also, wenn kein SQL Server-Konto beim Anmelden verwendet wird, das aktuelle Windows-Benutzerkonto zu nutzen. Das gelingt in diesem Fall, da wir die Datenbank ja mit dem aktuell angemeldeten Benutzer erstellt haben (siehe Bild 8).<\/p>\n Bild 8: Ermitteln des beim Auslösen des Ereignisses angemeldeten Benutzers<\/span><\/b><\/p>\n Wenn Sie die Sitzung nicht direkt nach dem Erstellen der Sitzung starten wollen, können Sie dies auch noch nachholen. Dazu wählen Sie einfach den Kontextmenü-Eintrag Sitzung starten <\/b>des Eintrags für die jeweilige Sitzung im Objekt-Explorer aus (siehe Bild 9). Dort können Sie auch die aktuelle Sitzung beenden.<\/p>\n Bild 9: Starten einer Sitzung<\/span><\/b><\/p>\n Eine Möglichkeit, die Liste der Ereignisse im Fenster Live Data <\/b>zu leeren, ist das Schließen des Fensters und das erneute Aktivieren der Anzeige der Livedaten. Den Eintrag Livedaten <\/b>ansehen finden Sie ebenfalls im Kontextmenü der jeweiligen Sitzung.<\/p>\n Anfang hatten Sie die Möglichkeit, eine neue Sitzung auf Basis einer Vorlage zu erstellen. Um eine solche Sitzungsvorlage zu erstellen, exportieren Sie diese mit dem Kontextmenü-Eintrag Sitzung exportieren… <\/b>beispielsweise unter dem Namen Beispielvorlage.xml<\/b>.<\/p>\n Wenn Sie danach eine neue Sitzung erstellen, können Sie die soeben gespeicherte Vorlage in der Liste der Vorlagen auswählen (siehe Bild 10).<\/p>\n Bild 10: Anlegen einer neuen Sitzung auf Basis einer benutzerdefinierten Vorlage<\/span><\/b><\/p>\n Mit den XEvents, zu Deutsch „Erweiterte Ereignisse“, können Sie alle Aktionen, die im SQL Server ausgeführt werden, tracken und detaillierte Informationen über jedes Ereignis ausgeben lassen. Auf diese Weise können Sie nicht nur kleinere Rätsel lösen wie im Beispiel dieses Beitrags, sondern auch noch wesentlich wichtigere Aufgaben erledigen – zum Beispiel die Performance-Optimierung einer Verbindung zwischen einem Access-Frontend und einem SQL Server-Backend. Früher oder später werden wir uns in einem weiteren Beitrag der Behebung eines Performance-Problems widmen.<\/p>\n","protected":false},"excerpt":{"rendered":" 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.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662018,66052018,44000022],"tags":[],"class_list":["post-55001158","post","type-post","status-publish","format-standard","hentry","category-662018","category-66052018","category-SQL_Server_und_Co"],"yoast_head":"\nWas wir untersuchen wollen<\/h2>\n
Neue XEvents-Sitzung anlegen<\/h2>\n
![\"Anlegen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1158_002.png\")
<\/p>\nEreignisse definieren<\/h2>\n
![\"Suchen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1158_003.png\")
<\/p>\n\n
Globale Felder definieren<\/h2>\n
![\"Festlegen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1158_004.png\")
<\/p>\nFilter setzen<\/h2>\n
![\"Setzen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1158_005.png\")
<\/p>\nEreignisfelder hinzufügen<\/h2>\n
![\"Setzen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1158_006.png\")
<\/p>\nFertigstellen und starten<\/h2>\n
![\"Eigenschaften](\"..\/fileadmin\/_temp_\/2018_05\/pic_1158_007.png\")
<\/p>\n![\"Ermitteln](\"..\/fileadmin\/_temp_\/2018_05\/pic_1158_008.png\")
<\/p>\nXEvents-Sitzung manuell starten<\/h2>\n
![\"Starten](\"..\/fileadmin\/_temp_\/2018_05\/pic_1158_009.png\")
<\/p>\nXEvents-Sitzung live ansehen<\/h2>\n
Sitzung als Vorlage speichern<\/h2>\n
![\"Anlegen](\"..\/fileadmin\/_temp_\/2018_05\/pic_1158_010.png\")
<\/p>\nZusammenfassung und Ausblick<\/h2>\n