Eine Beratung zur SQL Server Performance

So beginnen viele meiner Telefongespräche.

„So“, sage ich, „ein Problem – wie kann ich Ihnen denn weiter helfen?“ – „Wir haben Performance-Probleme mit unseren SQL Servern und benötigen Ihre Hilfe.“

Nachdem mir der Anrufer die Vorgeschichte erzählt hat und wir einige Worte gewechselt haben, sage ich zu, mich auf den Weg nach Österreich zu machen und mir das Problem einmal anzusehen.

Es ist ein verregneter Tag, als ich in dem kleinen Ort ankomme. Ich werde freundlich empfangen und man begleitet mich in ein Büro voller Menschen. Es ist ein kleines Büro, der Beamer wirft das Bild an die Wand und um einen runden Tisch drängen sich sechs Menschen. Alle sind voller Erwartung und hoffen jetzt die Lösung ihrer Probleme präsentiert zu bekommen. Es ist eine Softwareentwicklungsfirma, die ihre Anwendungen auf der Basis von SQL Server entwickelt, wie viele andere.
Nach der Begrüßung stellen sich alle höflich vor, ich erzähle ein paar Worte über mich und wir machen uns an die Arbeit. Neben mir liegt ein Blatt Papier, damit ich mir einige Notizen machen kann. Ich bitte zunächst um eine Einführung in die Umgebung, die entwickelte Software und den SQL Server. Das mache ich immer, damit ich mir ein korrektes Bild machen kann und ein Verständnis für die Prozesse entwickle.

Das Team besteht aus Datenbankentwicklern und C# Entwicklern. Anfangs ist auch die Geschäftsleitung anwesend. Sie erzählen mir, dass bereits ein Monitoring stattgefunden hat, aber nichts auffälliges zu sehen sei, weder im SQL Server noch im Hyper-V, alles scheint perfekt und doch sind Performance-Probleme vorhanden. Etwas hilflos sind die Blicke der Beteiligten, die selbst keine Lösung mehr finden können. Ich lehne mich zurück und beginne im Standardverfahren meine interne Checkliste abzuarbeiten. Nach einigen Fragen merke ich, dass die Beteiligten lediglich auf die Probleme fixiert sind. Hinweise von mir auf Grundsätzliches nehmen sie zwar auf, aber sie hoffen immer wieder auf ein Wunder: einen Parameter, der vielleicht falsch gesetzt wurde, ein paar fehlerhafte Konfigurationen oder ein paar schlecht programmierte Abfragen. Wie so oft wird nur dahin geschaut, wo aus der Sicht der Beteiligten doch eigentlich die Probleme liegen sollten und nicht auf das Ganze.

Davon lasse ich mich nicht beirren, sondern stelle meine ersten Fragen nach den größten Tabellen, der Anzahl an Datensätzen, Min- und Max Memory, I/O-Architektur, Dateien, LOGs, TEMPDB, Dateigruppen, Indizes und der Größe der Datenbanken. Als die Antwort mit 25GB ausfällt, muss ich innerlich schmunzeln. Ich war doch zunächst davon ausgegangen, dass ich es mit großen Datenbanken zu tun haben.

Um Zeit einzusparen, installieren wir das sqlXpert SQL Server Monitoring Pack, das Performance Pack und in diesem Zuge stelle ich die Frage, ob Auswertungen zur gesamten SQL Server Sicherheit auch von Bedeutung für die Teilnehmer sind. Den Datensammler richten wir gemeinsam ein, ich bitte den Verantwortlichen ein paar Knöpfe zu drücken, die Analysen laufen zu lassen, während wir weiter ins Thema gehen.

Nachdem ich die Rahmenbedingungen jetzt kenne und wir von einem SQL Server in der Standard Edition ausgehen, erkläre ich im Workshop welche Best Practices es hinsichtlich der I/O gibt, was der SQL Server am liebsten hat, welche Serverparameter wichtig sind und welche Monitoring-Verfahren es gibt. Bereits hier zeige ich Unterschiede der Editionen auf, erkläre den maximalen Grad an Parallelität, TempDB, Dateien und Dateigruppen, RAID Level, LOG und Datendateien, das Datenträger-Alignement, die Clustergröße und das gesamte I/O-Verhalten.

Ich habe das Gefühl, dass einige das nicht so richtig wahr haben wollen und tatsächlich erklären sie mir, dass sie darauf keinen Einfluss haben. Gut, denke ich: keinen Einfluss bis jetzt, aber wenn das Thema essenziell ist und sich herausstellt, dass hier ein Flaschenhals sitzt, werden sie sich Gedanken um Alternativen machen müssen.

Ich gehe zum Flipchart, zeichne eine umgedrehte Pyramide auf und erkläre zunächst, mit welchen Tools es möglich ist Daten zu sammeln. Beim SQL Server gibt es von Haus aus eine Menge Tools und Verfahren. Ich schreibe sie auf: Windows-, SQL Server-, und Agent Logs (werden gern vergessen), SQL Server Monitor, Windows Performance Monitor, Task Manager, SQL Server Profiler, Dynamische Verwaltungssichten, Prozeduren, SP_Configure, SQL Server Berichte, SQLDiag, Erweiterte Ereignisse, Datensammler, SQL Trace, SQLIO, SQLSIM, Ausführungspläne, Datenbank-Optimierungsratgeber und die Richtlinien basierte Verwaltung.

Beachtlich, was es bereits alles an Standardmitteln gibt, um eine Analyse auf dem SQL Server auszuführen. Ich muss feststellen, dass die Teilnehmer viele dieser Dinge nicht kennen, beziehungsweise mit den Tools nicht richtig umgehen können.

Häufig liegt das daran, weil man, wenn es an der Zeit für Fortbildung ist, wild drauf los bucht. Wenn beispielsweise der SQL Server von 2008 auf 2012 geupdatet wird, ist es Zeit für einen Kurs. Dabei übersieht man jedoch oft etwas wichtiges: Dass es bereits bei SQL Server 2005 Dinge gab, die die Teilnehmer nicht kennen und die bei einem Update-Kurs von SQL Server 2008 auf SQL Server 2012 gar nicht mehr vorkommen.

Wissen Sie denn noch wann folgende Dinge eingeführt worden sind?

PIVOT, UNPIVOT, CROSS APPLY
DDL Trigger, Change Data Capture und Change Tracking
CLR Integration und .NET Code im SQL Server
SCOPE_IDENTITY(), EVENTDATA(), ROW_NUMBER
Datensammler, Ressourcenkontrolle, Datenbank-Optimierungsratgeber
Erweiterte Events, Service Broker, Partitionierung von Tabellen, Event Notification
MDX, DAX, Power Pivot, SharePoint integrierter Modus, SSIS DB

Erneut wird mir klar, dass diese Dinge, die wir bereits seit Jahren kennen und in die wir hineingewachsen sind, für uns zwar selbstverständlich sind – der einzelne Administrator oder Entwickler kennt und beherrscht davon jedoch oft nur etwa 30 Prozent. Ich selbst habe seit dem SQL Server 6.5 alle Neuerungen kennen gelernt, die Veränderungen bzw. Verbesserungen erlebt und bin mit dem SQL Server groß geworden.

Oft buchen uns Kunden, weil sie Probleme haben und schnelle Lösungen brauchen. Leider muss ich hier oft enttäuschen. Nachdem wir die Standard-Tools und -Verfahren sowie unsere Produkte ausgewertet haben und festgestellt haben, dass es auf Grund einer fehlenden Baseline keine Vergleichswerte gibt, wird auch hier wieder klar, dass es keinen Single Point of Fehler gibt, sondern die Hausaufgaben im breiten Rahmen gemacht werden müssen.

Hätten bessere Kenntnisse der SQL Server und der Technologien diese Probleme verhindern können? Die klare Antwort ist auf jeden Fall ja, aber es gibt auch noch andere Schwierigkeiten: Würden die Mitarbeiter in den Unternehmen besser zusammen arbeiten und die Kommunikation besser funktionieren, dann würden sie nicht erst im Workshop gemeinsam mit mir die Probleme zum Teil selbst erkennen. So passiert es mir hin und wieder, dass ich die Rolle des Mediators einnehme, die Parteien zusammenbringe und dafür sorge, dass alle miteinander reden. Dabei zeigen sich die Lösungen oft von selbst.

Ich bin in der glücklichen Lage, dass ich den SQL Server ganzheitlich kenne. Das heißt, ich kenne ihn komplett von der Entwicklung her, der Administration und der Business Intelligence. Somit kann kein Entwickler oder Administrator sich in Ausreden fliehen und die Schuld auf den anderen schieben – das klären wir am Tisch direkt miteinander.

Hier eine Auflistung der Positionen, die wieder einmal zu Problemen geführt haben.

SQL Server Virtualisierung ohne Planung
SQL Server I/O, Dateien, Dateigruppen und Systemdatenbanken, Clustergröße und Alignement
Abfragen und fehlende bzw. schlechte Indizes, suboptimale Abfragen
Viele Trigger, synchrone Prozesse und keine Verwendung von Prozeduren
String-, und rechenintensive Funktionen
Speicherverwaltung, schlechtes Timing von Prozessen und suboptimale ETL-Prozesse

Wie so oft gab es den Single Point of Fehler nicht, sondern eine lange To-Do-Liste. Auch wenn viele denken, sie kennen den SQL Server sehr gut – oft sind sie nur wirklich firm in den Bereichen, die in ihrem täglichen Fokus liegen. Ich freue mich immer wieder wenn dann neue Erkenntnisse auch zum Erfolg führen.