SQL Server Health Check: Links, Ressourcen und Labs vom SQLDays 2026 Workshop

Vielen Dank an alle, die beim SQLDays Workshop in Erding dabei waren. Rund um den SQL Server Health Check haben wir uns gemeinsam durch ziemlich unterschiedliche Bereiche gearbeitet – von Installation und grundlegender Konfiguration über Betriebsübernahme und Recovery Readiness bis hin zu Health Checks, Blocking, Execution Plans und Query Store. Was mir dabei besonders gefallen hat: Es blieb eben nicht bei meinen vorbereiteten Slides und Demos. Viele Themen wurden erst durch eure Fragen und Erfahrungen aus echten Umgebungen richtig interessant.

Genau das ist für mich auch einer der großen Unterschiede zwischen einem Vortrag und einem Workshop. Man kann sich vorher sehr genau überlegen, was man zeigen möchte, aber die wirklich guten Diskussionen entstehen oft an den Stellen, an denen jemand aus dem Raum sagt: „Bei uns sieht das aber ganz anders aus“ oder „Was würdest du machen, wenn …?“. Einige dieser Fragen haben wir direkt im Workshop weiterverfolgt, andere sind mir danach im Kopf geblieben. Ein paar davon haben inzwischen sogar dazu geführt, dass die ursprünglichen Hands-on-Szenarien noch einmal deutlich erweitert wurden.

Was vom Workshop geblieben ist

Da wir in den einzelnen Slots natürlich nur begrenzt Zeit hatten und manche Themen locker einen eigenen Workshop füllen könnten, möchte ich hier die wichtigsten Links, Tools und weiterführenden Ressourcen noch einmal gesammelt bereitstellen. Dabei geht es mir ausdrücklich nicht um eine ultimative Best-Practice-Liste und auch nicht um den Anspruch, jedes Thema vollständig abzuhandeln. Vielmehr soll dieser Beitrag ein Ausgangspunkt sein, wenn ihr etwas aus dem Workshop später noch einmal nachlesen oder auf einer eigenen Testumgebung nachvollziehen möchtet.

Und weil diese Frage tatsächlich mehrfach kam: Ja, die Hands-on-Szenarien könnt ihr inzwischen selbst nachbauen. Ich wollte dafür allerdings nicht einfach ein ZIP mit ein paar SQL-Skripten hochladen, bei dem anschließend jeder mit einem anderen Ausgangszustand startet. Deshalb gibt es mittlerweile ein kleines reproduzierbares Lab auf GitHub, mit einer definierten Basisumgebung, einem gemeinsamen Setup und den vier Workshop-Szenarien.

TempDB: nicht nur die Anzahl der Dateien betrachten

TempDB ist eines dieser Themen, bei denen sich über die Jahre erstaunlich viele einfache Regeln festgesetzt haben. Vier Dateien, acht Dateien, eine Datei pro Core – fast jeder, der länger mit SQL Server arbeitet, hat irgendwann schon eine solche Empfehlung gehört. Das Problem ist weniger, dass diese Regeln grundsätzlich falsch wären. Schwieriger wird es dann, wenn sie aus ihrem ursprünglichen Kontext herausgelöst und wie eine universelle Wahrheit behandelt werden.

Was ich mir zuerst anschaue

Wenn ich mir eine unbekannte Umgebung anschaue, interessiert mich deshalb zunächst etwas anderes. Wie viele TempDB-Dateien gibt es heute überhaupt, sind sie gleich groß und verwenden sie dieselben Growth-Werte? Außerdem möchte ich wissen, wo sie physisch liegen und ob es auf diesem System überhaupt Hinweise darauf gibt, dass TempDB aktuell eine Rolle bei einem Performance-Problem spielt. Ein SQL Server mit zwei sauber konfigurierten TempDB-Dateien kann schließlich vollkommen unauffällig laufen, während acht Dateien auf demselben langsamen Volume noch lange keine gute Konfiguration ergeben.

Gleich große Data Files und ein bewusst gewähltes, festes Autogrowth sind für mich deshalb weiterhin ein sehr vernünftiger Ausgangspunkt, aber eben nur ein Ausgangspunkt. Gerade bei einem Health Check möchte ich vermeiden, dass aus „das entspricht nicht meiner bevorzugten Baseline“ automatisch „das ist ein Problem“ wird. Eine Abweichung ist zunächst einmal nur eine Beobachtung. Erst der Kontext entscheidet darüber, wie relevant sie wirklich ist – und genau diese Unterscheidung zieht sich eigentlich durch den gesamten Workshop.

Meine eigene grundsätzliche Herangehensweise an das Thema habe ich bereits im Beitrag Optimierung der TempDB für bessere Performance beschrieben. Zwei weitere Ressourcen, die ich zum Thema TempDB immer wieder gerne weitergebe, kommen von Brent Ozar:

• Frequently Asked Questions About TempDB
• Cheat Sheet: How to Configure TempDB for Microsoft SQL Server

Solche Übersichten finde ich gerade dann hilfreich, wenn man sich einem Thema neu nähert oder eine bestehende Konfiguration einmal gegen eine vernünftige Ausgangsbasis halten möchte. Ich würde sie allerdings nie ungeprüft als fertige Konfiguration übernehmen. Spätestens wenn reale Workloads, Storage, Virtualisierung und unterschiedliche SQL-Server-Versionen ins Spiel kommen, wird aus einer einfachen Regel sehr schnell eine individuelle Entscheidung.

Shrink Database: nicht als regelmäßige Wartung

Auch das ist ein Klassiker, der mir in gewachsenen Umgebungen immer wieder begegnet: Irgendwo existiert ein Job mit DBCC SHRINKDATABASE oder DBCC SHRINKFILE, der irgendwann einmal aus einem bestimmten Grund eingerichtet wurde und anschließend einfach jahrelang weitergelaufen ist. Oft weiß niemand mehr so genau, warum er überhaupt existiert – nur dass er „schon immer da war“.

Wann Shrink trotzdem sinnvoll sein kann

Ich halte Shrink nicht grundsätzlich für verboten. Wenn beispielsweise nach einer einmaligen Datenbereinigung dauerhaft sehr viel Speicherplatz nicht mehr benötigt wird, kann es vollkommen legitim sein, eine Datei bewusst zu verkleinern. Interessant wird es für mich allerdings immer dann, wenn Shrink als regelmäßige Wartungsaufgabe eingesetzt wird. Denn dann stellt sich automatisch die Frage, warum die Datenbank diesen Platz vorher überhaupt benötigt hat und ob sie ihn nicht kurze Zeit später wieder anfordern wird.

Genau an diesem Punkt wird aus einer scheinbar technischen Einstellung eine betriebliche Frage: Lösen wir mit dem Shrink tatsächlich ein Problem, oder behandeln wir nur regelmäßig dessen Symptom? Wenn eine Datei jede Woche wächst und anschließend jede Woche wieder verkleinert wird, lohnt es sich normalerweise deutlich mehr, zuerst zu verstehen, warum dieser Zyklus überhaupt entsteht. Deshalb taucht das Thema auch bewusst im Health-Check-Lab auf. Dort ist es kein „Fehler, den jeder sofort beheben muss“, sondern ein Finding, bei dem man nachfragen und verstehen sollte, wie dieser Zustand entstanden ist.

• What’s So Bad About Shrinking Databases with DBCC SHRINKDATABASE?
• What If You Really DO Need to Shrink a Database?

Gerade den zweiten Beitrag finde ich wichtig, weil er eben nicht in einem pauschalen „niemals machen“ endet. Es gibt legitime Fälle. Man sollte allerdings wissen, warum man es tut, welche Nebenwirkungen zu erwarten sind und ob der gewonnene Platz tatsächlich dauerhaft frei bleibt.

SQL Server Agent Operators und Alerts

Ein grüner Backup-Job fühlt sich erst einmal gut an, und genau deshalb passiert es meiner Erfahrung nach relativ schnell, dass man an dieser Stelle nicht mehr sehr viel weiterfragt. Bei einer Betriebsübernahme interessiert mich aber nicht nur, ob der Job gestern erfolgreich gelaufen ist. Mindestens genauso wichtig ist für mich die Frage, was heute Nacht passiert, wenn er eben nicht erfolgreich läuft – und vor allem, ob dann tatsächlich jemand davon erfährt, der auch etwas damit anfangen kann.

Die letzte Meile der Benachrichtigung

Deshalb schaue ich mir in solchen Umgebungen auch die eher unspektakulären Dinge an: Gibt es überhaupt einen Operator, funktioniert Database Mail und sind für die relevanten Jobs Notifications konfiguriert? Außerdem interessiert mich, ob irgendwann einmal jemand ausprobiert hat, ob eine solche Nachricht wirklich dort ankommt, wo sie ankommen soll. Gerade dieser letzte Punkt klingt banal, ist aber erstaunlich wichtig, denn eine sauber konfigurierte Benachrichtigungskette auf dem Papier hilft wenig, wenn sie im Fehlerfall niemanden erreicht.

Im Workshop war das deshalb bewusst ein Teil der Betriebsübernahme und nicht nur ein Nebenthema. Ein Server kann auf den ersten Blick sehr ordentlich aussehen, alle Jobs können grün sein und trotzdem fehlt am Ende genau die Information, die man braucht, wenn einmal etwas schiefläuft. Solche kleinen operativen Lücken sind es häufig, die erst im Ernstfall auffallen. Dann wirken sie plötzlich deutlich wichtiger als jede perfekt gesetzte Instanzoption.

Brent Ozar beschreibt die technische Einrichtung eines SQL Server Agent Operators hier sehr kompakt: How to Set Up a SQL Server Agent Operator. Das Einrichten selbst ist dabei eigentlich der einfache Teil. Interessanter wird für mich die Frage, ob aus dieser Konfiguration am Ende auch ein funktionierender betrieblicher Prozess wird.

Wait Statistics: Hinweise, keine fertigen Ursachen

Wait Statistics gehören zu den Dingen, die ich bei einer SQL-Server-Analyse sehr gerne verwende. Allerdings nicht deshalb, weil sie mir sofort eine fertige Antwort liefern würden, sondern weil sie häufig eine ziemlich gute Richtung vorgeben, in der ich weitersuchen kann. Genau deshalb bin ich auch vorsichtig, wenn aus einem auffälligen Wait Type unmittelbar eine Diagnose oder sogar schon eine konkrete Maßnahme abgeleitet wird. Ohne den zeitlichen und technischen Kontext sagt selbst ein sehr großer Wert oft weniger aus, als man zunächst vermutet.

Erst Kontext, dann Ursache

Mich interessiert deshalb immer auch, wie lange die Instanz bereits läuft, ob sich gerade eine ungewöhnliche Workload auf dem Server befindet und welche Requests aktiv sind. Gleichzeitig möchte ich wissen, ob das beobachtete Wait-Muster überhaupt zu dem passt, was die Anwender als Problem beschreiben. Ein hoher Wait Type kann ein sehr wertvoller Hinweis sein, aber häufig beginnt die eigentliche Analyse genau an dieser Stelle erst. Manchmal stellt sich beim weiteren Hinschauen sogar heraus, dass der zunächst auffälligste Wait mit dem aktuellen Problem gar nicht besonders viel zu tun hat.

Das ist für mich generell ein schönes Beispiel dafür, warum ich Health Checks und Troubleshooting gedanklich voneinander trenne. Bei einem Health Check können Wait Statistics helfen, Auffälligkeiten oder langfristige Muster zu erkennen. Wenn dagegen gerade ein konkretes Performance-Problem besteht, möchte ich viel stärker verstehen, was in genau diesem Moment passiert und welche Session, Query oder Ressource tatsächlich beteiligt ist.

Auf SQL aus Hamburg habe ich diese Sichtweise im Beitrag Sind Wait-Types im SQL Server ein Schlüssel zur Performance? ausführlicher beschrieben. Wenn ich während einer Analyse einen Wait Type sehe, den ich nicht sofort einordnen kann oder bei dem ich noch einmal Details nachlesen möchte, lande ich außerdem seit Jahren regelmäßig bei der SQL Server Wait Types Library von SQLskills. Als weiterführende Einführung ist auch SQL Server Performance Tuning Using Wait Statistics sehr lesenswert.

Maintenance: Ola Hallengrens SQL Server Maintenance Solution

Ola Hallengrens SQL Server Maintenance Solution dürfte vielen aus der Community längst bekannt sein. Für Backups, Integrity Checks sowie Index- und Statistics Maintenance ist sie für mich weiterhin eine der Ressourcen, die man zumindest kennen sollte. Gerade weil sie seit vielen Jahren in sehr unterschiedlichen Umgebungen eingesetzt wird, nimmt sie eine Menge Arbeit ab, die man sonst selbst skripten und pflegen müsste.

• Ola Hallengren – SQL Server Maintenance Solution
• Downloads

Das Tool ist noch nicht die Strategie

Was ich dabei im Workshop wichtig fand: Nur weil dieses Framework installiert ist, ist die Umgebung noch nicht automatisch gut gewartet. Die eigentlich spannenden Fragen kommen erst danach. Ein vorhandener Backup-Job sagt schließlich noch nichts darüber aus, ob die Backup-Strategie zu den fachlichen Anforderungen passt. Ebenso wenig wissen wir dadurch, ob die Aufbewahrung sinnvoll gewählt wurde oder ob im Ernstfall überhaupt bekannt ist, welche Backups für einen Restore benötigt werden.

Dasselbe gilt für CHECKDB, Index Maintenance oder Statistics Updates. Wann laufen die Jobs, wie lange brauchen sie und überschneiden sie sich vielleicht mit anderen Wartungsfenstern? Außerdem sollte man sich fragen, ob die gewählten Parameter überhaupt zur Umgebung passen. Das Tool kann uns sehr viel Arbeit abnehmen. Die Verantwortung dafür, ob die Strategie sinnvoll ist, nimmt es uns natürlich trotzdem nicht ab.

dbatools: SQL Server Administration automatisieren

Eine Frage aus dem Raum fand ich besonders praktisch: Wie dokumentiert man eigentlich eine bestehende SQL-Server-Instanz so, dass man ihre Konfiguration später für Migration, Disaster Recovery oder einfach zur Dokumentation wiederverwenden kann? Gerade bei älteren oder gewachsenen Umgebungen steckt häufig erstaunlich viel Wissen ausschließlich in der laufenden Instanz. Logins, Jobs, Operatoren, Credentials, Linked Servers und viele andere Dinge sind vorhanden, aber nirgends sauber dokumentiert.

Genau an solchen Stellen lohnt sich deshalb ein Blick auf dbatools. Damit lassen sich viele dieser Aufgaben sehr viel pragmatischer lösen, als wenn man jedes einzelne Objekt von Hand zusammensucht.

• dbatools – Getting Started
• Export-DbaInstance

Von „müssten wir mal“ zu wirklich dokumentiert

Ein einfacher Einstieg sieht beispielsweise so aus:

Export-DbaInstance -SqlInstance SQLSERVER01

Damit lassen sich große Teile einer SQL-Server-Instanz als T-SQL-Skripte exportieren, zum Beispiel Logins, SQL-Agent-Objekte, Database Mail, Credentials und weitere Konfigurationsbestandteile. Für Migrationen oder DR-Vorbereitung ist das natürlich hilfreich. Gleichzeitig mag ich solche Werkzeuge aber auch deshalb, weil sie aus „das müssten wir eigentlich einmal dokumentieren“ etwas machen, das man mit überschaubarem Aufwand tatsächlich tun kann.

Wenn solche Exporte anschließend geteilt, archiviert oder in Git gespeichert werden, sollte man vorher natürlich noch einmal genau prüfen, welche sicherheitsrelevanten Informationen darin enthalten sind. Gerade bei Logins, Credentials oder Verbindungskonfigurationen möchte man schließlich nicht versehentlich mehr veröffentlichen, als ursprünglich beabsichtigt war.

SQL Server Health Check: die Hands-on-Szenarien zum Nachbauen

Nach dem Workshop war mir relativ schnell klar, dass ich die Übungen nicht einfach als ein paar lose SQL-Dateien irgendwo ablegen möchte. Wenn ihr das später noch einmal auf einer eigenen Testinstanz ausprobiert, sollte möglichst derselbe Ausgangszustand entstehen wie im Workshop. Sonst verbringt man am Ende mehr Zeit damit, Unterschiede zwischen zwei Testumgebungen zu erklären, als mit dem eigentlichen Thema.

Warum mir ein definierter Ausgangszustand wichtig war

Deshalb habe ich die vier Szenarien inzwischen als kleines reproduzierbares Lab auf GitHub aufbereitet. Das Repository installiert bewusst keine komplette VM und baut auch keine Windows-Infrastruktur auf. Stattdessen setzt es eine klar definierte Basisumgebung voraus und kümmert sich anschließend darum, innerhalb von SQL Server einen reproduzierbaren Ausgangszustand herzustellen.

SQL Server Health Check Lab auf GitHub

Im Repository findet ihr die vier Perspektiven wieder, die wir auch im Workshop verwendet haben:

1. Build / Setup Review
   Ein installierter SQL Server läuft – aber würden wir ihn so wirklich in Betrieb nehmen?
2. Take Ownership / Recovery Readiness
   Was muss ich wissen, bevor ich für eine bestehende Umgebung Verantwortung übernehme?
3. Health Check / Assess, Don’t Assume
   Welche Findings sind wirklich relevant und welche sehen nur auf den ersten Blick ungewöhnlich aus?
4. Troubleshooting / Diagnose unter Druck
   Was passiert, wenn aus einem allgemeinen „SQL ist langsam“ eine konkrete Untersuchung werden muss?

Selbst analysieren statt die Lösung zu kopieren

Für alle Szenarien gibt es ein gemeinsames Setup und eine Validierung. Dadurch kann man vor dem eigentlichen Lab sehen, ob die erwartete Ausgangslage tatsächlich vorhanden ist. Anschließend lässt sich jedes Szenario gezielt erzeugen, untersuchen und wieder zurücksetzen, ohne dass man die komplette Testumgebung jedes Mal neu bauen muss.

Mir war dabei außerdem wichtig, die Lösungen getrennt von den eigentlichen Aufgaben abzulegen. Wer möchte, kann also erst einmal wirklich selbst analysieren und überlegen, welche Findings relevant sind, bevor er später in die Auflösung schaut. Gerade bei Health Checks und Troubleshooting finde ich diesen Teil deutlich wertvoller als ein Skript, das einem sofort sagt, welche Zeile „falsch“ ist.

Blocking, Execution Plans und Missing Index

Gerade Slot 4 hat mich nach dem Workshop noch ein bisschen weiter beschäftigt, wahrscheinlich auch deshalb, weil dort einige der interessantesten Rückfragen aus der Gruppe kamen. Das ursprüngliche Blocking-Szenario ist weiterhin enthalten: Eine offene Transaktion hält Locks, eine zweite Session wartet. Genau an dieser Stelle passiert im Alltag schnell etwas sehr Menschliches, denn man schaut zuerst auf die Session, die gerade hängt und sichtbar Probleme macht.

Die spannendere Frage ist aber oft nicht, warum diese Session wartet, sondern wer sie eigentlich aufhält und warum die blockierende Transaktion überhaupt noch offen ist. Im Lab lässt sich das bewusst mit mehreren SSMS-Sessions nachvollziehen. Dadurch sieht man nicht nur einen Screenshot eines Blocking Trees, sondern kann selbst beobachten, wie sich die Situation aufbaut, wie sie in den DMVs erscheint und was passiert, wenn die blockierende Transaktion schließlich beendet wird.

Wer sich mit solchen Situationen noch etwas tiefer beschäftigen möchte, findet im Beitrag SQL Server: Warum läuft meine Abfrage plötzlich langsam? unter anderem Blocking, offene Transaktionen, veränderte Ausführungspläne, IO, Statistiken und weitere typische Ursachen.

Vom Plan-Hinweis zur überprüfbaren Hypothese

Zusätzlich habe ich den Execution-Plan-Teil nach dem Workshop noch deutlich erweitert. Eine größere Beispieltabelle wird zunächst mit einem passenden Supporting Index abgefragt. Danach wird dieser Index entfernt und exakt dieselbe Query erneut ausgeführt. Dadurch lässt sich sehr schön nachvollziehen, wie sich der Execution Plan verändert, was mit den Logical Reads passiert und wie Query Store dabei hilft, den früheren und den aktuellen Zustand nebeneinander zu sehen.

Außerdem taucht dabei eine reproduzierbare Missing-Index-Empfehlung auf. Die ist im Lab ganz bewusst kein „hier klicken und fertig“-Moment, sondern eher der Beginn der nächsten Überlegung. Warum schlägt der Optimizer genau diesen Index vor, welche Spalten gehören in den Key und welche möglicherweise nur in INCLUDE? Gleichzeitig stellt sich die Frage, ob schon ähnliche Indizes existieren und was ein zusätzlicher Index für Schreibvorgänge und Wartung bedeutet.

Genau das ist für mich der interessantere Teil an Execution Plans. Natürlich möchte ich erkennen können, ob ein Scan oder Seek verwendet wird, wie Estimated und Actual Rows aussehen oder an welcher Stelle die meisten Reads entstehen. Wirklich hilfreich wird der Plan aber erst dann, wenn man daraus eine Hypothese ableiten kann. Anschließend lässt sich überprüfen, ob eine Änderung die Situation tatsächlich verbessert.

Kleines Add-on aus der Diskussion: Query Store Hints

Auch dieses kleine Add-on wäre ohne eine Frage aus dem Workshop wahrscheinlich gar nicht entstanden. Sinngemäß ging es darum, was man machen kann, wenn eine problematische Query bekannt ist, der Anwendungscode aber nicht kurzfristig geändert werden kann. Gleichzeitig möchte man dieser Query beispielsweise einen Hint mitgeben.

Seit SQL Server 2022 können dafür Query Store Hints verwendet werden. Das Spannende daran ist, dass der ursprüngliche SQL-Text der Anwendung unverändert bleibt. Der zusätzliche Hint wird stattdessen über die bereits bekannte query_id im Query Store zugeordnet.

Im Lab wird beispielsweise gezeigt, wie sich einer bekannten Query ein MAXDOP-Hint zuweisen lässt:

EXEC sys.sp_query_store_set_hints
    @query_id = @QueryId,
    @query_hints = N'OPTION(MAXDOP 2)';

Ich finde das gerade als Demo spannend, weil man daran sehr gut sieht, dass Query Store eben nicht nur ein Ort für historische Laufzeitdaten und alte Pläne ist. In bestimmten Situationen lässt sich damit auch gezielt Einfluss auf das Optimierungsverhalten einer einzelnen Query nehmen, ohne dass dafür sofort der Anwendungscode geändert werden muss.

Natürlich ist auch das kein Werkzeug, das man einfach blind auf jede langsame Query werfen sollte. Der eigentliche Wert liegt für mich darin, dass man zunächst einen konkreten Grund für die Maßnahme hat. Anschließend lässt sich überprüfen, wie sich die Query unter dem Hint verhält. Wenn er nicht mehr benötigt wird, kann der Eingriff genauso kontrolliert wieder entfernt werden.

Wie Query Store dabei helfen kann, von einem allgemeinen Performance-Signal zu konkreten Queries und historischen Plänen zu kommen, beschreibe ich auch im Beitrag Monitoring ist nicht Diagnose: Warum SQL-Server-Alarme nur der Anfang sind. Und weil so etwas im Lab nicht einfach „liegen bleiben“ sollte, gehört zur Demo natürlich auch das anschließende Entfernen des Hints. Gerade bei Performance-Maßnahmen finde ich es wichtig, dass Änderungen nicht nur funktionieren, sondern auch nachvollziehbar und reversibel bleiben.

Was mir beim SQL Server Health Check wichtig ist

Wenn ich nach dem Workshop noch einmal darüber nachdenke, zieht sich eigentlich eine Sache durch alle vier Blöcke: Wir sehen bei SQL Server ständig Werte, Warnungen, Job-Historien, Wait Types, Execution Plans, Backup-Historien oder Empfehlungen. Natürlich brauchen wir all diese Informationen. Schwierig wird es für mich immer dann, wenn aus einem einzelnen Wert zu schnell eine fertige Antwort entsteht, obwohl die eigentliche Umgebung noch gar nicht verstanden wurde.

Wann aus einem Finding wirklich ein Risiko wird

Ein MAXDOP von 0 kann auffällig sein, aber ich möchte wissen, auf welcher Hardware ich mich befinde und welche Workload dort läuft. Eine Datenbank im FULL Recovery Model ohne Log Backups ist deutlich interessanter. Allerdings möchte ich auch wissen, welches RPO überhaupt erwartet wird. Ein hoher Wait Type kann ebenfalls auf ein reales Problem hinweisen. Genauso gut kann er aber das Ergebnis einer Instanz sein, die seit Monaten ohne Neustart läuft und deren gesamte Historie in einem einzigen Zähler steckt.

Dasselbe gilt für eine wartende Session, eine Missing-Index-Empfehlung oder einen grünen SQL-Agent-Job. Alles davon kann wichtig sein, aber fast immer möchte ich noch mindestens eine oder zwei Fragen stellen, bevor ich daraus eine Maßnahme ableite. Vielleicht ist das auch der Teil an solchen Analysen, den ich persönlich am spannendsten finde: nicht das Finden einer roten Einstellung, sondern der Moment, in dem mehrere kleine Beobachtungen plötzlich zusammenpassen. Denn genau dann beginnt man zu verstehen, was in dieser Umgebung wirklich passiert.

Warum ich daraus keine reine Checkliste machen möchte

Genau deshalb wollte ich im Workshop auch nicht einfach vier Stunden lang eine Checkliste abarbeiten. Natürlich gibt es Dinge, die ich auf fast jedem SQL Server prüfe, und selbstverständlich habe ich meine eigenen Baselines und Erwartungen. Entscheidend ist für mich aber, dass aus diesen technischen Checks irgendwann eine Bewertung entsteht, die zum jeweiligen System passt. Denn eine Einstellung ist nicht automatisch schlecht, nur weil sie anders aussieht als auf meinem letzten Server.

Gleichzeitig darf „es läuft doch“ natürlich auch nicht das einzige Qualitätskriterium sein. Genau zwischen diesen beiden Extremen liegt für mich die eigentliche Arbeit eines guten Health Checks. Und genau an diesem Punkt fand ich eure Rückfragen besonders wertvoll. Einige davon haben Themen geöffnet, die in meinen ursprünglichen Slides nur am Rand vorkamen, während andere bestätigt haben, dass bestimmte Probleme eben nicht nur in einer einzigen Kundenumgebung existieren.

Was ich aus Erding mitnehme

Gerade diese Mischung aus vorbereiteten Inhalten und Erfahrungen aus dem Raum hat den Workshop für mich deutlich interessanter gemacht, als es eine reine Abfolge von Slides und Demos gewesen wäre. Gleichzeitig hat sie mir noch einmal gezeigt, dass wir in der SQL-Server-Community zwar oft mit sehr unterschiedlichen Umgebungen arbeiten, am Ende aber erstaunlich häufig über dieselben grundlegenden Fragen stolpern.

Noch einmal ein großes Dankeschön an alle, die in Erding dabei waren – fürs Zuhören, Nachfragen, Widersprechen, Ergänzen und natürlich auch für die Gespräche zwischendurch. Ich hatte bei der Vorbereitung eine ziemlich genaue Vorstellung davon, was ich in den vier Workshop-Blöcken zeigen möchte. Am Ende sind bei mir aber gerade die Stellen hängen geblieben, an denen wir gemeinsam ein bisschen tiefer gegangen sind oder jemand aus dem Raum noch eine zusätzliche Perspektive eingebracht hat.

Einige Ergänzungen im veröffentlichten Lab, gerade rund um Execution Plans und Query Store Hints, sind genau daraus entstanden. Deshalb gehe ich auch nicht davon aus, dass das Repository damit „fertig für immer“ ist. Wenn beim Nachbauen Fragen auftauchen oder sich auf anderen Testumgebungen interessante Unterschiede zeigen, ist das für mich eher ein Grund, das Lab weiterzuentwickeln als ein Problem.

Wenn ihr die Szenarien ausprobiert und dabei über etwas stolpert, wenn sich ein Lab auf eurer Testinstanz anders verhält oder euch irgendwo eine Erklärung fehlt, schreibt es gerne als Issue ins GitHub-Repository. Ich freue mich genauso über Hinweise, Verbesserungen oder Ideen für weitere Szenarien. Und wenn daraus die nächste gute Diskussion entsteht, umso besser – schließlich lebt unsere SQL-Server-Community genau davon, dass wir Erfahrungen nicht nur sammeln, sondern miteinander teilen.

Foto von Rob Dean auf Unsplash