Quellen für Performance-Optimierung und Objektsperren

Vor Kurzem erreichte mich eine Mail mit ein paar Fragen:

Ich komme immer wieder in die Situation SQL Skripte und Reports zu entwickeln. In den durchaus komplexen und gewachsenen Strukturen unserer Kunden kommt es nun immer wieder auf Performance und sauberen Code (u.a. Zugriff auf Daten, Objektsperren, etc.) an. Daher die Frage ob Du gute Ressourcen (Blogs, Bücher, etc.) für folgende Themen empfehlen kannst?

• Wie kann ein SQL Statement (z.B. Stored Procedure, SQL Script od. Report) hinsichtlich Performance überprüft werden? Insbesondere um zu erkennen, welche Codesektion geändert werden muss weil diese eine lange Abfragezeit verursacht?
• Gibt es Best Practices für SQL Code in Bezug auf Datenzugriff? Hier stellt sich z.B. die Frage was passiert wenn ein SELECT auf eine Tabelle mit Millionen von Einträgen erfolgt und andere Prozesse auch darauf zugreifen?

So pauschal lässt sich das eben nicht sagen. Man kann zwar ein paar Grundregeln bzw. Grundvoraussetzungen benennen, aber der Rest hängt von der jeweiligen Situation ab.

Der Flaschenhals kann ja sehr unterschiedlicher Natur sein, zum Beispiel zu wenig I/O-Durchsatz, fehlende Indizes, erhöhte Komplexität der Abfrage, usw.

Wenn man nun aber vor hat, sich in Sachen Performance-Optimierung weiterzubilden, so ist es essentiell, dass man grundlegend die Funktionsweise des MS SQL Servers versteht und dass man nachvollziehen kann, wie der SQL Server seine Abfragen verarbeitet und versucht zu optimieren. Für diese Grundlagen empfehle ich jedem das Buch Microsoft SQL Server 2008 Internals (aktuell ist noch das 2008er Buch, aber am 31. Juli 2013 erscheint die 2012er Version des Buches). In dem Buch ist nicht beschrieben wie ich mir einen Wartungsplan zusammenklicke, aber dafür ist im Detail erklärt, wie der SQL Server agiert und wie er seine Daten organisiert. Mit diesem Verständnis von der Vorgehensweise des SQL Servers kann man wesentlich besser Performance-Engpässe in Abfragen erkennen.

Im nächsten Schritt ist es unerlässlich, zu lernen, wie man Ausführungspläne liest und dessen Inhalt deuten kann. Vor allem muss man identifizieren können, an welchen Stellen im Ausführungsplan Engpässe entstehen können.

Im Endeffekt kann man aber einige wichtige Regeln aufstellen, die in den meisten Fällen Anwendung finden können:

1. Lieber Komplexität verringern und mit Zwischenschritten arbeiten. Das macht die Arbeit für den Abfrageoptimierer einfacher und eindeutiger.

2. Immer Tests mit den Abfragen machen und die Ausführungspläne studieren.

3. Den SQL Server Profiler verwenden, um die Laufzeiten, die CPU-Auslastung und die I/O-Werte zu analysieren.

Zum Thema Datensperre gibt es im MS SQL Server 2008 einen eleganten Weg, dem with (nolock)-Hint aus dem Weg zu gehen, denn es gibt das Snapshot-Isolation-Level.

Ohne die Einstellung des Snapshot-Isolation-Level wird bei jedem SELECT während des Datenabrufes ein Shared-Lock (die Tabelle wird vor ungewollter Änderung während der Sperre geschützt) auf die involvierte Tabelle gesetzt und alle anderen Prozesse, die die Daten manipulieren wollen, sind gezwungen so lange zu warten, bis das SELECT vollzogen wurde.

Letztendlich benötigt man viel Erfahrung und Verständnis auf diesem Gebiet.