Mit diesem Artikel möchte ich die technischen Berater für Microsoft SQL Server, DBAs und Entwickler erreichen, die täglich bei den Kunden sind, um technische Probleme zu analysieren und zu lösen. Der folgende Artikel beruht auf einem aktuellen Projekt. Ich wurde zu diesem Projekt hinzu gezogen, weil die technischen Analysen meines Vorgängers nicht ausreichend waren, um Probleme zu erkennen und zu beheben. Um mich mit dem Thema im Vorfeld beschäftigen zu können, habe ich um vorhandene Dokumentation(en) gebeten. Die dann zugesendeten Dokumente waren den Namen nicht wert, wie einige Auszüge im Artikel zeigen werden. Gleich Eines vorweg – es soll hier kein Finger Pointing stattfinden – ich möchte aufzeigen, welche Minimalanforderungen aus meiner Sicht an eine Analysedokumentation gestellt werden sollten.

Einleitung

Seit ca. 2 Jahren werde ich immer wieder mal bei Kurzprojekten eingesetzt (ca. 1 – 4 Wochen), bei denen es – wie soll es auch anders sein – die Performance-Analyse von implementierten Microsoft SQL Server-Umgebungen oder Hochverfügbarkeitsarchitekturen geht. Ich mag diese Art von Projekten, da sie neben den “Langläufern” immer wieder Abwechslung und neue Herausforderungen bieten. In den bisherigen Fällen wurden meine Dienstleistungen immer zu Beginn – bei Auftreten der Probleme – gebucht und in der Regel waren nach 2 – 3 Tagen die Probleme analysiert und es wurden Strategien für die Behebung entwickelt. Neben der Analyse steht für mich IMMER eine sorgfältige Dokumentation der Analyse und der daraus abgeleiteten Tätigkeiten im Fokus. Sie ist ein wesentlicher Bestandteil meiner Arbeit und hinterlässt so einen “Fingerprint” meiner Tätigkeiten.

Das Referenzprojekt, das Anlass dieses Artikels ist, wurde im letzten Jahr von einem Berater betreut, weil der Kunde massive Performanceprobleme auf dem Microsoft SQL Server vermutete. Aufgabe war die Analyse der Performance-Schwachstellen sowie die Erarbeitung einer Strategie für die Behebung. Sofortmaßnahmen – sofern sie sinnvoll erscheinen – sollten ebenfalls durchgeführt werden.

Warum dokumentieren?

“Unter Dokumentation versteht man die Nutzbarmachung von Informationen zur weiteren Verwendung. Ziel der Dokumentation ist es, schriftlich oder auf andere Weise dauerhaft niedergelegte Informationen (Dokumente) gezielt auffindbar zu machen.” (Quelle Wikipedia.de).

Eine Dokumentation ist für drei Parteien dieses Projekts von großem Nutzen:

• Kunde
• Autor
• Berater

Wenn ich meine Arbeit dokumentiere, habe ich immer die Erwartungshaltung des Kunden im Blick. Dabei stelle ich mir die Frage, warum mich der Kunde zu sich gerufen hat. Weil er das Problem selbst nicht lösen kann! Die Erwartung des Kunden bei der Dokumentation besteht darin, dass eine Bestandsaufnahme, Problemanalyse sowie eine Aussicht auf Lösungen ermittelt wird.

Bei der Aussicht auf Lösungen ist es wichtig, die Dokumentation so zu formulieren, dass der Kunde die Probleme erkennt und auch die angestrebten Lösungen versteht. Aus diesem Grund verpflichte ich mich in meinen Dokumentationen, die Probleme in einer Form zu erläutern, dass es ein IT-verantwortlicher Mitarbeiter verstehen kann. Ist das Verständnis für das Problem vorhanden, bedarf es weniger Erläuterungen für die Lösungsbeschreibung. Gleichwohl hat der Kunde ein Referenzdokument für seine Unterlagen, das die Tätigkeiten des Autors belegt und – bei Bedarf – an Dritte ausgegeben werden kann, um sich schnell in den Sachverhalt einzuarbeiten.

Für mich als Autor von Dokumentationen ist sie eine Referenz und das Aushängeschild meiner Arbeit. Mit der Dokumentation gebe ich dem Kunden einen Leistungsnachweis und eine Referenz an die Hand. Nicht immer ist der Kunde darüber im Klaren, was “der Berater” so lange vor dem Computer macht; noch weniger ist es dem Kunden (in der Regel) möglich, nachzuvollziehen, was der Berater am System untersucht und – gegebenenfalls – geändert hat. Um so wichtiger ist also, dass der Kunde nachträglich erkennt, mit welchen Techniken der Berater das System untersucht und – eventuell – optimiert hat.

Für einen Berater ist eine vorhandene Dokumentation die Chance, sich möglichst schnell einen Überblick über das betroffene System zu verschaffen. Hat der Autor seine Schritte dokumentiert, kann der Berater viel Zeit sparen, indem er  bereits durchgeführte Prüfungen überspringt. Dies erfordert aus meiner Sicht aber eine sehr detaillierte Dokumentation der Ergebnisse eines Untersuchungsschrittes. Dazu aber im Nachfolgenden mehr:

Step by Step durch die Dokumentation

Microsoft SQL Server lebt davon, dass eine gute und stabile Hardware vorhanden ist. Für eine gute Performance von Microsoft SQL Server sind vor allen Dingen drei Hardwarekomponenten von Bedeutung: CPU, RAM und STORAGE. Um einen Gesamtüberblick zu erlangen, muss der Berater wie auch der DBA wissen, mit welcher Hardware-Ausstattung zu rechnen ist. Insbesondere die Information über die Ausstattung des Arbeitsspeichers ist für mich eine erste Anlaufstelle, wenn ich mir später die Datenbanken anschaue. Sind nur 16 GB RAM vorhanden und die Datenbanken haben Größen jenseits der 100 GB, kann ich erwarten, EINEN verbesserungswürdigen Punkt gefunden zu haben.

Die obige Aussage zur Hardware ist nutzlos, da wirklich wichtige Informationen für eine Bewertung fehlen:

• Wie viel RAM wurde der virtuelle Hardware zur Verfügung gestellt?
• Wie viele CPUs wurde der virtuellen Hardware zur Verfügung gestellt?
• Werden die CPU exklusiv der virtuellen Hardware zur Verfügung gestellt oder müssen sich mehrere Hosts die CPU-Leistung teilen?
• Arbeitet der Server mit SAN-Komponenten oder nur mit lokalem Storage?
• Welche CPU-Modelle werden im Server verwendet?
• Welche Festplatten / SAN-Controller werden verwendet?

Sicherlich sind einige der obigen Fragen nicht unmittelbar zu beantworten aber die Aufgabe des Beraters besteht darin, sich einen Überblick über die Basis zu verschaffen. Was definiert ein ausreichendes System? Wenn die CPU-Last nicht mehr als 30% beträgt? Oder wenn SQL Server nur einen Bruchteil des RAM benötigt?

Ein ausreichendes System bestimmt sich nach den Anforderungen, die eine Applikation voraussetzt. Eine Hardware mit 4 GB RAM und 2 Cores wird für ein Datenbanksystem für den Versand von Weihnachtskarten  keine Probleme darstellen; die Plattform eines Internethändlers erwartet jedoch vollkommen andere Voraussetzungen. Bei der Dokumentation der Hardware spielen subjektive Bewertungskriterien keine Rolle; von einem ausreichenden System ohne Information über die vorgefundene Hardware zu sprechen, dient weder dem Kunden noch den Lesern.

Ein Server, der ausschließlich für den Betrieb als Datenbankserver vorgesehen ist, sollte auf jeden einen Blockgröße von 64KBytes verwenden (siehe: Disk Partition Alignment Best Practices for SQL Server). Hier möge sich der Leser in die Rolle des Kunden versetzen – dann wird sofort die Frage aufkommen: “WARUM soll die Blockgröße 64KBytes betragen? Eventuell wird nicht jeder dieser Aussage zustimmen aber ich halte es für essentiell, dass bei Empfehlungen angegeben wird, WARUM man diese Empfehlung ausspricht. Es müssen keine riesigen Abhandlungen sein; jedoch kann mit zwei Sätzen erklärt werden, dass Microsoft SQL Server Datenseiten mit einer Größe von 8 KBytes und Extents mit jeweils 8 Datenseiten verwendet. Wenn es zu aufwändig ist, den Sachverhalt Detail zu erläutern, reichen auch weiterleitende Links zu “offiziellen” Webseiten, die eine Empfehlung untermauern (aber bitte NICHT irgendwelche Forendiskussionen!). Dieser geringe Aufwand erfüllt mehrere Anforderungen:

• Der Kunde kann – bei Interesse – weitere Informationen über die Links abrufen.
• Der Kunde kann die Empfehlung unmittelbar bewerten.
• Der Berater zeigt seine Kompetenz und dass er sich mit dem beschriebenen Thema vor der Empfehlung auseinander gesetzt hat.
• Ein nachfolgender Berater, dem eine Technik / ein Feature unbekannt ist, kann sich – wie der Kunde – sehr schnell einen Überblick verschaffen.

Unabhängig vom WARUM? stellt sich die Frage danach, welche Analysen für diese Empfehlung verwendet wurden. Um noch einmal die Erwartungshaltung des Kunden in den Vordergrund zu stellen: Der Kunde erwartet sich von den Empfehlungen durch den Berater, dass die Verarbeitung im Microsoft SQL Server beschleunigt wird. Pauschal die obige kostenintensive Maßnahme zu empfehlen, wird beim Kunden keine Freudensprünge verursachen, da mehr Fragen offen bleiben als beantwortet werden.

Als Basis zur obigen Empfehlung fehlt – neben der technischen Erläuterung – vor allen Dingen eine Berücksichtigung der vorhandenen Workloads. Datenbanken werden vielfältig genutzt; es ist von elementarer Bedeutung, vor einer Aussage zum DISK-Layout die Anwendungsgebiete genau zu analysieren und zu beschreiben.

Nach meinem Verständnis fehlt für jedes oben beschriebene “Element” eine durch Messungen / Zahlen untermauerte Analyse der Workloads des Servers. Für einen Sharepoint-Server in einer Umgebung mit 20 Mitarbeitern würde die obige Empfehlung keinen Nutzen für den Kunden bringen – der Hardware-Lieferant hätte jedoch seine helle Freude bei der eingehenden Bestellung.

• Wenn die Datenbanken ausschließlich Lesend auf die Daten zugreifen, ist die Empfehlung für die DATA- und LOG-Files eher schlecht, da sie teuer ist, wenn z. B. erkennbar ist, dass mehr RAM zur Verfügung steht als die Datenbanken an Datenvolumen aufweisen.
• Die Verlagerung der TEMPDB auf ein schnelles IO-Subsystem ist nur dann von Vorteil, wenn im Vorfeld eine Workload- und Ausführungsplan-Analyse durchgeführt wurde.
• Handelt es sich um ein OLTP-System, in dem hohe WAIT STATS gemessen werden, ist das oben skizzierte Layout sicherlich von Vorteil.

Leider werden keine Protokolle in der Dokumentation verwendet, die Basis für die Empfehlung sind. Die Empfehlung wurde vermutlich als “pauschale” Empfehlung (best practice) ausgesprochen. Es bleiben zu viele Fragen offen, die auch der Kunde nicht beantworten kann.

Es mag langweilig sein – aber auch hier fehlt jegliche Erklärung dafür, warum der Berater diese Maßnahmen (wobei die erste sicherlich nicht verkehrt ist) durchgeführt hat. Viel wichtiger wäre im Sinne der Dokumentation jedoch folgende Information gewesen:

• Warum wurden 8 Dateien angelegt?
• Wurden die Dateien von TEMPDB auf einem dedizierten Laufwerk erstellt?
• Mit welcher Größe wurden die einzelnen Dateien initial festgelegt?
• Mit welchem Wachstumswert (Prozent oder Absolut) wurden die Dateien konfiguriert?
• Sind alle Dateien mit identischen Größen und Wachstumswerten konfiguriert worden?

Noch bevor die Dateien angelegt / konfiguriert wurden, wäre die Präsentation von Zahlen / Messungen sinnvoll gewesen, die eine solche Maßnahme begründen.

Die zweite Maßnahme erschließt sich mir nicht – wie soll dann der Kunde diesen Handlungsschritt verstehen. Auch hier fehlt jegliche Begründung für die Maßnahme. Insbesondere wäre als Grundlage für diese Entscheidung eine Auswertung des Plan Cache sinnvoll gewesen. So bleibt mir dieser Schritt überlassen, wenn ich mir das System anschaue!

Das ein Clustered Index deutlich mehr Schreib- als Lesevorgänge aufweist, liegt bei einem OLTP-System in der Natur der Sache – schließlich ist er ja die Tabelle (und somit die Daten) selbst. Außerdem fehlt erneut für eine neutrale Bewertung dieser Aussage die Informationen darüber, welche Werte gemessen wurden. Auch fehlt ganz deutlich, ob die Informationen aus sys.dm_db_index_usage_stats (das ist meine Vermutung) oder aber aus sys.dm_db_index_operational_stats abgeleitet werden. Hier besteht ein ERHEBLICHER Unterschied! Aber wieder zurück zu den Erwartungen des Kunden. Was soll der Kunde mit dieser Aussage anfangen?

• Aha – zwei Clustered Indexe (was ist das?), in denen mehr geschrieben als gelesen wird?
• Wie gestalten sich denn die die Lesevorgänge? Sind es eher SEEK oder SCAN Operationen?
• Was soll ich – basierend auf der Aussage – denn nun machen?

Spätestens bei dieser Aussage war mir dann klar, dass man von dem vorliegenden Dokument nicht von einer “Dokumentation” sprechen kann. Auch muss man – LEIDER – bei solchen Aussagen festhalten, dass eine Zertifizierung nicht immer das hält, was sie verspricht. Der Autor spricht von einer Optimierungsmöglichkeit! Der Neustart des Microsoft SQL Server bewirkt keine Verbesserung sondern insbesondere bei den ersten Zugriffen wird das System eher langsam als schnell! Beim Lesen dieser “Optimierungsmöglichkeit” wird der Kunde auf eine gefährliche Spur geleitet – er geht bei dieser Empfehlung (sie ist Bestandteil der Dokumentation!) davon aus, dass es eine zwingende Maßnahme ist. Leider fehlt es auch hier – wie bei ALLEN Empfehlungen und Maßnahmen – an einer Untermauerung für die Maßnahmen.

Meine Vermutung geht dahin, dass folgende Punkte thematisiert werden sollten:

• Parameter Sniffing
• Veraltete Statistiken
• NONSargable Queries

Die obigen Beispiele sind Ausschnitte aus einer Dokumentation, die sich über 5 Seiten erstreckt. Ab Seite 2 habe ich die Verwendung von Beispielen beendet, da sie sich wiederholen. Die Beispiele zeigen vier wesentliche Merkmale, die sich – bedauerlicher Weise – durch das gesamte Dokument ziehen:

• Es werden Thesen aufgestellt, die nicht durch Messungen / Analysen / Verfahren belegt sind.
• Es werden technische Definitionen erläutert, die weder in einer fachlich ansprechenden Form kundengerecht erläutert wurden noch durch Verweise auf offizielle Dokumente des Herstellers beschrieben werden
• Analysen (sofern man sie so bezeichnen kann) werden mit Empfehlungen und durchgeführten Handlungsschritten vermischt
• Der Kunde liest ein Dokument, von dem er sich Hilfe verspricht und wird – vermutlich – deutlich ratloser zurückgelassen, als er vorher war

Bei dem obigen Beispiel von einer “Dokumentation” zu sprechen, wäre sicherlich übertrieben – es bleiben einfach zu viele Fragen offen. Hier hätte der Autor sich meiner Meinung nach einer strengeren Strukturierung bei der Erstellung des Dokuments unterwerfen sollen – es sind zu viele “Berater-Sprech”-Blubber Blasen im Dokument, die nicht genug in die Tiefe gehen und darauf abzielen, sich nicht auf eine konkrete Aussage festlegen zu müssen!

EIN KUNDE ERWARTET EINE LÖSUNG UND BEZAHLT DAFÜR! Als Autor einer Dokumentation (und insbesondere in der Rolle des externen Beraters) muss man sich vor Augen halten, dass der Kunde Hilfe anfordert und mit einer sehr großen Erwartungshaltung auf den Berater wartet. Gleichzeitig hatte der Kunde bereits im Vorfeld eine wichtige Entscheidung zu treffen, die seine Erwartungshaltung noch untermauert: Er sucht einen Berater nach seinen Skills aus und bestellt ihn dann für viel Geld in sein Unternehmen!

Ich kann für Dokumentationen / Analysen folgende Punkte mit auf den Weg geben, um ein gutes Ergebnis abzuliefern:

• Denken Sie daran, dass der Kunden Sie teuer bezahlt
• Der Kunde verbindet mit Ihrem Einsatz Lösungen, bei denen Sie ihn unterstützen sollen/können
• Trennen Sie Analysen von Handlungsempfehlungen / Handlungsschritten
• Wenn Sie technische Handlungsempfehlungen geben, beschreiben Sie die Technik VOR der Empfehlung
• Belegen Sie Behauptungen durch Testergebnisse und beschreiben Sie die Grundlage der Testergebnisse
• Wenn Sie Thesen aufstellen, untermauern Sie diese Thesen mit Fußnoten / Referenzen / Weblinks
• Führen Sie immer eine Baseline-Analyse aus um – bei Änderungen am System – die Verbesserungen zu dokumentieren
• Ihre Dokumentation ist ein wichtiger Baustein für den Betrieb von IT-Umgebungen
• Ihre Dokumentation wird von vielen Menschen gelesen (vielleicht), achten Sie auf die Rechtschreibung.

Fader Beigeschmack

Die erhaltende Dokumentation war ihr Geld aus meiner Sicht nicht wert, da sie keine analytische Dokumentation sondern vielmehr ein Tätigkeitsprotokoll mit generischen Handlungsempfehlungen (copy / paste) darstellt. Es ist verständlich, dass der Kunde mit der Leistung “eher nicht” zufrieden war und sich nach Alternativen umschaut. Die Arbeit durch den Berater beschädigt nicht nur den eigenen Ruf sondern zeigt auch deutlich auf, dass Zertifizierungen nutzlos sind, wenn man sich – wie das Beispiel zeigt – oberflächlich mit einem Thema beschäftigt. Während ich die Dokumentation gelesen habe, ging mir immer wieder ein Artikel durch den Kopf, den ich erst vor wenigen Wochen geschrieben habe: “If you pay peanuts …”! Ein Schelm, wer Böses dabei denkt.

PPS: Eigene Anregungen, Ideen, Tipps für Dokumentationen sind in den Kommentaren willkommen!

Herzlichen Dank fürs Lesen!