Schnellcheck eines SQL Servers: Werkzeugkasten für Entwickler, die bei neuen Kunden Boden gewinnen wollen

Von /

Der Anruf kommt selten gut verpackt. „Können Sie mal kurz in unseren SQL Server schauen?“ Manchmal ist es ein Entwickler-Kollege, der ein Projekt abgibt. Manchmal ein Geschäftsführer, dessen alter IT-Partner aus der Firma raus ist. Manchmal ein Bestandskunde, bei dem man ohnehin gerade eine Stored Procedure anfasst und dabei merkt: Da liegt mehr im Argen, als der Auftrag vermuten lässt.

Die gemeinsame Frage in diesen Situationen lautet: Auf welchem Boden stehe ich hier eigentlich?

Genau dafür gibt es einen Werkzeugkasten, der in der SQL-Server-Welt de facto Standard ist. Wer ihn beherrscht, liefert innerhalb einer Stunde einen belastbaren Erstbefund. Wer ihn nicht kennt, fängt jedes Mal bei Null an und findet vieles gar nicht. Dieser Beitrag zeigt beides: das Vorgehen und die Tools.

Warum überhaupt ein Schnellcheck?

Ein SQL Server läuft meistens. Das ist das Problem. Solange täglich Buchungen erfasst und Rechnungen gedruckt werden, merkt niemand, dass PAGE_VERIFY auf NONE steht, Backups vielleicht laufen — aber nie getestet wurden — und der letzte Cumulative Update aus einer Zeit stammt, in der Corona noch Neuland war.

Das ist keine Theorie. Ich habe diese Woche in einem Kundensystem festgestellt, dass sechs produktive Diamant-Datenbanken seit Jahren ohne Seitenprüfsumme laufen. Kein akuter Schaden, aber ein stiller Risikoposten, den niemand auf dem Radar hatte — weil niemand danach gefragt hatte.

Ein Entwickler, der neu auf ein System kommt, hat die seltene Gelegenheit, genau solche Posten zu finden, bevor sie zu Vorfällen werden. Nicht als Audit-Dienstleistung, sondern beiläufig: als Nebenprodukt dessen, dass man sich mit dem System vertraut macht. Entscheidend ist, dass dieser Check strukturiert abläuft und nicht jedes Mal neu erfunden wird.

Praktisches Vorgehen beim neuen Kunden

Das folgende Vorgehen hat sich als wiederholbarer Prozess bewährt. Die Reihenfolge ist wichtig — sie schützt den Kunden vor überstürzten Eingriffen und den Entwickler vor Haftungsrisiken.

Schritt 1: Vorab-Checkliste an den Kunden

Bevor man sich einloggt, wird geklärt: Welche Instanzen laufen? Welche Datenbanken sind produktiv, welche Test? Welche Edition (Standard, Enterprise, Developer)? Gibt es Wartungsfenster? Wer ist für Backups verantwortlich? Existiert ein Monitoring? Welche Zugänge bekommt man — und welche nicht?

Das sind Fragen an die IT-Leitung, nicht an den SQL Server. Sie verhindern Missverständnisse und sind oft schon diagnostisch: Ein Kunde, der auf die Backup-Frage mit „das macht irgendwie der Server selbst“ antwortet, hat mit hoher Wahrscheinlichkeit weder eine getestete Restore-Strategie noch einen sauberen Wartungsplan.

Schritt 2: Read-only-Check, nichts anfassen

Die gesamte Erstaufnahme läuft ausschließlich lesend. Keine Änderungen an Konfiguration, an Datenbanken, an Jobs. Nicht, weil es technisch gefährlich wäre — sp_Blitz ist harmlos —, sondern weil es eine saubere Rollen-Regel ist: Als externer Entwickler ändert man nichts ohne schriftliche Freigabe. Das schützt vor der Situation, in der nach einer Umstellung irgendetwas nicht mehr funktioniert und alle Augen auf den Externen zeigen.

Gleichzeitig liegt in der Read-only-Beschränkung die Stärke des Ansatzes: Der Befund ist reine Beobachtung, kein Eingriff. Er lässt sich dem Kunden sauber präsentieren, ohne dass man sich rechtfertigen muss, warum man an Einstellung X gedreht hat.

Schritt 3: Befund zusammenfassen und priorisieren

Die Ausgabe der Tools ist technisch und umfangreich. Eine sp_Blitz-Tabelle mit 80 Findings ist für die IT-Leitung unlesbar. Entscheidend ist die Übersetzung: Man sortiert die Findings nach drei Kategorien — „Sofort klären“, „Mittelfristig angehen“, „Nice to have“ — und schreibt zu jedem Kernbefund zwei bis drei Sätze in Prosa. Welche Datenbanken betroffen sind. Was das praktisch bedeutet. Was der nächste Schritt wäre.

Diese Übersetzungsleistung ist der eigentliche Wert des Schnellchecks. Die Tools findet jeder. Den Befund in eine IT-Leitungs-taugliche Zusammenfassung bringen — das unterscheidet den erfahrenen Berater vom Scriptausführer.

Schritt 4: Mit der IT-Leitung besprechen

Der Befund geht an die interne Verantwortung zurück. Nicht als Liste von Vorwürfen, sondern als gemeinsame Entscheidungsgrundlage. Was wird angefasst? Was bleibt liegen? Was gehört zum Hersteller-Support des ERP-Systems? Wer setzt um — interne IT, Dienstleister, externer Entwickler?

Wichtig: Der Befund dokumentiert den Zustand zum Zeitpunkt der Aufnahme. Wenn der Kunde sich entscheidet, Finding Y nicht anzufassen, ist das eine legitime Entscheidung — solange sie dokumentiert ist.

Schritt 5: Baseline dokumentieren

Der Befund wird abgelegt, idealerweise mit Datum, Instanzname, Build-Stand und den rohen Tool-Ausgaben. Sechs Monate später kann man damit belegen, was sich verbessert hat und was nicht. Diese Baseline ist auch intern nützlich: Wenn in zwei Jahren ein Vorfall passiert, weiß man, was bereits bei Übernahme bekannt war.

Die Pflicht-Werkzeuge beim Erstcheck

Drei Tools reichen für 90 Prozent der Fälle. Alle drei sind kostenlos, open source, seit Jahren gepflegt und im Community-Konsens etabliert.

Definition: First Responder Kit

Das First Responder Kit ist eine frei verfügbare Sammlung von Stored Procedures für SQL-Server-Health-Checks und Performance-Analyse, gepflegt von Brent Ozar Unlimited unter MIT-Lizenz.

Werkzeug 1: First Responder Kit (Brent Ozar)

Das First Responder Kit — kurz FRK — ist der Kern des Werkzeugkastens. Es besteht aus rund einem Dutzend Prozeduren, von denen drei für den Erstcheck genügen:

sp_Blitz für einen Gesamt-Health-Check der Instanz, sp_BlitzCache für die Top-Ressourcenfresser aus dem Plan Cache und sp_BlitzIndex für eine Index-Bewertung pro Datenbank. sp_BlitzFirst ergänzt das, wenn man wissen will, was in einem konkreten Moment gerade passiert, und sp_BlitzWho ist eine bessere Variante des bekannten sp_who2.

Die Installation ist unspektakulär: Die aktuelle Release-ZIP von GitHub herunterladen und die SQL-Dateien in der master-Datenbank ausführen — alternativ in einer eigenen Utility-Datenbank, wenn der Kunde das bevorzugt. Wer PowerShell ohnehin einsetzt, installiert über Install-DbaFirstResponderKit aus dem dbatools-Modul in einem Rutsch.

Der Lauf selbst ist ein einziger EXEC sp_Blitz;. Das Ergebnis ist eine Tabelle mit Priorität (1 = kritisch, 255 = Info), Finding-Beschreibung, betroffener Datenbank und einem Link auf die Dokumentationsseite zum jeweiligen Thema. Unter den Dingen, die sp_Blitz regelmäßig findet: PAGE_VERIFY abweichend von CHECKSUM, Datenbanken ohne aktuelles Backup oder Log-Backup, aktiviertes Auto-Shrink, fehlende SQL-Agent-Alerts für Severity 17–25 und Error 823/824/825, veralteter CU-Stand, Datenbanken im Recovery Model FULL ohne Log-Backup-Strategie, Max Server Memory auf Default, problematische TempDB-Konfiguration, Security-Themen wie aktiver sa-Account oder BUILTIN\Administrators als sysadmin.

Das FRK wird quartalsweise aktualisiert und hat in den letzten Jahren nochmal an Tempo zugelegt — die aktuellen Versionen bieten inzwischen optionale AI-Integration in sp_BlitzCache und sp_BlitzIndex, mit der man zu einem konkreten Query-Plan oder einer Tabellen-Index-Situation direkt LLM-Rat abrufen kann. Für den Erstcheck ist das eher ein Nice-to-have — die klassischen Regeln tragen für sich.

Eine Einschränkung: Für Azure SQL Database ist das FRK nicht vollumfänglich supported, weil Microsoft dort DMVs ohne Vorwarnung ändert. Auf Windows- und Linux-SQL-Server sowie Amazon RDS läuft es sauber.

Werkzeug 2: Ola Hallengren Maintenance Solution

Das zweite Pflicht-Werkzeug ist eigentlich kein Analyse-Tool, sondern ein Wartungsframework — gehört aber zu jedem Erstcheck, weil sein Fehlen oder Vorhandensein selbst schon ein Befund ist.

Ola Hallengrens „SQL Server Maintenance Solution“ ist seit vielen Jahren der De-facto-Standard für Backups, Integrity-Checks (DBCC CHECKDB) und Index-Maintenance auf SQL Server. Die Lösung besteht aus einer Handvoll Stored Procedures und vorkonfigurierten SQL-Agent-Jobs, die den kompletten Wartungszyklus abdecken.

Beim neuen Kunden stellt sich also zuerst die Frage: Ist das System installiert? Auf produktiven Instanzen ohne Ola-Framework läuft Wartung entweder gar nicht, mit Bordmitteln (Wartungspläne aus SSMS, oft suboptimal konfiguriert) oder mit eigenen Skripten, die niemand mehr pflegt. In allen drei Fällen ist die Empfehlung dieselbe: Installation vorschlagen, Umsetzung mit der IT-Leitung abstimmen.

Wenn Ola bereits installiert ist, prüft man die Job-Historie: Laufen Backups tatsächlich täglich durch? Wie oft läuft DBCC CHECKDB, über welche Datenbanken? Welche Fehler sind in der History gelaufen, ohne dass jemand reagiert hat? Die Tabelle dbo.CommandLog in der Utility-Datenbank gibt darüber Auskunft — ein kurzer Blick reicht.

Werkzeug 3: sp_WhoIsActive (Adam Machanic)

Das dritte Pflicht-Tool ist ein Einzel-Prozedur-Download. sp_WhoIsActive von Adam Machanic liefert das, was sp_who2 hätte sein sollen: eine brauchbare Übersicht über aktive Sessions, mit ihrem aktuellen Query-Text, Wait Stats, Blocking-Hierarchie und Ressourcenverbrauch in einer einzigen übersichtlichen Resultset-Zeile pro Session.

Im Erstcheck ist sp_WhoIsActive weniger zentral als sp_Blitz, weil es den Ist-Zustand eines Moments zeigt, nicht die strukturellen Befunde. Man braucht es aber spätestens dann, wenn der Kunde sagt: „Manchmal ist das System plötzlich sehr langsam.“ Dann läuft sp_WhoIsActive im Hintergrund, während der Vorfall passiert — und zeigt, was gerade blockiert.

Viele Entwickler haben sp_WhoIsActive ohnehin in ihrer persönlichen Werkzeugsammlung. Es ergänzt sp_BlitzWho und sp_BlitzFirst aus dem FRK; beide Tools haben leicht unterschiedliche Stärken, und die meisten DBAs nutzen sie parallel.

Werkzeuge bei Bedarf

Für spezifische Fragestellungen jenseits des klassischen Erstchecks gibt es weitere etablierte Tools, die man im Hinterkopf haben sollte:

sp_HumanEvents (Erik Darling) — Extended-Events-Abfragen für Menschen. Wenn man Query-Profiling oder Deadlock-Analyse machen will, ohne sich durch XE-XML zu quälen, ist das die pragmatische Abkürzung.

DBATools (PowerShell-Modul) — rund 700 PowerShell-Funktionen für SQL-Server-Automatisierung, kostenlos und community-basiert. Der Einstieg ist steiler als bei den anderen Tools, aber unschlagbar bei Multi-Instance-Szenarien: Migrationen, Backup-Tests über mehrere Server, Vergleichs-Assessments. Wer FRK oder Ola installieren will, kann das über DBATools mit einem einzigen Befehl auf beliebig vielen Instanzen ausrollen.

Microsoft SQL Assessment API / Best Practices Assessment — Microsofts offizielles Gegenstück zu sp_Blitz, verfügbar über Azure Data Studio und PowerShell. Deckt sich teilweise mit dem FRK, hat aber eigene Regeln. Für Kunden, die Wert auf „offizielle Microsoft-Tools“ legen, eine gute Ergänzung.

Azure Data Studio + Notebooks — für Kunden, bei denen man den Befund direkt als reproduzierbares Notebook ablegen will.

Wo der Ansatz an Grenzen stößt

Ein Schnellcheck ist ein Schnellcheck. Er ersetzt weder ein vollständiges Security-Audit nach ISO 27001, noch eine professionelle Performance-Analyse unter Last, noch einen formalen Disaster-Recovery-Test. Der FRK findet viele strukturelle Themen, aber er sieht nicht in den Code der Stored Procedures und bewertet keine Datenmodell-Qualität. Ola-Jobs laufen nicht automatisch korrekt, nur weil sie installiert sind — die Konfiguration will geprüft sein.

Außerdem gilt: Die Tools melden, was sie finden. Sie ersetzen keine Interpretation. Ein Finding „PAGE_VERIFY = NONE“ ist dieselbe technische Tatsache bei einer ERP-Datenbank wie bei einer Test-Instanz — die Tragweite ist komplett verschieden. Genau deshalb steht oben im Prozess Schritt 3: Befund zusammenfassen und priorisieren. Das kann kein Tool.

Unterstützung

Wer Unterstützung bei der Umsetzung dieses Vorgehens sucht — bei der Interpretation der Befunde, beim Gespräch mit der IT-Leitung oder bei der Reparatur dessen, was der Check zutage gefördert hat — erreicht mich als Datenschäfer über sesoft.de/kontakt. Besonders dort, wo es um ältere On-Premise-Umgebungen, gewachsene Buchhaltungs- oder ERP-Datenbanken und die typischen stillen Risikoposten in norddeutschen Mittelständlern geht, lohnt sich oft ein zweiter Blick von außen.

Quellen

Ähnliche Beiträge

Nach oben scrollen