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

Speed Tests – Best Practices

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
In diesem Film fasst der Trainer eine Quintessenz der Speed-Tests zusammen und rät zu einer Reihe von Best Practices.
03:50

Transkript

Quintessenz aus dem Ganzen, was sind die "best practices"? Und ich denke, dass kann man in vier Punkten zusammenfassen: Zum einen "Clustered Index", immer dort benutzen, wo man die häufigsten Zugriffe erwartet. Über welchen Schlüssel wird am häufigsten auf meine Tabelle zugegriffen? Und man mag es drehen oder wenden, wie man möchte, es ist der "Primary Key". Man kann sagen, dass es in den meisten Fällen extrem sinnvoll ist, den Clustered Index auf den Primary Key zu legen und hat damit zumindest, wie gesagt in den meisten Fällen, gute Performance zu erwarten. Dann für alle anderen Zugriffe, für Suchen zum Beispiel, für Filter, entsprechend den "Non Clustered Index" zu benutzen, das macht Sinn. Damit kann ich sicherstellen, dass wenn ich Zugriff auf einen Tabelle habe, die jetzt nicht gleich den Primary Key, sprich in dem Fall den Clustered Index, wie wir es gerade definiert haben, einschließen, dass ich da noch entsprechend gute Performance bekommen kann. Ich würde natürlich nicht jede einzelne Spalte irgendwie indexieren. Ich würde auch nicht versuchen, möglichst viele Indizes anzulegen, weil jeder Index natürlich auch Arbeit bedeutet, die Indizes müssen aktualisiert werden, die müssen persistiert werden und, und, und. Das heißt, ich würde mir natürlich genau nach meinen Use Cases heraussuchen, über welche Spalten wird denn überhaupt auf eine Tabelle zugegriffen und damit würde ich dann entsprechend die Clustered Indices aufbauen beziehungsweise – Entschuldigung, den Non Clustered Index natürlich aufbauen. Dann den "Clustered Columnsotre Index" würde ich dort benutzen, wo ich eine große Zeilenanzahl habe und "groß" meine ich ein Vielfaches einer Million. Je mehr, fast umso besser, weil dann kommt die Kompression auch ganz gut ins Spiel, Sie haben gesehen, selbst bei nur 10 Millionen Zeilen, was eher die untere Kategorie an Größe ist für Clustered Columnstore Index, komme ich schon ungefähr auf 50 Prozent und das ist ja schon einmal so nicht schlecht. Problem ist natürlich, dass sie ansonsten nicht besonders schnell sind, damit eignen sie sich aber sehr gut für historische Daten. Ab SQL Server 2016 gibt es die Möglichkeit, "Temporal Table" oder "System Version Table" zu haben. Das heißt, immer wenn ich eine Änderung an den Daten mache, also in einer Tabelle ein UPDATE oder DELETE durchführe, dann wird die Originalversion der Zeile in einer Historientabelle archiviert und das könnte zum Beispiel so ein Clustered Columnstore Index sein an der Stelle. Ich habe dann die Möglichkeit, auf die Daten immer noch zuzugreifen. Ich habe also kein "Cold Storage" oder Ähnliches, sondern eher sowas wie ein "Warm Storage" und die Performance ist schon ein bisschen langsam. Aber ich kann zumindest für historische Analysen noch auf die Daten zugreifen und fahre damit eigentlich ganz gut. Dann "Memory Optimized", jetzt mit oder ohne "Schema Only", das ist natürlich der Ferrari an der Stelle. Ich habe schnelle Möglichkeiten, Daten abzulegen. Ich habe eine schnelle Möglichkeit, Daten zu berechnen, zu suchen und das funktioniert alles ziemlich schnell. Es hat natürlich einen Nachteil: Ich brauche sehr viel RAM. Wenn ich mehr RAM als Datenbank habe, wäre das vielleicht durchaus eine gute Idee, das zu tun. Aber dann ist es meistens auch so, dass die Datenbank so klein ist, dass es auch mit herkömmlichen Mitteln, sprich Clustered und Non Clustered Index, hervorragend performant ist an der Stelle. Das heißt, das muss man so ein bisschen abwägen, aber wenn Sie zum Beispiel ein Szenario haben, wo Sie Daten nur möglichst schnell aufnehmen wollen, dann später weiterverarbeiten, also schnelle Erfassung oder Zwischenergebnisse oder Ähnliches, dann ist es durchaus eine Option, die Sie nutzen können an der Stelle. Und je mehr RAM Sie haben für den SQL-Server, an der Stelle natürlich umso besser. Wie gesagt, halten Sie aber im Kopf, dass, wenn Sie mehr RAM benötigen würden, um die In-Memory-Tabellen entsprechend abzuspeichern, dass die Datenbank schlicht nicht gestartet wird. Das ist nicht so, dass nur ein Teil der Tabellen geladen wird, sondern es geht nach dem Alles-oder-nichts-Prinzip.

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!