Hilft ein Update auf die neuste SQL Server Version bei Performance- und Skalierungsproblemen?

Ist Neuer immer gleich auch Besser? Erstaunlicherweise ist die Antwort oft ein klares "Ja"! 

 

Das neue Smartphone läuft flotter und hält länger. Das neue Auto liegt noch besser auf der Straße und hat mehr technische Assistenzsysteme, die einem das Leben leichter machen. Die neue Bildbearbeitungssoftware macht gefühlt den Urlaub selbst quasi überflüssig. 

 

Also, hilft bei Performance Problemen auch einfach ein Update auf eine aktuellere SQL Server Version und alles ist wieder gut? 

 

Kurze Antwort: Nein!

 

Längere Antwort: Es kommt (natürlich) drauf an, aber es gibt meist eine klare Tendenz zum "Nein" von oben. Wenn Sie es eilig haben, dann dürfen Sie auch gerne ganz nach unten scrollen für das eigentliche Probleme. 

 

Warum ist das so? Entwickelt Microsoft seinen SQL Server etwa nicht kontinuierlich weiter? Warum gibt es dann immer neue Versionen und neue Features auf den Marketing Powerpoints?

 

Die primäre Antwort auf diese Fragen ist Rückwärtskompatibilität.

 

Microsoft kann die Engine des SQL Servers nicht einfach von einer Version zur nächsten komplett austauschen. Kunden haben Unsummen über die letzten Jahrzehnte für die Software Entwicklung für den SQL Server ausgegeben. Das sind meist komplexe Architekturen und Lösungen, welche gut optimiert wurden auf die SQL Server Engine. Diese Lösungen bewegen sich quasi in einem Rahmen von "physikalischen Gesetzen".

 

Damit sind Zusammenhänge gemeint, wie z. B.

  • Wann wird welcher Index wie genutzt?
  • Wie hält man seine Ausführungspläne stabil?
  • Wie wird der Hauptspeicher genutzt?
  • und so viel mehr...

Sollte Microsoft zu sehr an diesen Säulen rütteln, dann wäre ein Versionsupdate für Kunden, die eine funktionierende Lösung und ausreichende Performance haben, eine Katastrophe. 

 

Dazu kommt der Mythos, dass die alten Versionen des SQL Servers langsam sind. Dem ist erstaunlicherweise gar nicht so. Bereits mit SQL Server 7 als auch SQL Server 2000 gab es schon eine ganze Reihe von sehr großen und leistungsfähigen Architekturen. 

 

Was bringt Microsoft also an neuen Features ein, welche Performance adressieren? Unendlich viele. Nur muss man unterscheiden, ob diese Features einen existierenden Workload einer vorhandenen Lösungen optimieren oder eher für Neuentwicklungen zur Verfügung stehen. 

 

Microsoft hat in jeder Version Features eingebracht, welche existierenden Workload optimiert haben. Zunächst musste man diese oft mit sogenannten Traceflags aktivieren, später ging Microsoft dazu über, dass diese automatisch aktiv sind. Meist handelte es sich dabei um Features, welche aktuellere Hardware besser ausnutzen. Des Weiteren gibt es immer eine Reihe von Features, welche von Microsoft unter dem Claim "It just runs faster" zusammengefasst werden. Diese können schon mal 10-20% mehr an Performance bringen. Besonders wenn Sie von einer älteren Version auf SQL Server 2016 oder aktueller wechseln. Aber unterm Strich helfen diese Features meist nicht, um ernsthafte Probleme quasi verschwinden zu lassen. 

 

Der ursprüngliche Kern der aktuellen Engine (Stand Q1 2022) basiert zum Teil immer noch auf der Version 7. Das ist ein Fakt, welcher in unseren Workshops und Trainings meist erst auf Unglauben trifft, wir diesen Fakt aber schnell untermauern können. 

 

Dazu kommt, dass einige neue Features nicht für jeden gleich gut funktionieren. Zum Beispiel wurde mit dem SQL Server 2014 ein neuer "Cardinality Estimator" aktiviert. Einfach gesagt: Der SQL Server fing an andere Ausführungspläne zu generieren. Damit war ein Teil seiner Rückwärtskompatibilität eingebüßt worden, was auch sofort in der Community für "Ungemach" sorgte. Noch heute unterstützen wir diverse Kunden bei der Aufarbeitung exakt dieser Baustelle. Andere Kunden wiederum profitierten natürlich von dieser Änderung der Engine. 

 

Wiederum andere Features stellen neue Technologien dar, welche Entwickler aktiv verwenden müssen. Promiente Beispiele dafür sind: 

  • In-Memory OLTP
  • Spaltenbasierte Indizes

Und experimentierfreudige Kunden stürzten sich auf diese. Und waren oft enttäuscht, weil diese nicht die erhoffte Verbesserung brachten oder ermöglichten. 

 

Bei diesen neuen Technologien handelt es sich nicht um bessere Alternativen zu vermeintlichen Vorgängern, sondern um Erweiterungen der SQL Server Engine für spezielle Fälle. Zum Beispiel ist ein spaltenbasierter Index nicht automatisch für jeden Anwendungsfall die erste Wahl, sondern eher für analytische Szenarien. 

 

Eine abschließende Bemerkung noch dazu. Genaugenommen kann ein nicht wirklich durchdachter Versionssprung eher noch mehr Unruhe in eine eh schon anspannte Situation bringen. Wir waren schon öfters dazu geholt worden, nachdem sich ein Kunde entschieden hat, aus purer Verzweiflung ein Update durchzuführen und danach alles noch unübersichtlicher geworden ist. Aus einer solchen Position heraus dann eine fundierte Analyse des eigentlichen Problems durchzuführen wird dann unnötig aufwendig. 

 

Aber zurück zur ursprünglichen Fragestellung: Was hilft denn dann meist bei Performance Problemen?

 

Natürlich gibt es noch die Fälle, bei denen eine Konfiguration des SQL Servers unglücklich gewählt wurde oder das Plattensystem schlicht zu langsam ist. Und ja, auch ein produktiver SQL Server braucht mehr als 8GB Hauptspeicher, also meistens. Was aber nicht heißt, dass eine unreflektierte Erweiterung ins Endlose immer eine brauchbare Lösung darstellt. 

 

Also wenn man diese Fälle abzieht, welche übrigens mittlerweile nur noch knapp 10% unseres Arbeitsaufkommens ausmachen, dann kommen wir zu den Kunden mit Softwareprodukten, welche leider wenig oder manchmal auch überhaupt nicht optimiert wurden. Was dazu führt, dass die vorhandene Hardwareleistung wirklich genutzt werden kann, was zu vermeintlichen Engpässen führen kann. Mehr zum Mythos Engpass auch gern in diesem Artikel. 

 

Das Fazit ist, dass oft schon minimale Anpassungen am Workload einer Software für einen gefühlten Quantensprung in der Performance und Skalierbarkeit sorgen können. 

 

Das können sowohl zusätzliche Indizes sein als auch Optimierungen an T-SQL Statements, welche auch ohne Zugriff auf den eigentlichen Quelltext möglich sind. Zurzeit kann auch Microsoft noch immer nicht automatisch einen SQL Server Workload komplett von allen bei der Entwicklung entstandenen Problemen oder Ungereimtheiten heilen. 

 

Sollten Sie neugierig geworden sein bzgl. unserer Vorgehensmodelle und Systeme, dann empfehlen wir Ihnen auch u. a. folgende Artikel: