Kaum zu glauben – es ist schon ein Jahr her, dass ich etwas über Datenbanken geschrieben habe:
https://thwack.solarwinds.com/groups/thwack-emea/blog/2016/11/30/immer-diese-datenbanken

Vor ein paar Monaten bin ich auf den SAM eingegangen und heute bekommt der DPA seinen grossen Auftritt.

 

DPA misst die Zeit die ein Query innerhalb der Datenbank verbringt und zeigt, wo die meiste Zeit aufgebracht wird. Das funktioniert ohne Agent und ohne Änderungen an der Datenbank.
Die Software ist getrennt von Orion, integriert sich aber gerne in eine bestehende Umgebung.
Fangen wir bei Null an. Wobei, ich schreibe das gerade aus unserem Buero in London und hier ist es furchtbar kalt, fast schon unter Null!

 

Die Installation ist denkbar einfach:

 

Ein paar Mal auf Next und 90 Sekunden später ist die Sache erledigt. Das folgende Fenster erscheint:

 

Also weiter geht es im Browser eurer Wahl.

Zuerst wird das Repository angelegt. Das ist die DB in der DPA sein eigenes Zeugs ablegt.

 

Kompatibel sind die folgenden Systeme:

 

In den meisten Fällen wird eine SQLExpress vollkommen ausreichen. Es gibt nur eine Regel:
Nehmt nicht die DB die ihr überwachen wollt, da sonst die Ergebnisse nicht realistisch sind.

Ich nehme eine kleine DB die auf meinem Orion Server liegt. Nicht wirklich empfehlenswert aber ich bin ja auch nicht produktiv!

 

Ich lasse mit dem SA Konto einen Benutzer anlegen:

 

Das Erstellen des Repository dauert nur wenige Sekunden und wir klicken auf „Register“.

Jetzt wird die DB eingehängt die wir tatsächlich überwachen wollen.

 

Ich entscheide mich für meine SQL

 

Keine Sorge wegen des SA Kontos hier. Das dient nur zum Erstellen des Benutzers im nächsten Schritt:

 

Mehr zu den erforderlichen Berechtigungen beim SQL hier:

https://support.solarwinds.com/Success_Center/Database_Performance_Analyzer_(DPA)/SQL_Server_permissions_for_DPA_monitoring

Und für Oracle:

https://support.solarwinds.com/Success_Center/Database_Performance_Analyzer_(DPA)/Oracle_permissions_for_DPA_monitoring

 

Alles erledigt! Ein nahezu leeres Dashboard begrüßt euch, aber Daten kommen nun hinein:

 

Weil ich aber nicht Tage warten möchte wechsle ich auf ein schon bestehendes System:

 

Schaut mal auf das Element rechts. Eigentlich wollen wir ja immer, dass Trends nach oben gehen. Hier nicht!

Es ist Wartezeit und die soll gefälligst sinken. Also schalte ich auf „trending down“

 

Was heisst das jetzt? Nichts Gutes! Die Wartezeit ging leider hoch.

 

Schauen wir einmal warum.

Unten ist meine SQL Instanz und wir sehen schon, dass irgendwo ein Problem mit einem Query vorliegt:

 

Ich klicke auf die Instanz.

Das erste was ich sehe ist die Gesamtwartezeit innerhalb der letzten 30 Tage

 

Ich sehe auch direkt, dass meine Baseline bei etwa 22 Minuten am Tag liegt, irgendetwas muss am 08.11. passiert sein, und die Wartezeit wird hauptsächlich durch ein einziges Query erzeugt.

Ich bin jetzt echt interessiert am 08.11. Was war da los? Eine kurze Googlesuche sagt mit, dass Gordon Ramsey am 08.11. geboren wurde, aber 1966 und nicht 2017. Das kann es also nicht sein.

 

Nagut, dann klicken wir mal auf den Tag.

 

50 Sekunden Wartezeit pro Stunde mit der Ausnahme von den zwei Stunden zwischen 0800-100. Es wird immer unheimlicher. Es kann nur ein SQL-Poltergeist sein.

Ich klicke auf 0800. Nur ein Query hat hier wirklich etwas getan. Wir sehen auch schon anhand der Farbe und der Legende rechts, wofür in etwa die Zeit aufgebraucht wurde

 

Ich bin mal mutig und klicke auf das Query.

 

Wir sehen oben 482 Ausführungen innerhalb der Stunde und es war eine reine lesende Abfrage.

Ich kann dem Query oben einen Namen geben „name SQL“, rechts habe ich zwei Knöpfe für weitere Informationen mit historischen Daten und zusätzlichen Statistiken.

 

In meinem Fall steht hier nicht sehr viel – aber das ist auch klar. Ist ein neues Query verursacht von einem Report, den es vorher noch nicht gab.
Wenn ich nur wüsste, was ich da versucht habe!

 

Was auch immer. Wo wir gerade hier sind, schauen wir einmal nach oben.

 

Ich kann hier vom Query zurück navigieren auf den ganzen Tag.

Dort angekommen kann ich hier die Stunde erneut auswählen:

 

Aber jetzt passt mal auf.

Links ist ein Button für „Timeslice“ und nach Klicken dort kann ich einen granularen Intervall einstellen:

 

Unten sehe ich dann die Stunde unterteilt in 10 Minuten:

 

Klickt mal auf einen Block. Dann wieder auf Intervall:

 

Jetzt kann ich mir das ziemlich genau anschauen. Schade, dass das so versteckt ist!

 

 

Wenn ich aber nicht gezielt nach einem Problem suche, sondern einfach nur mal schauen möchte was mein SQL gerade so macht (und warum er gefühlt eine Million GB Ram braucht), nutze ich die Navigation oben und gehe zurück auf den ganzen Tag:

 

Jetzt klicke ich auf einen der anderen Buttons – wie wäre es mit dem hier:

 

 

Rechts sehe ich gut aufgelöst die Programme/DLL die auf die DB zugreifen:

 

Klickt bei der Gelegenheit klickt einfach mal auf die anderen Knöpfchen. Bei einer Produktivumgebung ist der Punkt DB User meist recht interessant – da sieht man vielleicht sogar, wer wirklich arbeitet

Scrollt mal etwas herunter da sind vier weitere Reiter. Nein, nicht die apokalyptischen. Okay der letzte vielleicht:

 

Klickt wieder etwas herum.
Wenn bei euch, so wie bei mir, gerade keine Deadlocks sind guckt einfach hier nach weiteren Details:

https://support.solarwinds.com/Success_Center/Database_Performance_Analyzer_(DPA)/Deadlock_analysis_in_DPA

 

Oben sind noch mehr Knöpfe. Es kann nie genug Knöpfe geben.

 

Wenn man auf Resources klickt gibt es ein paar Standardkennzahlen, die mit dem Umweg SQL über WMI aus der Maschine herausgezogen werden. Die Elemente hier sind selbsterklärend und ich verliere nicht viel Worte. Schaut euch um.

 

Aber nicht zu viel! Es gibt noch mehr zu sehen!

Ziemlich weit oben ist ein Knopf bei mir der bei euch vielleicht noch nicht ist:

 

Beim DPA gibt es ein optionales Paket mit dem Namen „VM Option“, das getrennt lizensiert werden muss. Ich kann mir hier mein vCenter oder meinen ESX direkt einpflegen.

Dazu gehe ich zuerst in die Options und dann „Register…“

 

Es werden readonly Berechtigungen benötigt daher es sollte kein Problem sein, diese von eurem freundlichen VM Admin zu bekommen.
Das vCenter wird scanned und nach einigen Sekunden sollte in der Übersicht der Instanzen rechts ein kleines Icon erscheinen:

 

Wenn ich jetzt also ganz oben auf Virtualization drücke sehe ich zuerst unten in der Übersicht etwas andere Info

 

Spannend wird es jetzt, wenn ich auf die Instanz klicke und alles etwas anders aussieht:

 

Wenn ich auf einen der Pfeile klicke erscheint ein Popup:

 

Ich sehe nun also Events aus der virtuellen Umgebung. Das ist stellenweise mehr als nur nett, weil es mir Dinge erklären kann die ohne diese Informationen so viel Sinn ergeben wie Grünkohl.

Ganz oben der Reiter VM Config:

 

Darunter mehr Knöpfe:

 

Wir sehen mit welchem Host wird es zu tun haben, welche anderen VMs dort sind und wie diese priorisiert sind.
Dazu fällt mir eine Anekdote ein – ich hatte irgendwann mal eine DPA Demonstration mit einem IT Manager der an dieser Stelle sagte „Das sind Informationen die ich meinem DBA niemals geben würde. Danach kündigt der mir noch!“

 

Wir sind fast durch. Folgt ihr mir noch? – Gut!

Ganz oben haben wir noch Buttons:

 

Bisher waren wir auf HOME, klicken wir kurz auf REPORTS

Nach Auswahl der Instanz gibt es ein paar vordefinierte Berichte

 

Unter Report Options kann ich das Ding noch etwas anpassen, unter anderem mit meinen eigenen Statements:

 

 

Das gleiche bei den ALERTS. Hier erlaubt mir „custom“ meine eigenen Statements:

 

Aber ihr seht schon, Berichte und Alarme sind hier eher rudimentär wenn man es mit Orion vergleicht.

Bei den OPTIONS finden wir Grundeinstellungen, können SMTP und AD zufügen sowie andere administrative Aufgaben erledigen.

 

Unter THWACK findet sich wieder etwas Interessantes:

 

Das bringt euch zu benutzerdefinierten Berichten. Diese laufen nicht innerhalb von DPA!
Die Berichte dort werden gegen das Repository gesetzt um spezielle Informationen herauszuziehen. Dazu nutzen wir dann das Management Studio.

 

Jetzt klicken wir auf LOGOUT und verlassen DPA und gehen zu Orion.

Dort unter Settings --> Product specific Settings finden wir Database Performance Analyzer

 

Nach dem Verknüpfen werden automatisch Abhängigkeiten gesucht für den Fall, dass ich Anwendungen überwache die auf meine DB zugreifen.
Das Resultat sieht dann so aus:

 

DPA bringt also seine Informationen in die Orion Plattform. Das ist interessant auf mehreren Ebenen, z.B. im Zusammenspielt mit AppInsight, aber natürlich auch dem Appstack

 

 

Noch recht neu ist die Integration in den Perfstack

 

Das ist schon heiss, oder nicht?
Hier in London ist es immer noch kalt aber das Problem beseitige ich jetzt mit einem Kaffee!