Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

SQL Server: Performance-Optimierung

Statistiken über Indizes abfragen und ermitteln, welche Indizes (möglicherweise) fehlen

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
DMVs (Database Managements Views) geben Auskunft, welcher Index wie oft verwendet wird und welcher Index eventuell fehlen könnte.
10:46

Transkript

Als erstes zeige ich Ihnen, wie Sie herausfinden können welchen Index der SQL Server wie oft wann das letzte Mal benutzt hat und welche Indizes er meint, dass sie fehlen könnten an der Stelle. Die erste Frage: “Wie oft wird welcher Index verwendet?” beantwortet eine Abfrage auf sys.dm_db_index_usage_stats und da habe ich verschiedene Spalten, die mir sagen, wann der Index benutzt wurde, wie der Index benutzt wurde, wurde ein Seek gemacht, d.h. eine Suche durchgeführt, oder wurde ein Scan gemacht, d.h. der ganze Index wurde durchlaufen, oder wurde ein Lookup durchgeführt, was in der Regel auf Joins hinweist an der Stelle. Und ich kann mir damit relativ leicht erklären, welcher Index wirklich am nützlichsten für mich ist, also wer am häufigsten in der Datenbank tatsächlich benutzt wird, bzw. genauer gesagt in einer Tabelle benutzt wird, und damit habe ich so eine gewisse Möglichkeit auch zu sehen, ob ich Indizes habe, die vielleicht gar nicht oder sehr selten benutzt werden, und dann muss ich abwägen, ob es sinnvoll ist, die überhaupt in der Datenbank zu haben. Dann gibt es eine Abfrage auf sys.dm_db_missing_index_details. Das bedeutet der SQL Server sagt mir, von welchen Indizes er ausgeht, dass sie fehlen würden. Aber Obacht, das kann sehr schnell in die falsche Richtung gehen, weil schlicht und ergreifend bedeutet das ja nur, dass der SQL Server eine Abfrage ausgeführt hat. Eine Abfrage, die gar nicht typisch sein muss. Der SQL Server hat keinen Blick dafür, ob die Abfragen, die er in der letzten Zeit gesehen hat, ob die typisch sind, ob die häufig auftreten, oder ob die nur für einen Monats-, Quartals- oder sogar Jahresabschluss sind. Und dann kann es natürlich sein, dass der SQL Server für solche untypischen Abfragen, natürlich Indizes vorschlägt, die durchaus auch Sinn machen in diesem Kontext, aber da die Abfrage nicht wirklich häufig verwendet wird, und der Index demnach einfach nur Platz wegnehmen würde und relativ selten in Gebrauch wäre, muss man das wirklich sehr stark abwägen. Es gibt viele Stellen wo der SQL Server solche Ratschläge gibt, also Sie können das z.B. im Ausführungsplan oder es gibt auch den Tuning Advisor, den ich Ihnen später vorstelle, der gibt Ihnen Hinweise entsprechend welche Indizes fehlen, aber natürlich immer nur mit denen Daten, mit denen er arbeiten kann, d.h. die Abfragen, die er gesehen hat, wo er sagt: “Ok, wenn diese Abfrage wirklich regelmäßig kommt, dann macht es Sinn, diesen Index anzulegen. Ansonsten Finger weg!” Das heißt, mein guter Rat, nicht einfach die Abfrage ausfüllen, denken sich, oh, klasse, ich könnte jetzt hingehen und hier einen Index anlegen, das kann darauf hinauslaufen, dass Sie hinterher wirklich ein Dutzend Indizes haben, die größtenteils gar nicht verwendet werden, die vielleicht in der einen oder anderen Situation mal wirklich herangezogen werden, aber im Großen und Ganzen doch dann eher nutzlos quasi in der digitalen Ecke stehen. So, ich habe jetzt erst einmal beide Scripts geöffnet, also das erste, das mir sagt, welche Indizes wie oft benutzt wurden. Der Kern ist hier, wie auch hier früher schon zu sehen gewesen ist, dm_db_index_usage_stats. Wenn ich das laufen lasse, das laufen lasse, dann sehe ich diese Rückgabe. Hier einmal die Tabelle, das Schema der Tabelle, den Name des Index. Teilweise sehen Sie, es gibt Indizes, die keine expliziten Namen haben. Dann kann ich, wenn ich weiter nach rechts scrolle, sehen, wann der letzte User Scan, Lookup oder Seek durchgeführt wurde. Und entsprechend hier, wie oft das in Summe geschehen ist. Und zwar das bedeutet quasi in der Zeit, seitdem der SQL Server das letzte Mal gestartet wurde an der Stelle. So, wenn ich weiter nach rechts scrolle, sehe ich das Ganze nochmal für Systemzugriffe. Interessant sind aber die für den User, das bedeutet wenn ich z.B. hier mal ein bisschen reinschaue, die ersten drei Zeilen sind für Indizes, die offensichtlich nie benutzt wurden. Und ich könnte z.B. einfach mal schauen, auf welche Tabellen das geht. Zum Beispiel: auf den ClusteredColumnstore Index. Könnte eine Abfrage machen: SELECT TOP 10 * FROM, ich fülle das einfach mal aus. Liefert mir etwas zurück, das ist schon mal gut. Da ist also was drin. Dann kann ich hingehen, das tab hier nochmal laufen lassen. Und Sie sehen, aus der Null ist eine Eins geworden, d.h. ich habe einmal in der Tat wirklich einen Scan durchgeführt, d.h. ich bin hier einfach nur durch den Index durchgegangen für die ersten 10 Zeilen quasi. Dann sehe ich entsprechend wann der Zugriff war. Wenn ich das Ganze nochmal machen würde, bekäme ich entsprechend eine Zwei und hätte an der Stelle dann auch einen etwas aktuelleren Zeitstempel dann. Machen wir das doch gleich mal. Hier haben wir die Zwei und entsprechend hier den neuen Zeitstempel. Dann könnte ich natürlich hingehen und sagen, ok, ich möchte eine Suche durchführen. Mal gucken, ob er auch meinen Index benutzt an der Stelle. So, lasse das mal laufen. Geh da nochmal in meine Abfrage. Sie sehen, offensichtlich nicht. Er benutzt nach wie vor einfach einen Scan. Jetzt machen wir nochmal eine andere Art von Abfrage. So, wir haben jetzt Zeilen von 1 bis 10 Millionen, also sollte das, sofern ich mich nicht vertan habe, auch ein richtig gültiger ID Wert sein. Sie sehen, auch das funktioniert nicht. D.h. ich kann den SQL Server nicht so ohne weiteres zwingen in der Tat das zu benutzen. Ich gehe mal auf einen anderen Index. Da wird es ein bisschen leichter sein. Und zwar auf die Tabelle Produktverzeichnis Clustered Info. Kann ich zumindestens auch erstmal eine Abfrage machen. Naja, dann tue ich das mit TOP, war eine gute Idee und schreibe das so rein. Jetzt kann ich das einmal laufen lassen. Dann lasse ich noch einmal unsere Abfrage laufen. Und Sie sehen es, habe ich entsprechend genau auch hier einen Eintrag. Wird es endlich, sogar in beiden Fällen, weil letztendlich auch ein und dasselbe Objekt abgefragt wurde, sprich der Klassenindex, der natürlich auch immer dann verwendet wird, wenn ich beispielsweise überhaupt nur auf die Daten zugreife, also durch das Sternchen, in sofern gehe ich jetzt mal in die Tabelle, in die Definitionen. So, dann kann ich nochmal kurz einen Blick reinwerfen. Es sind die Spalten EAN und Bezeichnung die verwendet werden. So, dann kann ich nochmal kurz Es sind die Spalten EAN und Bezeichnung die verwendet werden. Also, könnte ich mal versuchen: WHERE EAN LIKE 23%. Na gut, die established hier oben natürlich nicht die andere. In der Tat, das erhöht beides natürlich wieder. Möchte ich nicht, also kann ich z.B. hingehen und sagen ich möchte nur den EAN Code haben, aber nicht alle Spalten. Und wenn ich jetzt genau hingucke, sehen Sie, dass die Indizes jetzt hier mehrfach vorhanden sind. Das liegt ein bisschen an der Art der Abfrage. Nichtsdestotrotz interessieren mich aber z.B. hier die Zeile wo ich sehe, dass auch hier ein Seek durchgeführt wurde. Also Sie sehen hier, das ist das Ergebnis von meinem Seek gerade mit dem gleichen Zeitstempel. D.h., wenn ich diese Abfrage durchgehe, kann ich sehr schnell feststellen, ob es möglicherweise Indizes gibt, die kaum oder gar nicht verwendet werden. Das muss ich natürlich in Relation sehen. Wenn ich eine Datenbank wie diese habe, wo kaum Zugriffe stattfinden, dann ist das natürlich ein bisschen schwieriger um zu sagen, ok, ich habe jetzt hier nur 100 Zugriffe, aber letztendlich kann das natürlich sehr viel sein. Das muss man nur ein bisschen in Relation setzten, wobei natürlich eine Anzahl von, naja, wenigen Dutzend im Normalfall eigentlich schon ein recht schlechtes Ergebnis sind. Die zweite Abfrage teilt mir mittels sys.dm_db_missing_index_group_stats mit, welche Indizes möglicherweise der Performance gut tun würden. Ich führe das einfach mal aus. Und Sie sehen, er gibt mir an, in welchen Tabellen über welche Spalten, das ist hier equality_columns und inequality_columns, entsprechend er denn gerne einen Index hätte. Er sagt mir gleichzeitig, wie oft er davon profitiert hätte und wann das letzte Mal. D.h. hier kann ich ein bisschen abschätzen, wie oft benutzt er das überhaupt. Wenn das eine Mal zumindest 1171 Zugriffe via Seek waren, das ist natürlich schon mal durchaus eine gewisse Anzahl, bedeutet das hier, dass der Index hier unten nur einmal verwendet worden wäre. Das ist meine Abfrage von gerade übrigens. Letztendlich kann ich mich auch ein bisschen verlocken lassen, wenn ich weiter nach rechts scrolle, sehen Sie in der letzten Spalte, wieviel Performance Zuwachs in der Tat stattfinden würde, würde ich diesen Index anlegen. Allerdings berücksichtigt es natürlich nicht den Aufwand, den ich habe, um den Index aktuell zu halten. Also immer wenn Daten geändert werden, muss ja auch der Index geändert werden. Und es ist da durchaus sehr legitim zu sagen, wie oft wird der Index verwendet? Das kann ich nicht unbedingt in absoluten Zahlen sehen. Ich muss das ungefähr so ein bisschen mit der Verwendungshäufigkeit meiner Anwendung, respektive meiner Datenbank ein bisschen abgleichen. Da kann natürlich 1171 relativ wenig sein. Fakt ist aber, dass eins mit Sicherheit auf jeden Fall relativ wenig ist. Und ich kann das mit der Information wandeln, der Index das letzte Mal vermisst wurde, mir mit dem Datum, mit der Uhrzeit natürlich so ein bisschen anschauen, und wenn ich dann sehe, ok, er hätte jetzt möglicherweise vor einer Woche das mal benutzt und das sind vielleicht 30 Situationen, wo entsprechend die Informationen, bzw. der Index die Information schneller hätte heranziehen können, naja, kann ich mir überlegen, das ist es wahrscheinlich nicht wert. Auch diese statistischen Informationen werden von boot zu boot jeweils zurückgesetzt, d.h. das bedeutet seit dem letzten boot sieht es entsprechend so aus auf der Maschine, der eine Index einmal, der andere 1171 mal vermisst oder hätte Performance gebracht an der Stelle. Ich kann ihn jetzt anlegen und dann würde er aus der Liste verschwinden und dann käme er quasi in die andere Tabelle, bzw. Abfrage herein und dann könnte ich da sehen, wie oft wird er in der Tat denn wirklich benutzt dann. Also das muss man so ein bisschen abwägen, was da sinnvoll ist. Nicht auf jeden Ratschlag des SQL Servers hören.

SQL Server: Performance-Optimierung

Lernen Sie den Umgang mit Indizis und Tools, um die Leistungsfähigkiet Ihrer SQL Server Datenbank effektiv zu erhöhen.

3 Std. 20 min (32 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:04.05.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!