Wann läuft unser SQL Server wieder zuverlässig?

„Fehlt unserem Team das Know-how?“ Manchmal ja. Häufiger hat sich die Umgebung verändert: Die Daten sind gewachsen, Abläufe werden anders genutzt, neue Berichte und Schnittstellen konkurrieren mit dem Tagesgeschäft. Beides lässt sich unterscheiden und bearbeiten. Seit 1998 ist das unsere Arbeit bei PSG: die Ursache finden, ändern, was wirkt, und prüfen, ob es hält.

Optimieren und steuern sind zwei Aufgaben

Performance lässt sich optimieren. Damit sie stabil bleibt, muss sie laufend gesteuert werden. Dazu gehören drei Aufgaben:

• Performance Tuning behebt ein konkretes Problem oder beschleunigt einen Ablauf.
• Performance Engineering gestaltet Anwendung und Arbeitslast so, dass sie unter den erwarteten Bedingungen tragen.
• Performance-Risikomanagement erkennt künftige Verschlechterungen früh, bewertet sie nach ihren geschäftlichen Folgen und prüft, ob Maßnahmen wirken.

Eine gute Optimierung kann ein Problem dauerhaft beseitigen und erhebliche Reserven schaffen. Sie hält aber die Umgebung nicht an. Datenbestand, Nutzung, Hintergrundjobs, Releases, Statistiken und Indizes verändern sich weiter. SQL Server wählt seine Ausführungswege anhand von Schätzungen und verwendet sie wieder. Ein Weg, der gestern gut war, passt deshalb nicht zwingend zu den Daten von morgen.

Für das Management bedeutet das einen wiederkehrenden Ablauf: kritische Abläufe bestimmen, Risiken bewerten, Maßnahmen vereinbaren, Veränderungen beobachten und die Wirkung prüfen.

Ein Beispiel aus unserer Praxis

Eine zentrale Listenansicht einer geschäftskritischen Anwendung reagierte träge. Ein erster, fachlich naheliegender Eingriff änderte an den Messwerten nichts. Der Befund: In der Ausführungshistorie von SQL Server war für die entscheidende Abfrage seit Langem ein bestimmter Plan festgelegt. Wann und warum, wusste niemand mehr. Diese Festlegung verhinderte, dass die Verbesserung wirken konnte.

Nach gelöster Festlegung, Beobachtung und einer abgestimmten neuen Festlegung sank die mittlere Laufzeit der Funktion um 98,6 %, verglichen über Millionen Ausführungen. Am Anwendungscode wurde keine Zeile geändert. Den ganzen Fall beschreibt unsere Seite zur Performance-Optimierung.

Die Lehre für das Management: Auch eine frühere Lösung kann zum Risiko werden, wenn niemand sie dokumentiert und regelmäßig prüft. Nicht jeder Fall endet so deutlich. Der Weg ist aber immer derselbe: belegter Befund, abgestimmte Änderung, gemessene Wirkung.

Reparierbarer Fehler oder strukturelle Grenze?

Oft gibt es eine konkrete, behebbare Ursache: einen ungünstigen Ausführungsplan, einen fehlenden Index, eine Wartung zur falschen Zeit, eine blockierende Transaktion. Dann ist es ein Fehler, der sich reparieren lässt, und das sagen wir auch so.

Manchmal stößt eine Anwendung an eine strukturelle Grenze: Datenzugriffe wachsen nicht mit dem Datenbestand mit, Transaktionen halten gemeinsam genutzte Daten zu lange fest, oder die Last ist für den heutigen Aufbau zu hoch geworden. Dann hilft eine weitere Einzelkorrektur nur kurz.

Wir zeigen anhand von Belegen, was davon vorliegt. Akute Stabilisierung und strukturelle Änderung halten wir auseinander und nennen für jede Option Aufwand, Wirkung und verbleibendes Risiko. So entscheiden Sie auf einer klaren Grundlage statt nach dem nächsten Einbruch.

Was „stabil“ bedeutet

Drei Erwartungen werden häufig vermischt:

• Verfügbarkeit: Ist das System erreichbar, und funktioniert der Wiederanlauf nach einer Störung?
• Performance-Stabilität: Bleiben wichtige Geschäftsabläufe unter den erwarteten Bedingungen innerhalb ihrer Antwortzeitziele?
• Belastbarkeit: Wie viel gleichzeitige Arbeit trägt das System bei diesen Zielen?

Ein Server kann erreichbar sein und trotzdem für den Monatsabschluss zu langsam. Darum beginnt die Beurteilung beim Geschäftsvorgang: Was muss wie schnell funktionieren, in welchem Zeitfenster und bei welcher Last?

Warum das Monitoring grün sein kann, obwohl die Anwendung langsam ist

Eine gesunde VM, normale CPU-Mittelwerte und erfolgreiche Jobs sind wertvolle Signale. Ob ein wichtiger Geschäftsvorgang seine Antwortzeit einhält, beantworten sie nicht. Vorhandene Werkzeuge leisten dabei oft schon viel, wenn Monitoring, historische Daten und Ursachenklärung zusammenpassen. Regelmäßig sehen sollte die IT-Leitung:

• Antwortzeit der wichtigsten Abläufe, einschließlich der langsamen Ausreißer
• Anteil im Ziel: wie viele Aufrufe innerhalb des vereinbarten Ziels bleiben
• Veränderungen einzelner Abfragen und ihrer Ausführungswege
• Releases und Wartung mit Vorher-nachher-Vergleich
• Zeit bis zum Befund: wie lange es dauert, bis eine Ursache belegt ist
• Wirkung: welche Maßnahmen tatsächlich nachgemessen wurden

Was gemessen wird und welche Daten fehlen, gehört in denselben Bericht.

Wer was beeinflussen kann

Ein DBA schafft wesentliche Grundlagen: Konfiguration, Wartung, Diagnose und zuverlässigen Betrieb. Entwicklung oder Softwarehersteller prägen Datenzugriffe und Transaktionen. Infrastruktur und Cloudplattform setzen weitere Bedingungen. Damit Verantwortung nicht zwischen „Datenbank“, „Anwendung“ und „Hersteller“ liegen bleibt, trennen wir in unserer Arbeit drei Bereiche:

• Was wir selbst bearbeiten: Untersuchung, belegter Befund, freigegebene Änderungen an Datenbank und Konfiguration, jeweils mit Rückweg und Wirkungskontrolle.
• Wofür wir mit dem Hersteller zusammenarbeiten: Gehört der Anwendungscode einem Softwarehersteller, liefern wir einen nachvollziehbaren Befund mit Bedingungen, Auswirkung und Änderungsvorschlag. Nach einer Herstelleränderung prüfen wir, ob die Wirkung eintritt. Termine und Freigaben des Herstellers liegen bei ihm.
• Was Sie entscheiden: Priorität, Budget, akzeptierte Einschränkungen und das verbleibende Risiko. Wir legen dafür Optionen mit Aufwand und Folgen offen.

Auch ohne Zugriff auf den Anwendungscode lässt sich so viel erreichen. Das Praxisbeispiel oben ist ein solcher Fall.

Sieben Fragen an Ihr Team

Nutzen Sie die Fragen als Gesprächsgrundlage. Jede Antwort sollte sich mit einem konkreten Beispiel oder Beleg erklären lassen.

1. Welche drei Geschäftsabläufe dürfen nicht unbemerkt langsamer werden? Benennen Sie Prozess, Antwortzeitziel oder Zeitfenster und geschäftliche Auswirkung.
2. Kennen wir deren normales Verhalten zu Spitzenzeiten? Ordnen Sie Last, Datenvolumen und Vergleichszeitraum ein.
3. Haben wir historische Abfrage- und Plandaten, wenn ein Problem erst morgen gemeldet wird? Prüfen Sie den gespeicherten Zeitraum, die Abdeckung und bekannte Lücken.
4. Können wir nach einem Release Veränderungen belastbar vergleichen? Legen Sie Baseline und Prüfkriterium vor der Änderung fest.
5. Wer spricht mit dem Softwarehersteller, wenn die Ursache im Code liegt? Benennen Sie den Ansprechpartner und einen gemeinsam nachvollziehbaren Befund.
6. Wer entscheidet über kurzfristige Maßnahmen und deren Rücknahme? Klären Sie Eingriffsrechte, Freigabe, Rückweg und Wirkungskontrolle.
7. Wissen wir, welche wiederkehrenden Probleme den größten Geschäftsschaden erzeugen? Priorisieren Sie nach betroffenen Abläufen und Auswirkungen, nicht allein nach technischen Zählern.

Eine unklare Antwort zeigt zunächst eine Informations- oder Verantwortungslücke, kein persönliches Versagen. Wählen Sie die geschäftlich wichtigste Lücke und klären Sie sie zuerst. Eine gemeinsame Bestandsaufnahme dazu ist der Performance-Teil unseres Health Checks.

Welcher nächste Schritt passt?

Ein erster Auftrag hat bei uns eine klare Frage, einen vereinbarten Umfang und einen Entscheidungspunkt. Am Ende steht ein verwertbares Ergebnis: eine belegte Ursache, eine wirksame Maßnahme, ein konkreter Handlungsbedarf beim Hersteller oder die klare Aussage, welche Daten noch fehlen. Danach entscheiden Sie, wie es weitergeht.

• Belastbarer Ausgangspunkt: Ein SQL Server Health Check untersucht eine vereinbarte Fragestellung, benennt Belege und Grenzen und ordnet die nächsten Maßnahmen, auch wenn Ihr eigenes Team sie umsetzt.
• Konkreter Fall: Wir grenzen mit Ihnen ein, was sich verändert hat, und vereinbaren Analyse und Optimierung mit Wirkungskontrolle, für einzelne Abrufe auch als Beratungskontingent.
• Fortlaufende Betreuung: Mit PSG MX beobachten, untersuchen und verbessern wir die vereinbarte Anwendung und prüfen die Wirkung, Monat für Monat. Nur hier laufen unsere Werkzeuge dauerhaft mit, und sie sind genau für diese laufende Steuerung gebaut: MX AIOps erfasst Wartezeiten, Ressourcen, Jobs und Ereignisse fortlaufend vor Ort, PSG QX wertet die Ausführungshistorie im Query Store aus. So fallen Veränderungen auf, bevor Anwender sie melden, und die Wirkung jeder Maßnahme ist belegt. Beide laufen in Ihrer Umgebung und synchronisieren keine Daten in eine Public Cloud. Ziele, Zuständigkeiten und Umfang werden vorab festgelegt.

Für den Routinebetrieb passt die SQL-Server-Betreuung, für Wiederanlauf und Architektur Infrastruktur und Hochverfügbarkeit. Bei einem akuten Stillstand hilft die Akut-Hilfe.

Häufige Einwände

„Unsere Webserver laufen doch auch stabil.“

Die unbequeme Wahrheit zuerst: SQL wird nicht immer gleich ausgeführt. Auf einem Web- oder Application Server legt der Programmcode fest, welcher Weg durchlaufen wird; derselbe Aufruf nimmt denselben Weg. SQL beschreibt dagegen nur, welches Ergebnis gebraucht wird. Wie es ermittelt wird, entscheidet SQL Server erst zur Laufzeit, anhand von Statistiken, Parameterwerten und Datenverteilung. Dieselbe Abfrage kann deshalb morgen einen anderen Ausführungsplan bekommen und ein Vielfaches an Arbeit verursachen, ohne dass jemand eine Zeile Code geändert hat.

Hinzu kommt: Viele Anwendungsschichten verteilen Anfragen auf mehrere austauschbare Instanzen. Eine Datenbank hält dagegen meist den gemeinsam genutzten Datenbestand, koordiniert konkurrierende Änderungen und wählt ihre Ausführungswege anhand von Datenmenge und -verteilung. Mehr Backend-Instanzen nehmen zum Beispiel mehr Aufträge an. Wenn die zugehörigen Datenzugriffe aber lange dieselben Datensätze sperren, wächst die Warteschlange trotzdem. Das sind typische Architekturmerkmale, keine festen Regeln: Auch Backends können zum Engpass werden, und Datenbanken lassen sich skalieren.

„Seit der Wartung ist es langsamer.“

Ein wichtiger Hinweis, aber noch kein Ursachenbeweis. Statistikpflege, Indexänderungen und Upgrades können das Ausführungsverhalten beeinflussen; Wartung und Backups beanspruchen Ressourcen. Notwendige Wartung sollte deshalb nicht entfallen. Ihr Nutzen und ihre Nebenwirkungen gehören mit einem Vorher-nachher-Vergleich geprüft.

„Mehr CPU oder die Cloud bringen doch Ruhe.“

Zusätzliche Ressourcen können helfen. Sie können aber auch laufende Kosten erhöhen, ohne die eigentliche Ursache zu beseitigen. In der Cloud übernimmt der Anbieter je nach Dienst Teile des Plattformbetriebs; Datenzugriffe, Transaktionen und Antwortzeitziele bleiben Ihre Aufgabe. Eine Verfügbarkeitszusage ist keine Zusage, dass jeder Geschäftsablauf schnell genug ist.

„Der Health Check war doch gut.“

Dann lohnt die ehrliche Frage, was er tatsächlich geprüft hat. Wurden Konfiguration, Wartung und Best Practices zu einem Stichtag bewertet? Oder auch, ob die wichtigsten Geschäftsabläufe ihre Antwortzeiten einhalten, unter Spitzenlast und nach dem letzten Release? Das Erste ist eine wichtige Grundlage, beantwortet aber nicht die Frage nach der Performance-Stabilität. Und selbst ein guter Befund gilt nur für seinen Aussagezeitraum.

„Bei anderen Kunden läuft dieselbe Software schnell.“

Ein nützlicher Vergleich, wenn die Bedingungen bekannt sind: Datenmenge und -verteilung, Version, Erweiterungen, gleichzeitige Nutzung, Ressourcen und Konfiguration. Er beweist weder einen Fehler Ihres Betriebsteams noch, dass die Software unter allen Bedingungen trägt.

„Wäre eine andere Datenbank-Engine die Lösung?“

Für eine bestimmte Aufgabe kann eine andere Engine geeigneter sein. Das zeigt ein Vergleich Ihrer Geschäftsabläufe unter repräsentativen Bedingungen, einschließlich Portierung, Betrieb und Gesamtkosten. Problematische Zugriffsmuster und lange Transaktionen nimmt ein Wechsel meist mit.

Quellen

• Microsoft: Abfrageverarbeitung und Planwiederverwendung
• Microsoft: Skalierung und Engpässe in zustandsbehafteten Komponenten