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

Versteckte Bremsen – Theorie

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Viele versteckte (Performance-)Bremsen fallen bei näherer Betrachtung schnell ins Auge. Dieser Film zerrt einige häufige Fälle ins Rampenlicht.
05:21

Transkript

Der nächste Sachverhalt, für den ich Sie ein bisschen sensibilisieren möchte, sind versteckte Bremsen, die man sich, ja, relativ schnell einhandelt und denen man sich gar nicht so sehr bewusst ist, aber die trotzdem die Anwendung richtig ausbremsen können. Was kann das zum Beispiel sein? Trigger. Vielleicht brauche ich Trigger. Ich habe aber in vielen Fällen festgestellt, dass Trigger entwickelt wurden, dass man Trigger irgendwann eigentlich gar nicht mehr wirklich benötigt, also die reine Funktionalität, die hinter diesem Trigger steht in der Tat zwar in der Datenbank belässt. Man braucht es ja vielleicht nochmal. Man lässt diese Trigger immer mitlaufen. Und irgendwann ist es einfach schlicht und ergreifend eine Ressourcenverschwendung, den Trigger mitlaufen zu lassen. Der wird ja irgendwas tun, vielleicht irgendwelche Daten irgendwo einfügen, irgendwas verändern. Aber die reine Funktionalität brauche ich eigentlich gar nicht mehr. Und da muss man wirklich sagen: Okay, dann baue ich diesen Trigger aus und habe einfach nicht das Problem, dass ich da Ressourcen massiv, gerade bei Änderungen an Daten, verschwende an der Stelle. Der nächste Punkt sind Check Constrains, das heißt Constrains, mit denen ich überprüfe, ob gewisse Bedingungen in einer Tabelle, genauer gesagt in einer Zeile in vielen Fällen, vorliegen oder nicht. Auch das kann ich natürlich relativ komplex gestalten. Ich kann mir Funktionen überlegen, die relativ aufwendige Prüfungen machen, die möglicherweise über die CLR-Integration des SQL-Servers hingehen, komplexe Berechnungen durchführen, und wenn die nicht das richtige Ergebnis liefern, dann schlicht und ergreifend die Zeile als nicht gültig erachten. Das kann sinnvoll sein, keine Frage. Aber in vielen Anwendungen ist es so, dass gerade die Business-Logik solche komplexen Prüfungen durchführt und die Daten nur noch in die Datenbank schreibt. Und wenn ich sicherstellen kann, dass außer mir kein anderer Prozess die Datenbank in irgendeiner Form an der Stelle modifiziert, dann kann ich mir möglicherweise überlegen, ob ich in der Tat diese Check Constrains rauslasse, das heißt nicht noch ein zweites Mal prüfe, und wenn es nicht unbedingt notwendig ist und wenn ich auf jeden Fall eine gute Datenqualität benötige, dass ich dann quasi hingehe und einen Prüfprozess regelmäßig laufen lasse, aber nicht bei jeder Änderung die komplette Zeile zu validieren. Das macht in vielen Fällen schlicht und ergreifend keinen besonders großen Sinn und kann einfach eine versteckte Bremse sein. Der dritte Punkt ist das unnötige Lesen von statischen Inhalten. Das bedeutet, gerade wenn ich eine Web-Anwendung habe und beispielsweise auf einer Seite einer Web-Anwendung eine Dropdown-Liste habe, dann ist der Inhalt dieser Dropdown-Liste höchstwahrscheinlich immer der gleiche. Der wird sich vielleicht über die Zeit in der Tat wirklich ändern, aber für den Anwendungslauf sind das in der Tat wirklich die Informationen, die sich nicht ändern. Da kommt immer der gleiche Inhalt. Und es ist natürlich eigentlich eine totale Verschwendung, wenn ich jedes Mal die Information für diese Dropdown-Liste aus der Datenbank herauslese. Viel besser wäre es, ich hätte eine Art von Cache möglicherweise, sei es im Speicher oder sei es, ich würde Redis oder ähnliches benutzen, dass ich wirklich hingehe und sage, die Daten müssen nicht jedes Mal aus dem SQL-Server ausgelesen werden. Und selbst wenn ich Dropdown-Listen habe, wo die Auswahl einer Dropdown-Liste den Inhalt einer zweiten Dropdown-Liste beeinflusst und die wiederum die Auswahlmöglichkeiten in einer dritten Dropdown-Liste beeinflussen, dann macht es vielleicht schlicht und ergreifend Sinn, die gesamten Daten in irgendeiner Form zu cachen im Speicher, was auch immer ich da haben möchte, aber nicht jedes Mal aus der Datenbank herauslesen muss. Also, da sollte man sich wirklich genau überlegen, was denn in der Tat wirklich notwendig ist, was an frischen Daten vom Server kommen muss. Und nicht alles muss aus der SQL-Server-Datenbank kommen. Dann gibt es ein Problem, das nennt sich SELECT n+1, und diejenigen der Zuschauer, die möglicherweise im Entity Framework unterwegs waren oder sind, werden mit dem Problem vielleicht schonmal konfrontiert worden sein. SELECT n+1 habe ich immer dann als Problem, wenn ich beispielsweise versuche, hinzugehen und eine, sagen wir mal, eine Rechnung zu laden und gleichzeitig oder in nachfolgenden Schritten die einzelnen Rechnungspositionen. Das wäre natürlich total effizient. Ich würde hingehen, die Rechnung und gleichzeitig die Rechnungspositionen zu laden, und dann join ich das zusammen. Das ist das, was Entity Framework machen würde. Oder ich habe zwei SELECT-Statements, einmal Rechnung, einmal Rechnungspositionen. Das ist das, was möglicherweise das Entity Framework Core machen würde. Wenn ich es ungeschickt anstelle, dann fängt das Entity Framework relativ schnell an, hinzugehen, einmal den Rechnungskopf zu laden und dann jede einzelne Zeile nochmal nachzuladen, die für die Rechnungspositionen stehen, und das ist dieses n+1. Das bedeutet: Er macht für 30 Bestellpositionen 31 Zugriffe, nämlich einmal für die Rechnung selber plus 30 für die Bestellpositionen. Und Sie können sich sicherlich vorstellen, dass das Abfeuern von zwei Abfragen oder sogar nur von einer gejointen Abfrage viel, viel performanter ist als das Abfeuern von 31 einzelnen Statements an der Stelle. Wie man das rausfinden kann? Relativ einfach. Trauen Sie erst natürlich nicht Ihrem OR-Mapper. Entity Framework und auch andere OR-Mapper sind tolle Tools, mit denen man fantastische Anwendungen bauen kann. Nichtsdestotrotz ist es nichts anderes als ein Stück Software, und die muss nicht immer die besonders beste Entscheidung in jeder Situation treffen. Was man relativ leicht machen kann, um ein solches Problem in den Griff zu bekommen oder erstmal als solches zu diagnostizieren, zeige ich Ihnen jetzt hier.

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!