SQL Server Neustart - Warum ist nun alles wieder schnell?

Viele Unternehmen haben die Erfahrung gemacht, dass ein Neustart eines SQL Servers tatsächlich Performance Probleme zu lösen scheint. Was ist da los?

Es ist Monatsende, die Abrechnung läuft, die Revision auch und der Datenbank Server scheint wieder mal zu stehen. Ein Blick auf Ihre Monitoring Lösung zeigt, dass der Server mit knapp 94% CPU am Anschlag läuft. Mit einem Seufzer schreiben Sie eine kurze Rundmail, öffnen eine Terminal-Session und starten den Windows Host des SQL Servers einmal durch. 

 

Wenige Minuten später ist alles wieder oben und auch wieder ausreichend schnell. Vorerst. 

 

Die Geschäftsleitung steht auch wieder mal in der Tür und fragt, ob wir "den Kram" nicht endlich mal austauschen, erneuern oder einfach in die Tonne drücken sollten. Auf jeden Fall ginge das so nicht weiter. 

 

Der Hardware Lieferant weist jegliche Schuld von sich. Hat "den Kram" schon zweimal durchgeprüft und alles geupdated, was möglich war. Und deren Angebot für ein noch schnelleres Storage System liegt auch schon vor. 

 

Der Software Lieferant weist jegliche Schuld von sich, da die Lösung ja auch bei anderen Kunden stabil läuft. Dieses merkwürdige Verhalten gäbe es nur bei uns. Müsse also die Hardware, das Netzwerk oder was auch immer sein. Die Buchhaltung spricht schon von Erdstahlen unterm Server-Keller. Vielleicht ist es doch an der Zeit endlich in die Cloud zu gehen? 

 

Das Thema "neuer und schnellerer Server??" steht für das Quartal am Whiteboard. Da sind sich sowohl Hardware- als auch Software Lieferant einig. Nur warum läuft der SQL Server die meiste Zeit reibungslos? Das "Problem" tritt ja nur vereinzelt auf. Nur wenn, dann auch so, dass es leider auch wirklich jeder im Unternehmen mitbekommt. 

 

Kommt Ihnen das bekannt vor? 

Liegt es an der Hardware, dass der SQL Server ab und zu mal sehr langsam ist?

Kurze Antwort: Quasi nie. 

 

Längere Antwort: Natürlich kommt es wieder mal drauf an, aber ja, es liegt mittlerweile selten an der Infrastruktur. Heute (2024) als auch in den letzten 10-15 Jahren tritt die Hardware als primäres Problem immer mehr in den Hintergrund. Insbesondere, wenn der SQL Server als Datenbank System die meiste Zeit reibungslos läuft. 

 

Echte Hardware Fehler sind zum Glück sehr selten geworden. 

Ist die Server Hardware für den SQL Server zu klein dimensioniert?

Gutes Thema, nur selten der primäre Grund für das oben beschriebene Verhalten des SQL Servers. 

 

Wenn die Performance Probleme gefühlt willkürlich auftreten und auch wieder verschwinden, sogar ohne einen Neustart, dann ist die Hardware selten einfach "zu klein". 

 

Kennen Sie auch diese Gespräche? "Sagt mal, gestern, so gegen 11:30, kurz vorm Mittag, habt Ihr da was am Server gemacht? Da war alles super langsam bei uns. Aber nach dem Mittag lief wieder alles."

Müssen alte Daten gelöscht werden, weil die Datenbank zu groß geworden ist?

Haben Sie diesen Vorschlag schon mal gehört?

 

In der Regel kommt dieser irgendwann vom Software Lieferanten. Gerne auch mit dem Hinweis, dass bei anderen Kunden die Datenbank ja "viel" kleiner sei und die hätten ja nie Probleme.

 

Der Geschäftsleitung leuchtet dieser Vorschlag auch völlig ein, weil klingt ja auf den ersten Blick total logisch: Viele Daten, Server langsam!

 

Spoiler-Alert... Wir nähern uns langsam der häufigsten Ursache, aber es ist nicht die eigentliche Größe der Datenbank.

 

Und noch ein Wort der Warnung gleich dazu. Sofern Sie einen Test machen werden auf einem Test-Server mit weniger Daten, ja, das wird dann wohl schneller sein und sehr wahrscheinlich keinen Neustart mehr benötigen. Womit aber das eigentliche Probleme erfolgreich kaschiert wurde.

 

Wenn ein SQL Server Daten liest, zum Beispiel einen Kundenauftrag, dann erwartet man ja, dass er diesen "direkt" liest, oder? Also sich nicht die Zeit nimmt und erst mal ALLE Aufträge aller ALLER Kunden auf den virtuellen Schreibtisch holt und zu blättern anfängt. Und dann kommen noch Kollegen vorbei, welche auch dringend mal einen Auftrag suchen, aber geht ja gerade nicht, weil wird ja gerade drin geblättert. 

 

Die Erwartung ist, dass ein Datenbank System, wie der SQL Server, einen Beleg sofort und findet, also direkt zum richtigen Ordner greift und die bunte Reiterpappe am Rand nutzt. Und genauso macht dieser es auch. Weil es Sinn macht für eine Warenwirtschaft (ERP) System. 

 

Wann sollte der SQL Server blättern? Wenn eine Auswertung gefragt ist, weil dann müssen viele Aufträge gelesen und aufsummiert werden. 

 

Sollten Sie also auf historische Daten im System verzichten, weil der Datenbank Server die Tendenz hat zu vergessen, wie man schnell einen Auftrag findet? 

Warum hilft nun ein Neustart des SQL Servers?

Sicherlich haben Sie schon davon gehört, dass ein SQL Server mittels der Sprache T-SQL angesprochen wird. Dieses T-SQL ist aber keine Programmiersprache wie Java, C#, Javascript usw. Es gibt auch keinen Compiler für T-SQL, sondern einen sogenannten Optimizer. 

 

Egal in welcher Programmiersprache Ihre eigentliche Anwendung (WaWi, ERP, eCommerce, CRM, Kampagnensteuerung, Game-Server usw.) geschrieben ist, am Ende spricht diese mit dem SQL Server nur in T-SQL. Es gibt keine Ausnahme!

 

Dieses T-SQL trifft also auf den SQL Server, dort wird es analysiert und in etwas umgewandelt, was man als Ausführungsplan bezeichnet. Und dieser Vorgang ist etwas komplexer als es auf den ersten Blick zu schein scheint. Weil, der erwähnte Optimizer nimmt nicht nur das T-SQL Statement, sondern schaut sich auch die Tabellen der Datenbank an. Wie viele Daten sind in diesen gerade? Wie sind die Daten in den Spalten der Tabelle aus statischer Sicht verteilt? Welche Indexe gibt es? Was sucht der Anwender eigentlich gerade in diesen Tabellen? Deswegen nennt man diesen Prozess optimieren, weil es wird versucht einen möglichst optimalen Plan für genau dieses T-SQL für genau diese Daten zu erzeugen. Klassischer Code wie Java oder C# wird einmalig kompiliert und das wars. 

 

Warum macht man sich die Mühe mit T-SQL? Weil der Optimizer u.a. entscheiden muss, ob der SQL Server sich einen Ordner und damit einen Auftrag schnappen soll oder lieber ins Blättern verfällt. Klingt gut? Ist es auch. Aber...

 

Wenn man sich das einmal mit Abstand anschaut, dann wird klar, dass die Ausführung von T-SQL von den Daten auf dem SQL Server abhängt. Damit könnte das ja bei jedem Kunden einer Softwarelösung anders sein. Die einen haben Belege mit wenig Positionen, andere rechnen nur am Monatsende ab und haben dementsprechend längere Belege. Die einen haben wenig Artikel, andere sehr viele davon. Die einen haben wenige große Kunden, andere haben viele Kunden. Usw.

 

Damit wird klar, dass der Software Lieferant einen harten Job hat, da dieser eigentlich nicht wissen oder gar garantieren kann, was für ein Ausführungsplan aus dem T-SQL auf Ihrem Server wird. (Okay, das stimmt nicht ganz, es gibt Software Lösungen, welche das recht gut können. Auf Anfrage verraten wir gerne welche.)

 

Dazu kommt, da dieser Optimierungsprozess recht aufwändig ist, dass der SQL Server sich diese Pläne merkt. Er hat sie dann für das nächste Mal, wenn dieses T-SQL kommt, vorbereitet liegen, um Zeit (und CPU) zu sparen. Einer der Gründe, warum ein SQL Server in großen Umgebungen mit auch hunderttausend Anwendern und Terrabyte an Daten sehr schnell laufen kann. 

 

Nun ist es aber so, dass, wenn es "doof läuft" aka der Software Lieferant eine Kombination an Datenmenge, Datenzusammensetzung und Parameter nicht ausreichend getestet hat, der Optimizer einen Ausführungsplan erzeugen wird, welcher nur für genau diesen einen Fall Sinn ergibt. Der Plan ist nicht schlecht, nur halt besonders. Aber auch dieser wird sich gemerkt. Man spricht da übrigens vom "Plan Cache".

 

Aber dieser besondere Plan wird auch wiederverwendet. Und hier fängt das Drama an, denn evtl. passt der Plan hier nicht mehr so gut oder ist sogar völlig unpassend.  

 

Und damit können die Prozesse in einer Software Lösung aus dem Nichts heraus langsam werden. Insbesondere, wenn sich der SQL Server so einen besonderen Plan für einen wesentlichen Prozess gemerkt hat.

 

Und was bringt nun der Neustart? Der SQL Server merkt sich Ausführungspläne im Hauptspeicher. Nach "einiger Zeit" werden Pläne zwar erneuert und auch besondere Pläne verschwinden dann wieder, aber zunächst einmal liegen diese im RAM des Servers.

 

Und ja, ein Neustart löscht quasi den Plan Cache, weil mit jedem Start der SQL Server Instanz der Plan Cache neu gefüllt wird. 

Es liegt also an der Software Lösung?

Leider ja, meistens. Sozusagen. 

 

Genau genommen können wir dem Software Lieferanten oft nicht wirklich die "Schuld" geben. Denn die Entwickler müssen sich auf die Implementierung von Geschäftsprozessen konzentrieren und können nicht immer tief in die Performance-Optimierung und die Funktionsweise der Query Engine des SQL Servers eintauchen. Das ist auch nicht ihre Kernaufgabe. Dennoch sind solche Performance-Probleme keine Seltenheit und sie können für Unternehmen sehr frustrierend sein.

 

Und nein, die Lösung ist natürlich nicht, dass Sie Ihren SQL Server nun regelmässig oder bei Bedarf neustarten sollen!

 

Es sehr wertvoll sein, sich Expertenrat zu holen. Die  Erfahrung hat gezeigt, dass spezialisierte SQL Server Experten häufig in der Lage sind, Performance-Probleme schnell zu identifizieren und zu beheben. Dabei können sie sowohl kurzfristige Lösungen als auch langfristige Optimierungen umsetzen, die die Stabilität und Performance Ihrer SQL Server-Umgebung nachhaltig verbessern.

 

Unsere Expertise in der Performance-Optimierung von SQL Servern hat bereits vielen Unternehmen geholfen, die Leistung ihrer Datenbanken signifikant zu steigern und Ausfallzeiten zu minimieren. Wir arbeiten eng mit Ihren Entwicklern und Ihrer IT-Abteilung zusammen, um passende Lösungen zu entwickeln, die auf Ihre Bedürfnisse zugeschnitten sind.

 

Ein weiterer wichtiger Aspekt unserer Arbeit ist die Weiterbildung und Schulung Ihrer Teams. Wir bieten spezialisierte Workshops an, die darauf abzielen, Ihre Software-Lieferanten und Entwickler für die Performance-Optimierung und die effiziente Nutzung des SQL Servers zu sensibilisieren. Diese Schulungen sind darauf ausgerichtet, langfristig die Qualität und Performance Ihrer Anwendungen zu sichern und zukünftige Probleme proaktiv zu vermeiden.

 

Kontaktieren Sie uns heute und lassen Sie uns gemeinsam herausfinden, wie wir Ihre SQL Server-Umgebung optimieren und Ihre Performance-Probleme  lösen können. Denn eine reibungslos laufende Datenbank ist kein Zufall, sondern das Ergebnis gezielter Optimierung und kontinuierlicher Pflege.

 

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