© best_vector/Shutterstock.com
Windows Developer
Adaptive Abfragenausführung mit dem SQL Server 2017

Das Performance-Perpetuum-Mobile


SQL Server 2017 brachte zahlreiche Neuerungen wie beispielsweise die Unterstützung verschiedener Linux-Derivate und Docker oder Verfügbarkeitsgruppen ohne Cluster mit. Neben diesen vielbeachteten Neuerungen hat sich auch einiges im Bereich der Performanceoptimierung getan: Im Vergleich zu den älteren Versionen gibt es nun einige Mechanismen, die eine automatische Optimierung der Abfragepläne versprechen.

Video: SQL Server 2017 (vNext)

In diesem Artikel soll sowohl auf die adaptive Abfrageausführung (Adaptive Query Processing) als auch auf das automatische Tuning im SQL Server 2017 eingegangen als auch die Funktionsweise dieser Optimierungsverfahren beschrieben werden [1]. Vorteilhaft für den SQL-Server-Entwickler bzw. -Administrator: Die vorgestellten Optimierungsverfahren laufen (sofern eingeschaltet, s. u.) transparent im Hintergrund ab, d. h. es ist keine weitere Konfiguration oder Ähnliches erforderlich.

Performanceoptimierung – die Sisyphosarbeit

Jeder, der sich schon einmal beruflich um einen SQL Server kümmern musste, kennt das Problem: Irgendwie laufen Abfragen langsam und die Umgebung erzielt nicht mehr die Performance, die sie ganz am Anfang gehabt hat. Das kann viele unterschiedliche Gründe haben. Neben der Tatsache, dass sich die Datenmengen im Vergleich zu den Anfangstagen der Applikation deutlich vergrößert haben – und das geht schnell, glauben Sie mir – greifen möglicherweise immer mehr Benutzer auf das System zu und verursachen so einen Einbruch der Systemleistung, der in bestimmten Fällen erheblich sein kann. Um die ursprüngliche Leistung des Systems wiederherzustellen, gibt es nun zwei Ansätze – einen einfachen und einen intelligenten. Der einfache Weg ist der, dass wir einfach Hardware auf das Problem schmeißen. Läuft der SQL Server nicht schnell genug, muss halt eine größere Kiste her: mehr Speicher, im Fall echter Hardware schnellere Platten, oder eine Umkonfiguration der VM. Dabei handelt es sich meiner Meinung nach um den „einfachen“ Weg, weil man nicht nachdenken muss, sondern einfach eine neue Maschine einkauft, den SQL Server umzieht und fertig ist. Allerdings führt er nicht immer zum Ziel, ist ggf. nur eine temporär erfolgreiche Lösung und mal ehrlich: Diese Art Lösung ist doch nicht der Grund dafür, dass wir uns alle mit IT beschäftigen.

Der intelligente Weg sieht so aus, dass wir uns mit dem eigentlichen Grund dafür beschäftigen, warum der SQL Server langsam ist, und sowohl Indizes als auch Abfragen optimieren. Zugegeben: ...

Windows Developer
Adaptive Abfragenausführung mit dem SQL Server 2017

Das Performance-Perpetuum-Mobile

SQL Server 2017 brachte zahlreiche Neuerungen wie beispielsweise die Unterstützung verschiedener Linux-Derivate und Docker oder Verfügbarkeitsgruppen ohne Cluster mit. Neben diesen vielbeachteten Neuerungen hat sich auch einiges im Bereich der Performanceoptimierung getan: Im Vergleich zu den älteren Versionen gibt es nun einige Mechanismen, die eine automatische Optimierung der Abfragepläne versprechen.

Frank Geisler


SQL Server 2017 brachte zahlreiche Neuerungen wie beispielsweise die Unterstützung verschiedener Linux-Derivate und Docker oder Verfügbarkeitsgruppen ohne Cluster mit. Neben diesen vielbeachteten Neuerungen hat sich auch einiges im Bereich der Performanceoptimierung getan: Im Vergleich zu den älteren Versionen gibt es nun einige Mechanismen, die eine automatische Optimierung der Abfragepläne versprechen.

Video: SQL Server 2017 (vNext)

In diesem Artikel soll sowohl auf die adaptive Abfrageausführung (Adaptive Query Processing) als auch auf das automatische Tuning im SQL Server 2017 eingegangen als auch die Funktionsweise dieser Optimierungsverfahren beschrieben werden [1]. Vorteilhaft für den SQL-Server-Entwickler bzw. -Administrator: Die vorgestellten Optimierungsverfahren laufen (sofern eingeschaltet, s. u.) transparent im Hintergrund ab, d. h. es ist keine weitere Konfiguration oder Ähnliches erforderlich.

Performanceoptimierung – die Sisyphosarbeit

Jeder, der sich schon einmal beruflich um einen SQL Server kümmern musste, kennt das Problem: Irgendwie laufen Abfragen langsam und die Umgebung erzielt nicht mehr die Performance, die sie ganz am Anfang gehabt hat. Das kann viele unterschiedliche Gründe haben. Neben der Tatsache, dass sich die Datenmengen im Vergleich zu den Anfangstagen der Applikation deutlich vergrößert haben – und das geht schnell, glauben Sie mir – greifen möglicherweise immer mehr Benutzer auf das System zu und verursachen so einen Einbruch der Systemleistung, der in bestimmten Fällen erheblich sein kann. Um die ursprüngliche Leistung des Systems wiederherzustellen, gibt es nun zwei Ansätze – einen einfachen und einen intelligenten. Der einfache Weg ist der, dass wir einfach Hardware auf das Problem schmeißen. Läuft der SQL Server nicht schnell genug, muss halt eine größere Kiste her: mehr Speicher, im Fall echter Hardware schnellere Platten, oder eine Umkonfiguration der VM. Dabei handelt es sich meiner Meinung nach um den „einfachen“ Weg, weil man nicht nachdenken muss, sondern einfach eine neue Maschine einkauft, den SQL Server umzieht und fertig ist. Allerdings führt er nicht immer zum Ziel, ist ggf. nur eine temporär erfolgreiche Lösung und mal ehrlich: Diese Art Lösung ist doch nicht der Grund dafür, dass wir uns alle mit IT beschäftigen.

Der intelligente Weg sieht so aus, dass wir uns mit dem eigentlichen Grund dafür beschäftigen, warum der SQL Server langsam ist, und sowohl Indizes als auch Abfragen optimieren. Zugegeben: ...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang