{"id":21233,"date":"2022-06-10T11:05:00","date_gmt":"2022-06-10T09:05:00","guid":{"rendered":"https:\/\/www.sysbus.eu\/?p=21233"},"modified":"2022-08-30T09:43:27","modified_gmt":"2022-08-30T07:43:27","slug":"im-test-solarwinds-sql-sentry-microsoft-sql-server-durchleuchtet","status":"publish","type":"post","link":"https:\/\/www.sysbus.eu\/?p=21233","title":{"rendered":"Im Test: SolarWinds SQL Sentry – Microsoft SQL Server durchleuchtet"},"content":{"rendered":"\n

Mit dem Werkzeug „SQL Sentry“ bietet Solarwinds eine \u00dcberwachungsl\u00f6sung f\u00fcr den SQL Server von Microsoft. Das Produkt versetzt Administratoren in die Lage, sowohl die Leistungsdaten der Virtuellen Maschine oder der Server-Hardware, auf der der Datenbank-Server l\u00e4uft, als auch die Leistungsdaten der Datenbankinstanzen, die jeweils \u00fcberwacht werden, in einem einheitlichen Dashboard anzusehen. Dar\u00fcber hinaus bietet das Tool auch noch einige andere n\u00fctzliche Features an. Wir haben im Testlabor analysiert, wie die Installation des Produkts abl\u00e4uft und wie die t\u00e4gliche Arbeit damit aussieht.<\/p>\n\n\n\n

\"\"<\/a>
Bild: SolarWinds<\/figcaption><\/figure>\n\n\n\n\n\n\n\n

Dieser Beitrag ist auch als PDF verf\u00fcgbar: https:\/\/www.sysbus.eu\/wp-content\/uploads\/2022\/05\/IT_Testlab_Test_Solarwinds_SQL_Sentry.pdf<\/a>.<\/p>\n\n\n\n

Neben dem angesprochenen Dashboard erm\u00f6glicht ein leistungsf\u00e4higes Alarm- und Response-System beim Eintritt bestimmter Zust\u00e4nde automatische Reaktionen durch SQL Sentry. Das Tool kann sowohl Befehle ausf\u00fchren, als auch Benachrichtigungen verschicken. Frei definierbare Konditionen erm\u00f6glichen es in diesem Zusammenhang, genau auf bestimmte Zust\u00e4nde zu reagieren. Darauf gehen wir sp\u00e4ter noch genauer ein.<\/p>\n\n\n\n

Abgesehen davon geh\u00f6ren auch noch Abfrage- und Indexanalysen, Speicherprognosen und ein Ereigniskalender zum Leistungsumfang von SQL Sentry. Die Speicherprognosen erstellt das Tool mit Hilfe von Maschine-Learning-Algorithmen. Dabei ber\u00fccksichtigt es Workloads und setzt genaue Voraussagen zur Disk-Kapazit\u00e4t ein. Eine Reporting-Funktion hilft dabei, Downtimes zu verhindern.<\/p>\n\n\n\n

\"\"<\/a>
Das Hinzuf\u00fcgen eines Targets zu SQL Sentry (Screenshot: IT-Testlab Dr. G\u00fcttich)<\/figcaption><\/figure>\n\n\n\n

Installation<\/strong><\/p>\n\n\n\n

F\u00fcr den Test spielten wir SolarWinds SQL Sentry auf einem Windows Server 2016 ein, der mit einer Microsoft SQL Server 2019 CU5 Standard-Datenbank arbeitete. In Produktivumgebungen empfiehlt der Hersteller, SQL Sentry auf einem anderen Rechner als die Datenbank laufen zu lassen, um die Leistung nicht zu beeinflussen, in unserer Testumgebung spielte dieser Aspekt aber keine Rolle. Zum Testzeitpunkt war Version 2021.18 von SQL Sentry aktuell. Da die Software ohne Agenten auf den Zielsystemen auskommt, reicht es, sie auf einem beliebigen System im Netz einzuspielen. Laut Hersteller ben\u00f6tigt die L\u00f6sung \u00fcbrigens f\u00fcr das Sammeln der Monitoring-Daten etwa zwei bis drei Prozent der Ressourcen des Zielsystems. Je nach Last kann ein SQL-Sentry-Dienst etwa 50 bis 80 Datenbank-Instanzen \u00fcberwachen. In der Praxis l\u00e4uft das so ab, dass die Software die Monitoring-Daten bei den einzelnen Instanzen abfragt und sie in ihre eigene Datenbank \u00fcbertr\u00e4gt. Dort dienen sie dann als Quelle f\u00fcr die Informationen, die im SQL-Sentry-Client angezeigt werden. Die Zahl der Clients ist nicht beschr\u00e4nkt, lizenziert wird das System nach der Zahl der Instanzen.<\/p>\n\n\n\n

Was die Systemanforderungen angeht, so empfiehlt SolarWinds f\u00fcr die Maschine mit dem Monitoring-Service bei einer Installation mit f\u00fcnf Targets mindestens eine CPU mit vier Kernen und 2.0 GHz Taktfrequenz. Au\u00dferdem sollten zw\u00f6lf GByte RAM verf\u00fcgbar sein. F\u00fcr die Datenbank-Maschine gen\u00fcgt ein Prozessor mit vier Kernen und 1,6 GHz Taktfrequenz, abgesehen davon sollte das System \u00fcber acht GByte RAM und zehn GByte Speicherplatz verf\u00fcgen.<\/p>\n\n\n\n

\"\"<\/a>
Die Startseite mit dem Health Score (Screenshot: IT-Testlab Dr. G\u00fcttich)<\/figcaption><\/figure>\n\n\n\n

Als SQL Server f\u00fcr die SQL-Sentry-Datenbank sollte die Version 2014 oder neuer zum Einsatz kommen (in kleineren Umgebungen reicht auch die Express-Version), als Betriebssystem unterst\u00fctzt die Software den Windows Server 2012 oder neuer, sowie Windows 8.1 und Windows 10. \u00dcberwachen kann das Produkt von SolarWinds alle SQL Server von 2012 bis 2019.<\/p>\n\n\n\n

Die eigentliche Installation l\u00e4uft folgenderma\u00dfen ab: Zun\u00e4chst einmal muss der Administrator die Installationsdatei f\u00fcr SQL Sentry von der Webseite des Herstellers herunterladen und diese dann aufrufen. Auf unserem System bem\u00e4ngelte die Setup-Routine, dass die ben\u00f6tigten Komponenten \u201cReport Viewer 2010 Redistributable\u201d und \u201c.NET 4.7.1\u201d nicht vorhanden seien und spielte diese anschlie\u00dfend ein.<\/p>\n\n\n\n

Danach startete ein Wizard, der uns Lizenzinformationen anzeigte und uns fragte, ob wir eine komplette Installation, eine benutzerdefinierte Installation oder lediglich eine Installation des Software-Clients w\u00fcnschten. Wir entschieden uns f\u00fcr den Test f\u00fcr die vollst\u00e4ndige Installation.<\/p>\n\n\n\n

Im n\u00e4chsten Schritt wollte der Assistent wissen, ob wir eine neue Datenbank f\u00fcr SQL Sentry anlegen oder eine Verbindung zu einer existierenden Datenbank herstellen wollten. Hier handelt es sich um die Datenbank f\u00fcr SQL Sentry selbst, nicht um eine sp\u00e4ter zu \u00fcberwachende Datenbankinstanz. Da wir noch keine SQL-Sentry-Datenbank hatten, erzeugten wir zu diesem Zeitpunkt eine neue. Dazu mussten wir den Namen des zu verwendenden SQL Servers und der neuen Datenbank angeben.<\/p>\n\n\n\n

\"\"<\/a>
Markiert der Administrator im Dashboard einen Eintrag, so hebt das System automatisch den gleichen Zeitraum bei den anderen Eintr\u00e4gen hervor (Screenshot: IT-Testlab Dr. G\u00fcttich)<\/figcaption><\/figure>\n\n\n\n

Jetzt konnte es daran gehen, einen Dom\u00e4nen-Account anzugeben, unter dem der Monitoring-Service laufen sollte. Danach kam noch die Definition des Kontos an die Reihe, mit der sich der SQL-Sentry-Portal-Service mit der Datenbank verbindet, anschlie\u00dfend lief die Installation durch.<\/p>\n\n\n\n

Zum Schluss gaben wir noch in der Konfigurations-Utility das Passwort f\u00fcr unser sa-Konto an. Damit war das System einsatzbereit.<\/p>\n\n\n\n\n\n\n\n

Das Einbinden der zu \u00fcberwachenden Datenbank-Instanz<\/strong><\/p>\n\n\n\n

Nach dem Abschluss der Installation aktivierten wir die Software mit den Lizenzinformationen, die uns SolarWinds zur Verf\u00fcgung gestellt hatte, legten ein Benutzerkonto f\u00fcr SQL Sentry fest und konfigurierten den Zugriff auf unseren SMTP-Server, damit das Produkt uns Warnmeldungen und \u00c4hnliches per E-Mail zuschicken konnte. Zum Schluss verwendeten wir den Befehl \u201cAdd target\u201d und gaben den Namen der zu \u00fcberwachenden Datenbank-Instanz an. Daraufhin verband sich die Software mit der Datenbank und wir hatten Zugriff auf die \u00dcberwachungsfunktionen.<\/p>\n\n\n\n

\"\"<\/a>
Ein Quick Report mit einer Analyse der Wait Stats (Screenshot: IT-Testlab Dr. G\u00fcttich)<\/figcaption><\/figure>\n\n\n\n

Der Funktionsumfang von SQL Sentry in der Praxis<\/strong><\/p>\n\n\n\n

Nachdem wir unsere Datenbank hinzugef\u00fcgt hatten, landeten wir auf einem Dashboard, das im Workspace in der Mitte Aufschluss \u00fcber den \u201cHealth Score\u201d der gerade \u00fcberwachten Instanz mit den aktuellen Events gab. Darunter gab es Links zu einem Demo-Video und diversen Webseiten mit Dokumentation, Support, Tipps und Tricks und so weiter.<\/p>\n\n\n\n

Der eben erw\u00e4hnte Health Score kann irgendwo zwischen eins und 100 liegen, je h\u00f6her die Zahl ist, desto besser. Er errechnet sich aus den in der letzten Zeit aufgetretenen Events, gibt einen schnellen \u00dcberblick \u00fcber den Status des Systems und erm\u00f6glicht proaktives Troubleshooting. Daneben finden sich Eintr\u00e4ge, die Aufschluss dar\u00fcber geben, welche Ereignisse als \u201cCritical\u201d, \u201cHigh\u201d, \u201cMedium\u201d oder \u201cLow\u201d eingestuft worden sind. Alternativ existiert auch eine \u00dcbersicht nach Tags wie „Network“, „CPU“ oder auch „Memory“. Klickt man auf einen dieser Eintr\u00e4ge, so blendet die Software eine Liste ein, die die Events der jeweiligen Kategorie umfasst, so dass man sofort erkennt, was passiert.<\/p>\n\n\n\n

Klickt man auf die Kondition, die zu dem Ereignis geh\u00f6rt, so erh\u00e4lt man eine Detail\u00fcbersicht, die die Anwender dar\u00fcber informiert, wann die Kondition auftrat und was der dazugeh\u00f6rige Wert war (beispielsweise ein hoher I\/O-Count). Es steht an gleicher Stelle auch ein kurzer Hilfetext mit einer Erkl\u00e4rung oder ein Link zu einer Knowledge Base zur Verf\u00fcgung.<\/p>\n\n\n\n

\"\"<\/a>
Das Dashboard mit einer Baseline (Screenshot: IT-Testlab Dr. G\u00fcttich)<\/figcaption><\/figure>\n\n\n\n

Struktur der Client-Software<\/strong><\/p>\n\n\n\n

Auf der linken Seite findet sich eine Baumstruktur, \u00fcber die die Anwender unter anderem zu den \u00fcberwachten Instanzen und den Event-Kalendern navigieren k\u00f6nnen. Rechts befindet sich ein Bereich zum Zugriff auf alle Konditionen, also \u201cGeneral Conditions\u201d, \u201cFailsafe Conditions\u201d, \u201cAudit Conditions\u201d und \u201cAdvisory Conditions\u201d. Auf die Konditionen und den Event-Kalender gehen wir sp\u00e4ter noch im Detail ein.<\/p>\n\n\n\n

Die Seitenleisten lassen sich bei Bedarf ausblenden, um den Arbeitsbereich zu vergr\u00f6\u00dfern. Dar\u00fcber hinaus kann man sie bewegen, andocken und ihre Gr\u00f6\u00dfe ver\u00e4ndern.<\/p>\n\n\n\n

Performance-Analysen in einem Dashboard<\/strong><\/p>\n\n\n\n

Wechselt man auf der linken Seite nach \u201cAll Targets \/ Default Site \/ {Name des Datenbank-Servers}\u201d, so kann man dort auf die Performance-Analyse des betroffenen System zugreifen. Das hier angezeigte Dashboard (das wir in der Einleitung bereits kurz angesprochen hatten) bietet in grafischer Form Aufschluss \u00fcber die wesentlichsten Leistungsparameter des Systems und wird standardm\u00e4\u00dfig alle zehn Sekunden aktualisiert. Dazu geh\u00f6ren der Netzwerkverkehr, die Prozessorlast, die Speicherauslastung und der Disk I\/O auf Server-Ebene sowie die Aktivit\u00e4t des SQL Servers, die SQL Server Waits, die Speichernutzung des SQL Servers und der Datenbank I\/O. Die genannten Werte umfassen also \u2013 wie gesagt – sowohl Leistungsdaten des Servers als auch des Datenbanksystems, die zust\u00e4ndigen Mitarbeiter k\u00f6nnen hier also auch sehen, wenn irgendwelche anderen Dienste dem SQL Server Kapazit\u00e4ten wegnehmen.<\/p>\n\n\n\n

\"\"<\/a>
Ein Plan Diagramm (Screenshot: IT-Testlab Dr. G\u00fcttich)<\/figcaption><\/figure>\n\n\n\n

Man kann die Start\u2013 und Enddaten der Performance-Analyse jederzeit \u00e4ndern und so die L\u00e4nge des Zeitraums und den Zeitpunkt genau bestimmen. Abgesehen davon sind die IT-Verantwortlichen jederzeit dazu in der Lage, in diese grafischen Darstellungen hineinzuzoomen und bestimmte Bereiche zu markieren. Stellen sie zum Beispiel fest, dass zu einem bestimmten Zeitraum die Zahl der SQL Server Waits besonders hoch war und markieren diesen Zeitraum, so hebt das System den gleichen Zeitraum auch in allen anderen Graphen hervor. Auf diese Art und Weise k\u00f6nnen die Verantwortlichen sofort sehen, ob es zur gleichen Zeit besonders viele SQL Server Writes oder eine hohe CPU-Last gab.<\/p>\n\n\n\n

Abgesehen davon gibt es auch die M\u00f6glichkeit, eine Baseline \u00fcber die aktuellen Messwerte zu legen. Aktiviert ein Administrator beispielsweise die Baseline des vorherigen Tages oder der vorherigen Woche, so kann er anhand der eingeblendeten Linie sehen, wie sich das System im Durchschnitt w\u00e4hrend des gew\u00e4hlten Zeitpunkts verhalten hat (beispielsweise k\u00f6nnte die CPU-Last durchschnittlich bei 28 Prozent gelegen haben) und so Unterschiede zum aktuellen Zustand sichtbar machen. Bei Bedarf lassen sich jederzeit auch eigene Baselines definieren.<\/p>\n\n\n\n

Dar\u00fcber hinaus besteht unter anderem auch die Option, zu den Prozessen, dem Event-Kalender, dem Disk-Space oder auch den Indexen zu springen oder einen \u201cQuick Report\u201d zu den Server Writes zu erzeugen. Auf diese Art und Weise lassen sich schnell Informationen sammeln und Zusammenh\u00e4nge herstellen, zum Beispiel, dass eine Festplatte des Servers zu dem genannten Zeitpunkt \u00fcberlastet war und deshalb die Datenbank ausbremste. Das ganze System ist also extrem m\u00e4chtig.<\/p>\n\n\n\n

Weitergehende Informationen sammeln<\/strong><\/p>\n\n\n\n

Es gibt aber noch weitere M\u00f6glichkeiten, tiefer in das System einzusteigen. Wechselt man innerhalb des gew\u00e4hlten Zeitraums nach \u201cTop SQL\u201d, so hat man die Option, mehrere verschiedene Informationen einzusehen. Dazu geh\u00f6ren die \u201cRunning Queries\u201d, die \u201cCompleted Queries\u201d, die \u201cProcedure Stats\u201d und die \u201cQuery Stats\u201d. M\u00f6chte man sich beispielsweise ansehen, was genau in der Vergangenheit passiert ist, so ruft man die \u201cCompleted Queries\u201d auf. Dann erscheint eine Liste mit allen Datenbankabfragen. Diese Liste gibt Aufschluss \u00fcber die Anwendung, die betroffene Datenbank, den Host, die Dauer, die CPU-Last und vieles mehr. Zusammengeh\u00f6rende Abfragen lassen sich bei Bedarf auch zusammenfassen, so dass man erkennen kann, welche Workloads entstanden sind. So machen die zust\u00e4ndigen Mitarbeiter beispielsweise sichtbar, dass bestimmte Abfragen eines Online-Shops eine besonders hohe Zahl an I\/O-Vorg\u00e4ngen verursacht haben.<\/p>\n\n\n\n

\"\"<\/a>
Die Disk Space-Analyse (Screenshot: IT-Testlab Dr. G\u00fcttich)<\/figcaption><\/figure>\n\n\n\n

Unterhalb der Liste mit den Abfragen kann man – nach der Auswahl einer Abfrage – sehen, welche Statements die jeweilige Abfrage enthalten hat, wie lange die Abarbeitung der einzelnen Statements gedauert hat, welche Prozessorlast dabei anfiel und \u00c4hnliches. Es gibt also die M\u00f6glichkeit, genau herauszufinden, welche Statements welchen Einfluss auf die Datenbankleistung haben.<\/p>\n\n\n\n

Unter den Statements befindet sich noch eine grafisch gestaltete \u201cQuery History\u201d. Diese zeigt, wann das betroffene Code-St\u00fcck ausgef\u00fchrt wurde und wie lang der Vorgang gedauert hat. Alternativ gibt es auch die Option, sich die durch den Code verursachte Prozessorlast oder die Reads und Writes anzeigen zu lassen. Damit k\u00f6nnen die zust\u00e4ndigen Mitarbeiter sehen, wie sich der Code normalerweise verh\u00e4lt und herausfinden, warum Probleme entstehen.<\/p>\n\n\n\n

Arbeit mit dem Plan Explorer<\/strong><\/p>\n\n\n\n

Ebenfalls von Interesse: der Plan Explorer. In der Liste der Statements befindet sich ein Button namens \u201cOpen\u201d. Klickt man darauf, oder auf den Eintrag \u201cPlan Diagram\u201d, so \u00f6ffnet sich ein Fenster, das neben dem Statement auch ein Plandiagramm des Ablaufs enth\u00e4lt. In diesem Diagramm werden die Operatoren hervorgehoben, die am meisten Ressourcen verbrauchen. An gleicher Stelle finden sich noch viele weitere Informationen, die Aufschluss \u00fcber die in der Datenbank ablaufenden Aktionen liefern. Eine \u201cPlan History\u201d hilft in der Praxis beim Optimieren der Statements, da sie die einzelnen Abl\u00e4ufe vorh\u00e4lt und zeigt, welche Auswirkungen vorgenommen \u00c4nderungen haben.<\/p>\n\n\n\n\n\n\n\n

Die Index\u00fcbersicht und weitere Funktionen<\/strong><\/p>\n\n\n\n

Was die Indizes angeht, so verf\u00fcgt SQL Sentry \u00fcber die bereits erw\u00e4hnte Index\u00fcbersicht, die am oberen Rand Aufschluss \u00fcber die Fragmentierung, die Buffer-Nutzung und den auf den Festplatten genutzten Speicher gibt. Darunter findet sich eine Liste der vorhandenen Indizes. W\u00e4hlt man aus dieser Liste einen aus, so erscheinen im unteren Bereich Informationen, die sich auf diesen ausgew\u00e4hlten Index beziehen, n\u00e4mlich die Fragmentierung, der benutzte Disk-Speicherplatz und die Aktivit\u00e4t (also User-Scans, die den Index verwenden).<\/p>\n\n\n\n

Auf \u00e4hnliche Art und Weise k\u00f6nnen sich die Anwender \u00fcber den genutzten Disk-Space informieren. In dem entsprechenden Reiter finden sich nicht nur Informationen \u00fcber den freien Speicher, sondern auch Daten zum letzten Backup und vieles mehr.<\/p>\n\n\n\n

\"\"<\/a>
Ein Blick in den Event-Kalender (Screenshot: IT-Testlab Dr. G\u00fcttich)<\/figcaption><\/figure>\n\n\n\n

Weitere Reiter befassen sich mit „Blocking SQL“ und „Deadlocks“. Interessanter ist die QuickTrace-Funktion. Ein QuickTrace stellt einen umfassenden Aktivit\u00e4ts-Snapshot dar, der sich aus Trace-Events und Prozess-Level-Daten zusammensetzt, die w\u00e4hren eines kurzen Zeitraums gesammelt wurden. Dabei f\u00fchrt SQL Sentry verschiedene Messwerte zusammen, wie I\/O, Cache Misses, CPU und so weiter. Das Ergebnis ist eine klare \u00dcbersicht \u00fcber die Prozesse, Hosts, Anwendungen und Benutzer, die f\u00fcr die Aktivit\u00e4ten w\u00e4hrend der Datensammlung verantwortlich waren.<\/p>\n\n\n\n

Der Event-Kalender stellt schlie\u00dflich eine zentrale Ressource zum Log-Management dar. Er stellt die Ereignisse, die auf den \u00fcberwachten SQL-Server-Instanzen stattgefunden haben, grafisch dar und hilft beim Automatisieren von Workflows, um proaktiv die Leistung zu verbessern. Die Events werden in einer Outlook-\u00e4hnlichen Oberfl\u00e4che angezeigt, in der man die dazugeh\u00f6rigen Daten einsehen kann.<\/p>\n\n\n\n

Der Aufbau des Event-Kalenders<\/strong><\/p>\n\n\n\n

Der Event-Kalender liefert nicht nur eine \u00dcbersicht \u00fcber alle Events, die auf dem Server ablaufen, sondern gibt zudem Aufschluss \u00fcber die Runs, die simultan ablaufen. Die Anwender sehen hier beispielsweise, ob die Server mit zu vielen Jobs belastet werden. Dabei hebt das System die einzelnen Eintr\u00e4ge mit Farben hervor. Ein blauer Balken bezieht sich auf die Runtime, bei historischen Eintr\u00e4gen zeigen sie die echte Runtime, bei zuk\u00fcnftigen die durchschnittliche. Direkt daneben befindet sich noch ein zweiter Farbbalken, der Aufschluss \u00fcber die Advisory-Konditionen gibt, rot f\u00fcr fehlerhaft und gr\u00fcn f\u00fcr erfolgreich. Auf diese Weise wird auf einen Blick klar, was wie lang gedauert hat und welche Ergebnisse zustande kamen.<\/p>\n\n\n\n

F\u00fchrt man einen Klick auf einen solchen Event aus, so erscheint ein Fenster mit weiteren Hintergrundinformationen, wie Name, Typ, Benutzer, Queue Settings und so weiter. Es steht nach einem Rechtsklick auch ein passendes Men\u00fc zu jedem Event zur Verf\u00fcgung, \u00fcber das man unter anderem Jobs startet und stoppet sowie die Option hat, Runtime Stats einzusehen. Man kann die Events auch filtern, die Ansicht anpassen, Jobs per Drag-and-Drop planen und so weiter, der Event-Kalender ist also extrem leistungsf\u00e4hig. Es gibt sogar die M\u00f6glichkeit, eigene Ansichten f\u00fcr die Kalender zu erzeugen, so dass es beispielsweise Kalender gibt, die nur Failed Jobs oder Backups anzeigen.<\/p>\n\n\n\n

Der Einsatz der Alarmfunktion<\/strong><\/p>\n\n\n\n

Es lassen sich auf jeder Server-Hierachie Alarme anlegen. Von der ganzen Infrastruktur \u00fcber Server-Gruppen bis hin zu einzelnen Jobs. Es gibt vier Arten von Alarmen, die durch die bereits angesprochenen Konditionen ausgel\u00f6st werden. \u201cGeneral Conditions\u201d beziehen sich auf Dinge wie langsame Jobs, Fehler, Deadlocks, Blocks und so weiter. \u201cFailsafe Conditions\u201d decken Cluster Failover und ausfallende SQL Server ab. Diese Alarme werden nicht aktiv, wenn ein Wartungsfenster auf dem betroffenen Server aktiv ist. \u201cAudit Conditions\u201d wiederum thematisieren \u00c4nderungen innerhalb von SQL Sentry selbst. Nimmt ein Mitarbeiter zum Beispiel eine Konfigurations\u00e4nderung vor, so kann man das System so einrichten, dass der Administrator einen Mail-Alert dazu erh\u00e4lt. Es sind aber auch andere Aktionen m\u00f6glich, wie zum Beispiel das Ausf\u00fchren von Jobs, Powershell-Skripts und SQL-Abfragen sowie das Senden von SNMP-Traps.<\/p>\n\n\n\n

Am interessantesten sind in diesem Zusammenhang sicher die \u201cAdvisory Conditions\u201d. Mit ihnen legen die zust\u00e4ndigen Mitarbeiter Konditionen an, die sich genau auf die jeweilige Umgebung und die darin unterst\u00fctzten Applikationen beziehen. Diese k\u00f6nnen die Ergebnisse von T-SQL-Queries, WMI-Abfragen, Performance-Counter-Werten oder beliebige Kombinationen daraus enthalten. Bei den Performance-Countern hat das System auf alle Counter Zugriff, die auf dem betroffenen Server existieren.<\/p>\n\n\n\n

\"\"<\/a>
Die Liste der Advisory-Conditions den Erkl\u00e4rungen unten rechts (Screenshot: IT-Testlab Dr. G\u00fcttich)<\/figcaption><\/figure>\n\n\n\n

Es geh\u00f6ren bereits 85 Advisory Conditions (wie beispielsweise „High Active User Sessions“, „Log File Growth“ oder „Network Bottleneck \u2013 Outbound“) zum Lieferumfang von SQL Sentry, die Anwender haben aber jederzeit Gelegenheit, eigene anzulegen. Wechselt der Administrator auf die Liste der vorhandenen Advisory Conditions und w\u00e4hlt eine Kondition aus, so zeigt ihm das System unten die dazugeh\u00f6rige Query und unten rechts eine Erkl\u00e4rung, die ihn dar\u00fcber informiert, was die Kondition genau macht. Bei manchen Eintr\u00e4gen finden sich in dieser Erkl\u00e4rung auch Links zu dazugeh\u00f6rigen Blog-Eintr\u00e4gen. Die Thresholds, die bei den vordefinierten Advisory Conditions gesetzt wurden, basieren \u00fcbrigens auf den Empfehlungen von Microsoft.<\/p>\n\n\n\n

Die ganze Alert-Funktionalit\u00e4t ist sehr m\u00e4chtig und erm\u00f6glicht sowohl einfache Alarme, die zum Beispiel bei hoher CPU-Last einen SNMP-Trap ausl\u00f6sen oder eine Mail schicken, als auch Alarme, die aktiv werden, wenn eine gesch\u00e4ftskritische Abfrage l\u00e4nger als den festgelegten Zeitraum in Anspruch nimmt. Es ist allerdings auch m\u00f6glich, viel kompliziertere Alarme zu erzeugen, die zum Beispiel nur dann aktiv werden, wenn das SQL Blocking w\u00e4hrend der Arbeitszeit dreimal pro Stunde l\u00e4nger als eine Minute gedauert hat.<\/p>\n\n\n\n

Browser-Version von SQL Sentry<\/strong><\/p>\n\n\n\n

Um SQL Sentry zu nutzen, m\u00fcssen die IT-Verantwortlichen \u00fcbrigens nicht zwingend die Client-Software installieren. Es existiert auch eine Web-Version der Anwendung mit einem anpassbaren Dashboard. Diese kann zum Einsatz kommen, um das System zu \u00fcberwachen. Die verf\u00fcgt momentan noch nicht \u00fcber alle Konfigurationsoptionen, wird aber st\u00e4ndig verbessert.<\/p>\n\n\n\n

\"\"<\/a>
Das Dashboard im Web-Interface (Screenshot: IT-Testlab Dr. G\u00fcttich)<\/figcaption><\/figure>\n\n\n\n

Fazit

<\/strong>SQL Sentry hilft Datenbankadministratoren dabei, schnell die Informationen zu erhalten, die ihnen dabei helfen, Leistungsprobleme ihrer Datenbanken zu beseitigen. Sie m\u00fcssen mit dem Tool keine wertvolle Arbeitszeit verschwenden, um an den falschen Stellen nach Antworten zu suchen. Die L\u00f6sung liefert im Betrieb alle relevanten Informationen f\u00fcr die Probleml\u00f6sung. Aufgrund des gro\u00dfen Leistungsumfangs ist allerdings eine gewisse Einarbeitungszeit erforderlich, um das Produkt in vollem Umfang nutzen zu k\u00f6nnen.<\/p>\n\n\n\n

Dieser Beitrag ist auch als PDF verf\u00fcgbar:<\/p>\n\n\n\n