Ein Werkzeugkasten von Brent Ozar, der dir in zehn Minuten zeigt, was dein SQL Server tatsächlich tut — und wo Hallengren weitermacht
Du hast deine Access-Anwendung auf SQL Server umgehoben. Vielleicht teilweise, vielleicht komplett. Tabellen liegen jetzt im Backend, das Frontend greift per ODBC zu, ein paar Sichten und Prozeduren sind dazugekommen. Der Server läuft. Aber wenn dich jemand fragt, wie er läuft — welche Abfragen den meisten Schaden anrichten, ob Indizes sinnvoll gesetzt sind, was die Datenbank gerade tatsächlich tut — dann zuckst du mit den Schultern. Kein Vorwurf. SQL Server zeigt einem das alles, aber er zeigt es nicht freiwillig.
An dieser Stelle kommt das First Responder Kit ins Spiel: eine Sammlung kostenloser T-SQL-Skripte von Brent Ozar und über 190 weiteren Beitragenden, die genau diese Antworten in lesbare Tabellen gießen. Keine Installation, keine Lizenz, kein Agent — einfach SQL-Dateien, die du in der master-Datenbank ausführst.
Was beantworten die Skripte?
Das Kit besteht im Kern aus einer Handvoll Stored Procedures, die jeweils eine konkrete Frage beantworten:
sp_Blitz— „Wie geht es meinem Server insgesamt?“ Liefert eine nach Dringlichkeit sortierte Mängelliste: fehlende Backups, gefährliche Konfigurationen, ungewöhnliche Einstellungen, Sicherheitsthemen.sp_BlitzFirst— „Warum ist der Server gerade jetzt langsam?“ Nimmt fünf Sekunden lang Stichproben aus den Diagnoseansichten und sagt dir, ob gerade ein Backup läuft, ein DBCC, ein Plattenplatzproblem oder eine entlaufene Abfrage.sp_BlitzCache— „Welche Abfragen verbrauchen die meisten Ressourcen?“ Sortiert deine zehn teuersten Statements nach CPU, Lesezugriffen, Ausführungen pro Minute oder Speicherbedarf — mit Klickbarem Ausführungsplan.sp_BlitzIndex— „Sind meine Indizes sinnvoll?“ Zeigt fehlende, doppelte, überflüssige und ungenutzte Indizes pro Tabelle, inklusive Schätzung, was eine Änderung bringen würde.sp_BlitzWho— „Was läuft jetzt gerade?“ Wie das eingebautesp_who2, nur mit allem, was man wirklich wissen will: Speicherzuweisung, Parallelitätsgrad, aktueller Ausführungsplan.sp_BlitzLock— „Welche Deadlocks hatten wir, und warum?“ Zerlegt das XML aus der System-Health-Sitzung, sodass du Deadlocks lesen kannst, ohne XML lesen zu müssen.sp_BlitzBackups— „Wie viele Daten würde ich verlieren, wenn jetzt der Server abraucht?“ Schätzt Recovery Point und Recovery Time aus deiner Backup-Historie.
Definition: Stored Procedure Eine Stored Procedure ist ein in der Datenbank gespeicherter SQL-Code, der mit
EXEC NameDerProzeduraufgerufen wird.
Du installierst die Skripte einmal über Install-All-Scripts.sql in der master-Datenbank, danach stehen sie auf dem ganzen Server zur Verfügung. Aufruf direkt im SSMS, Ergebnis als Tabelle — fertig.
Welche Lücken hat das Kit in der Praxis?
So nützlich die Skripte sind: Sie haben blinde Flecken, die du kennen solltest, bevor du sie deinem Kunden als Allheilmittel verkaufst.
Sie reparieren nichts. Das Kit ist Diagnose, nicht Therapie. sp_Blitz sagt dir, dass deine Datenbank seit drei Wochen kein Vollbackup gesehen hat. Es macht aber keins. sp_BlitzIndex empfiehlt einen Index. Es legt ihn nicht an. Wer aus den Befunden Maßnahmen ableiten will, braucht zusätzliches Wissen — oder ein zweites Werkzeug, das tatsächlich Wartungsaufgaben durchführt.
Sie setzen Englisch und DBA-Vokabular voraus. Die Ausgaben sind in englischer Fachsprache geschrieben, mit Begriffen wie „spills“, „RESOURCE_SEMAPHORE“ oder „query hash“. Für jeden Befund gibt es eine URL mit Hintergrund — die führt aber wieder auf englischsprachige Artikel auf brentozar.com. Wer Access kann, aber selten unter die Haube von SQL Server geschaut hat, braucht etwas Einarbeitung.
Auf Azure SQL DB läuft nur ein Teil. Microsoft ändert in Azure regelmäßig die Diagnoseansichten, deshalb wird Azure SQL DB vom Kit-Team nicht offiziell unterstützt. Für Express-Edition auf eigenem Server, RDS oder Linux ist alles dabei. Für Azure-Workloads bist du auf andere Werkzeuge angewiesen.
Der Plan-Cache ist flüchtig. sp_BlitzCache liest aus dem Speicherbereich, in dem SQL Server zuletzt ausgeführte Abfragepläne aufbewahrt. Nach einem Neustart, einem Failover oder unter Speicherdruck ist dieser Bereich leer oder lückenhaft. Wer einmal pro Quartal eine Analyse fährt, sieht möglicherweise nur das, was in den letzten Stunden gelaufen ist — nicht das, was gestern Nacht den Server lahmgelegt hat. Wer systematisch tunen will, muss die Ausgabe regelmäßig in eine Tabelle wegschreiben (das Kit kann das, siehe @OutputDatabaseName).
Express-Edition: keine Engpassanalyse mit Kostenschätzung. Die Express-Edition liefert keine Query-Store-Daten, und manche Diagnoseansichten verhalten sich anders als in den größeren Editionen. Das meiste funktioniert trotzdem — aber wenn sp_BlitzFirst mal merkwürdige Wartestatistiken zeigt, liegt das oft an der Edition, nicht am Skript.
In welcher Reihenfolge solltest du anfangen?
Wenn du das Kit zum ersten Mal auf einem fremden oder lange unbeaufsichtigten Server einsetzt, hat sich folgender Ablauf bewährt:
Erstens: sp_Blitz ohne Parameter. Dauert wenige Sekunden, gibt dir die akuten Baustellen. Gibt es ein Datenbank-Backup? Steht die Datenbank im richtigen Wiederherstellungsmodell? Sind irgendwo Konfigurationen so verstellt, dass es weh tut? Erst diese Liste durchgehen, dann weitergehen.
Zweitens: sp_BlitzFirst. Lass es einmal laufen, in einer typischen Arbeitsphase. Du erfährst, womit der Server gerade tatsächlich beschäftigt ist. Wenn der Befund „nichts Auffälliges“ lautet, weißt du: Im Normalbetrieb ist alles ruhig. Das ist eine wichtige Information, bevor du anfängst zu optimieren.
Drittens: sp_BlitzCache @SortOrder = 'reads'. Bei Access-Migrationen sind Lesezugriffe fast immer der Engpass. ODBC-Treiber neigen dazu, mehr Daten anzufordern als nötig, und alte Access-Abfragen, die als Sichten in den SQL Server gewandert sind, sind selten optimal indiziert. Diese Sortierung zeigt dir, welche zehn Abfragen am meisten von der Platte holen — und damit oft die größten Optimierungshebel.
Viertens: sp_BlitzIndex für die größten Tabellen. Mit @DatabaseName und @TableName einzelne Tabellen tief analysieren. Du bekommst pro Tabelle eine Übersicht der bestehenden Indizes, ihre Nutzung, fehlende Indizes laut SQL Server, und Hinweise auf doppelte oder unbenutzte. Standardmäßig werden nur Objekte über 250 MB analysiert, weil die Annahme ist, dass du beschäftigt bist.
Fünftens (situativ): sp_BlitzWho und sp_BlitzLock. Wenn der Anwender anruft mit „die Anwendung hängt“, öffnest du sp_BlitzWho und siehst sofort, was läuft, was blockiert, was wartet. Wenn die Anwendung Deadlock-Fehler wirft, gibt dir sp_BlitzLock die Vorgeschichte.
Aus meiner Praxis bei Access-zu-SQL-Server-Migrationen: Diese Reihenfolge findet in den meisten Fällen innerhalb einer Stunde drei bis fünf konkrete Verbesserungspunkte, die spürbaren Effekt haben.
Warum ist das gerade für SQL-Server-Express-Betreiber spannend?
Wer SQL Server Express einsetzt — typischerweise nach einer Access-Migration mit überschaubarem Datenvolumen — bekommt von Microsoft die Datenbank-Engine, aber nicht den Werkzeugkasten drumherum. SQL Server Profiler? Eingeschränkt. SQL Server Agent für geplante Jobs? Nicht in Express. Performance Dashboard, Datenbank-Tuning-Berater, Wartungspläne? Funktionieren teilweise gar nicht oder nur über Umwege.
Express-Betreiber sitzen also auf einer technisch durchaus fähigen Datenbank-Engine, aber ohne die Komfort-Werkzeuge, die das Standardpaket mitbringt. Das First Responder Kit füllt genau diese Lücke. Die Skripte greifen ausschließlich auf Diagnoseansichten zu, die in jeder Edition vorhanden sind. Du bekommst damit auf einer Express-Installation eine Diagnosefähigkeit, die ohne diese Skripte nur die kostenpflichtigen Editionen mitbringen.
Eine Express-Datenbank, die du fünf Jahre lang nicht angefasst hast, weil „sie ja läuft“, lässt sich mit sp_Blitz und sp_BlitzCache in einer Mittagspause vermessen. Das Ergebnis ist meistens: Sie läuft tatsächlich. Manchmal ist es: Sie läuft seit zwei Jahren ohne Backup. Beides ist eine Information, die du vorher nicht hattest.
Wo hört Brent Ozar auf, und wo fängt Ola Hallengren an?
Beide Sammlungen werden oft im selben Atemzug genannt, aber sie machen unterschiedliche Dinge. Verkürzt:
| First Responder Kit (Brent Ozar) | Maintenance Solution (Ola Hallengren) | |
|---|---|---|
| Zweck | Diagnose: Was ist los? | Wartung: Was muss regelmäßig getan werden? |
| Kernfragen | Performance, Engpässe, Indizes, Deadlocks | Backups, Integritätsprüfung, Indexpflege, Statistiken |
| Typischer Einsatz | Manuell, bei Bedarf, im SSMS | Automatisiert über SQL Server Agent, nachts |
| Hauptobjekte | sp_Blitz, sp_BlitzCache, sp_BlitzIndex, sp_BlitzFirst | DatabaseBackup, DatabaseIntegrityCheck, IndexOptimize |
| Express-tauglich | Ja, vollständig | Skripte ja, aber Express hat keinen Agent — nur über Umwege automatisierbar |
| Reparierende Wirkung | Keine — nur Befunde | Ja — führt Backups, Checks und Indexpflege tatsächlich aus |
| Auszeichnungen | 3.700 GitHub-Stars, 191 Beitragende | Mehrfach „Best Free Tool“ der SQL Server Magazine Awards 2010–2014 |
Hallengren beantwortet die Frage „Wie sorge ich dafür, dass die Datenbank in einem definierten Zustand bleibt?“. Die drei Hauptprozeduren DatabaseBackup, DatabaseIntegrityCheck und IndexOptimize decken Sicherung, Integritätsprüfung und Index-/Statistik-Pflege ab und sind auf alle SQL-Server-Editionen ab 2008 zugeschnitten. Brent Ozar beantwortet die Frage „Was ist eigentlich los?“.
In der Praxis brauchst du in den meisten Projekten beides. Hallengren als nächtliche Routine, die für Backups und gepflegte Indizes sorgt. First Responder Kit als Werkzeug für den Moment, in dem etwas nicht stimmt — oder wenn du einmal im Quartal nachsehen willst, wie sich die Anwendung entwickelt hat.
Die beiden Sammlungen kennen einander übrigens: Die Brent-Ozar-Prozedur sp_DatabaseRestore ist explizit darauf ausgelegt, mit Hallengrens Backup-Skripten zusammenzuspielen.
Ehrliche Einschränkung
Das First Responder Kit ist ein scharfes Werkzeug, kein Tutorial. Wer noch nie einen Ausführungsplan gelesen hat, wird mit sp_BlitzCache zwar die Top-10-Bösewichte sehen — aber ohne Grundverständnis dafür, wie SQL Server Abfragen verarbeitet, fehlt dir die Brücke vom Befund zur Maßnahme. Plane Lesezeit ein. Brent Ozar selbst hat über die Jahre eine umfangreiche Sammlung kostenloser Erklärartikel veröffentlicht, die zu jedem Befund den passenden Hintergrund liefern. Diese Lerninvestition ist überschaubar, aber sie ist nicht null.
Aus meiner Erfahrung im norddeutschen Mittelstand: Wer von Access kommt und SQL Server bisher als „bessere Datei“ benutzt hat, gewinnt durch eine halbe Stunde mit sp_Blitz und sp_BlitzCache mehr Klarheit über die eigene Anwendung als durch jede Schulung. Der erste Lauf öffnet die Augen — was du danach damit anstellst, ist die eigentliche Arbeit.
Wenn du das einmal anschauen lassen möchtest
Eine Bestandsaufnahme deiner SQL-Server-Umgebung mit diesen Skripten dauert typischerweise einen halben Tag und liefert eine sortierte Liste konkreter Maßnahmen. Wer das einmal mit jemandem zusammen durchgehen möchte, der die Befunde einordnen und priorisieren kann, erreicht mich über sesoft.de/kontakt oder sichert sich ein kostenloses Erstgespräch über sesoft.de/kostenloses-erstgespraech-sichern.
Quellen und weiterführende Links
- First Responder Kit auf GitHub — Quellcode, Releases und Dokumentation
- FirstResponderKit.org — Projektseite mit Einstiegshilfen
- Ola Hallengren’s SQL Server Maintenance Solution — Backup, Integritätsprüfung, Indexpflege
- DBA.StackExchange.com — Community-Forum für Folgefragen, das auch von den Kit-Maintainern als offizieller Support-Kanal genannt wird
