Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

SQL Server: Performance-Optimierung

Wie schnell sind 1000.000 DELETEs?

Testen Sie unsere 2021 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Last, but not least, liefert dieses Video einen Geschwindigkeitstests für 100.000 DELETEs.
04:44

Transkript

Interessant ist es natürlich auch zu messen, wie lange es dauert, Zeilen zu löschen. Und da benutze ich wieder das gleiche Skript, ich modifiziere das nur ein bisschen, sodass diesmal keine Daten ausgewählt oder aktualisiert werden, sondern schlicht und ergreifend gelöscht mit einem DELETE-Statement. Und ich zeige Ihnen auch hier kurz das Skript, bevor ich es dann ausführe und Ihnen später dann die Ergebnisse präsentiere. Und im SQL Server Management Studio begrüßen wir einen fast schon alten Bekannten. Das ist das gleiche Skript, nur ein bisschen modifiziert. Hier finden Sie an den entsprechenden Stellen keine Update-Anweisungen und keine SELECT-Anweisungen, sondern schlicht ein "DELETE" und letztendlich muss man hier sagen, eigentlich ist es ein bisschen gemogelt. Ich gehe hin und möchte zehntausend Zeilen löschen, was nicht zwangsläufig bedeutet, dass ich auch wirklich zehntausend Zeilen lösche, weil der Zufallsgenerator natürlich rein theoretisch mehrfach ein und dieselbe Zeile über deren ID auswählen könnte und die könnte versucht werden zu löschen. Allerdings da die Zeile nur einmal gelöscht werden kann, würde das darauf hinauslaufen, dass weniger Zeilen als hunderttausend gelöscht werden. Nichtsdestotrotz kalkuliere ich das ein. Was sind 100 000 Zeilen, die ich lösche, aus einer Gesamtmenge von 10 Millionen Zeilen. Das, denke ich, kann man vertreten an der Stelle. Und das Skript gibt es auch hier in doppelter Couleur, das heißt, einmal wie gezeigt und an der anderen Stelle, hier im zweiten Editor eigentlich fast identisch, abgesehen von dem Zusatz "OPTION (MAXDOP 1)" an der Stelle, damit ich das auch einmal ohne Parallelisierung ausprobieren kann. Ich lasse das Skript jetzt laufen, notiere die Ergebnisse und wir sehen uns in wenigen Sekunden auf dem Ergebnis-Sheet. Oh, da sind Sie ja schon und hier ist das Ergebnis. Ja, wie es so aussieht, "Clustered Columnstore Index" hat an der Stelle, na ja, wieder die längste Laufzeit aufzuweisen. Interessant ist hier: eine Parallelisierung offensichtlich eher kontraproduktiv. Mit "Maxdrop 1", die gelbe Säule liegt nur bei 480 im Vergleich zu 502 Sekunden mit acht Kernen. Tja, dafür ist offensichtlich ein "Clustered Columnstore Index" auch nicht so richtig gut gebaut an der Stelle. Schauen wir uns doch einmal die anderen Werte an. "Non-Clustered"-Indizes und "Clustered"-Indizes liegen recht eng beieinander bei 28, 22 und 23 Sekunden. Das tut sich nicht besonders viel an der Stelle, macht auch durchaus einen Sinn, weil letztendlich die Art des Zugriffs die gleiche ist und die Zeile wird als "gelöscht" markiert im SQL-Server und später dann auch wirklich physisch entfernt. Auf der rechten Seite, die "Memory Optimized Tables", die sind beide extrem schnell. Das eine relativ langsam noch mit 13 und 15 Sekunden, wenn ich also auch wirklich eine Persistenz haben möchte. wenn es mir reicht, die Daten nur im Speicher zu haben, dann liege ich ungefähr bei einer Sekunde und da ist es eigentlich fast egal, ob ich einen 8-Kern oder eine Maxdrop 1 einsetze an der Stelle. Letztendlich der Unterschied lag im Millisekundenbereich. Ich habe immer kaufmännisch gerundet, sodass ich in beiden Fällen auf 1 gekommen bin, insofern da tut sich nicht mehr besonders viel. Das heißt auch hier, "Memory Optimized" scheint erst einmal eine durchaus Interessante Option zu sein. Da muss ich natürlich auch wieder auf das generelle Transaktionsverhalten eingehen und ich muss natürlich – und das dürfte der größte Nachteil fast sein, genügend Speicher haben, um mal Tabellen alle auch wirklich im RAM zu halten. Wenn ich natürlich nur ein Tabelle habe oder relativ viele kleine Tabellen, ist das vielleicht einfacher, aber Sie können sich vorstellen, dass es natürlich nicht ganz so einfach ist, eine Tabelle von 300, 400 GB im Speicher zu halten. Da muss ich natürlich erst einmal eine ganze Menge letztendlich an Geld in die Hand nehmen, damit ich an so eine Maschine komme. Ein anderer Punkt ist, den man berücksichtigen sollte, auch hier ist natürlich letztendlich ein bisschen ausgeklammert, dass das Laden – ich habe es schon einmal erwähnt, aber ich wiederhole es, einfach weil es wichtig ist, nochmal – letztendlich das Laden der Daten in den RAM für diese Tabelle beim Start der Datenbank geschieht. Das heißt ja letztendlich, die Dauer tritt auf jeden Fall ein. Ich kann sie hier in dem Fall nur nicht wirklich messen. Je mehr oder je umfangreicher die in Memory Optimized Tables sind, die ich in meiner Datenbank habe, umso länger dauert es natürlich auch, bis diese gestartet ist und es kann durchaus sein, dass es ein, zwei Minuten dauert, bis die ganzen Daten endlich geladen sind. Das ist natürlich ein sehr extremes Beispiel, aber das dauert einfach so und so lange, bis dann die Datenbanken hier zur Verfügung stehen. Auch das sollte man vielleicht ein bisschen im Auge behalten.

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!