Robert Panther
SQL Server. Performanceprobleme analysieren und beheben
ISBN: 978-3-86802-686-3
© 2016 entwickler.press
Ein Imprint der Software & Support Media GmbH
Bibliografische Information Der Deutschen Bibliothek
Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.
Ihr Kontakt zum Verlag und Lektorat:
Software & Support Media GmbH
entwickler.press
Schwedlerstraße 8
60314 Frankfurt am Main
Tel.: +49 (0)69 630089-0
Fax: +49 (0)69 630089-89
lektorat@entwickler-press.de
http://www.entwickler-press.de
Lektorat/Korrektorat: Corinna Neu, Martina Raschke
Copy-Editor: Nicole Bechtel
Satz: Dominique Kalbassi
Umschlaggestaltung: Maria Rudi
Belichtung, Druck und Bindung: Media-Print Informationstechnologie GmbH, Paderborn
Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art (Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder anderen Verfahren) nur mit schriftlicher Genehmigung des Verlags. Jegliche Haftung für die Richtigkeit des gesamten Werks kann, trotz sorgfältiger Prüfung durch Autor und Verlag, nicht übernommen werden. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.
Vorwort
Dieses Buch ist für alle gedacht, die sich mit der Administration von SQL Servern beschäftigen und dafür mitverantwortlich sind, dass diese (und damit auch die Anwendungen, die darauf zugreifen), performant laufen. Der bewusst kompakt gehaltene Text liefert eine Hilfestellung, um auf plötzlich auftretende Performanceprobleme richtig reagieren zu können und somit möglichst rasch die Verwendbarkeit der dahinterliegenden Anwendung wiederherzustellen. Es wird aber auch darauf eingegangen, wie eine ausführliche Analyse von Datenbankserver und Datenbanken erfolgen kann, um daraufhin Maßnahmen abzuleiten, mit denen langfristig eine bessere Verfügbarkeit der Datenbank gewährleistet werden kann.
Dabei ist der größte Teil des Texts so allgemein gehalten, dass er für alle gängigen Versionen von SQL Server (SQL Server 2005 bis SQL Server 2016 und wahrscheinlich auch darüber hinaus) Anwendung findet. Es wird aber auch hier und da auf besondere Möglichkeiten der neueren Versionen hingewiesen, die dann aber auch entsprechend gekennzeichnet sind. Dasselbe gilt für Features, die nur für größere Editionen (wie beispielsweise Enterprise Edition) verfügbar sind. Auch wenn mittlerweile eine Vielzahl an hervorragenden Tools von Drittanbietern verfügbar ist, nutze ich im eigentlichen Buchtext ausschließlich die mit SQL Server ausgelieferten Tools, damit die Lösungsansätze für möglichst viele Leser nachvollziehbar sind. Aus eigener Erfahrung als Berater kenne ich die Problematik nur zu gut, dass man im Einsatz beim Kunden das eine oder andere Tool, an das man vorher gewöhnt war, nicht einsetzen kann (oder darf) und es daher immer hilfreich ist, sich auch mit dem Standardtoolset helfen zu können.
Auch wenn es oft schmerzhaft ist, versuche ich im Allgemeinen möglichst die deutschsprachigen Bezeichnungen für Menüpunkte und Tools zu verwenden. Da das englischsprachige Äquivalent gerade bei Recherchen im Web jedoch oft geläufiger ist, werde ich bei Einführung neuer Begriffe zusätzlich noch die englischsprachige Bezeichnung erwähnen.
Zum Schluss dieses Vorworts möchte ich mich noch bei ein paar Personen bedanken. Zum einen bei den Mitarbeitern der Software & Support Media GmbH und hier insbesondere bei Martina Raschke und Corinna Neu für ihre Geduld und konstruktive Kritik. Ein weiterer Dank geht an die zahlreichen Projektkollegen und befreundeten Spezialisten für SQL Server, mit denen ein regelmäßiger Know-how-Austausch auf Treffen der Microsoft Data Platform Community PASS (früher bekannt als „Professional Association for SQL Server“) und verschiedenen Konferenzen stattfindet. Die interessanten Diskussionen führen häufig zu neuen Anregungen und Ideen, von denen einige auch den Weg in dieses Buch gefunden haben. Hier möchte ich insbesondere Uwe Ricken erwähnen, der mir Einblick in seine umfangreiche Sammlung von SQL-Skripten gewährt hat.
Natürlich kann dieses Buch kein Allheilmittel für alle möglichen Ursachen von Performanceproblemen sein. Aber auch dann, wenn die genaue Lösung für Ihr individuelles Performanceproblem einmal nicht dabei sein sollte, sollten die beschriebenen Ansätze Sie zumindest in die richtige Richtung führen, um das Problem zu lösen.
Wenn Sie eigene Anregungen oder auch anderes konstruktives Feedback (positiv wie negativ) haben, können Sie diese gerne an meine Mailadresse sqlserver@rpanther.de senden.
Aber nun wünsche ich viel Spaß beim Lesen und hoffe, dass das Buch auch beim Lösen Ihrer Performanceprobleme weiterhilft.
Robert Panther
Hattersheim, im Juli 2016
1 Einleitung
1.1 Warum dieses Buch?
Jeder Datenbankadministrator (oder Berater in diesem Umfeld) hat sicherlich schon einmal die Situation erlebt, dass bei einer Anwendung, die bereits längere Zeit problemlos lief, sich die Anwender plötzlich beschweren, dass die Performance unerträglich schlecht und ein normales Arbeiten kaum noch möglich ist. Entweder dauern einzelne Aktionen deutlich zu lange, oder Anwender erhalten eventuell auch Time-out-Meldungen, die belegen, dass eine Aktion zu diesem Zeitpunkt gar nicht ausgeführt werden konnte, weil sie zu lange gedauert hat.
Wenn es schlecht läuft, haben die Klagen der Anwender über die schlechte Performance schon Teile des Managements erreicht; im ungünstigsten Fall waren diese davon sogar unmittelbar selbst betroffen.
Nun gilt es, gleichzeitig schnell zu reagieren, dabei aber dennoch wohlüberlegt zu handeln, denn ein Schnellschuss kann das Eingrenzen des wesentlichen Problems erschweren und im Extremfall sogar zu einer Verschlechterung der Performance führen. Die möglichen Ursachen des Problems können sehr vielseitig sein:
Daraus ergeben sich auch mindestens genauso viele Lösungsansätze:
Um schnell Abhilfe zu schaffen, ergibt es natürlich wenig Sinn, alle möglichen Lösungsansätze der Reihe nach durchzugehen. Dies würde einen erheblichen Aufwand verursachen, ohne dass eine Garantie auf Besserung des Problems gegeben wäre. Dazu erfordern einige Ansätze einen Neustart des Serverdienstes (und damit zusätzliche Ausfallzeiten) oder gar Änderungen an der Anwendung selbst. Dabei sollte es das primäre Ziel sein, quasi minimalinvasiv zu agieren, also mit möglichst geringen Änderungen eine möglichst deutliche Verbesserung der Performance zu erreichen. Erst wenn die akuten Probleme beseitigt sind, kann anschließend eine ausführliche Analyse erfolgen, um auch kleinere oder noch nicht akute Probleme zu beseitigen. Insgesamt hat sich ein dreistufiges Vorgehen bewährt:
An diesem dreistufigen Vorgehen orientiert sich auch der Aufbau des Buchtexts (Kapitel 2–4), denen ein Kapitel folgt, in dem die wichtigsten mit SQL Server ausgelieferten Tools zur Performanceanalyse kurz dargestellt sind.
Dabei ist insbesondere der erste Teil – wie das Buch insgesamt auch – sehr kompakt gehalten, damit man bei akuten Performanceproblemen nicht lange lesen muss, um eine schnelle Besserung zu erzielen. Aus demselben Grund werden Sie im Buch auch keine langen Listings finden. Wenn Sie ein akutes Performanceproblem bei einer Datenbank haben, möchten Sie sicherlich keine Zeit damit verschwenden, lange SQL-Skripte abzutippen. Stattdessen wird in den meisten Fällen beschrieben, wie Sie Performanceanalysen über die Benutzeroberfläche der diversen Tools durchführen können.1
Halten Sie dieses Buch also am besten immer in greifbarer Nähe (in der Schreibtischschublade oder unter der Tastatur), sodass Sie es im Ernstfall schnell zur Hand haben.
1.2 Für wen ist dieses Buch gedacht?
Der Text richtet sich primär an Datenbankadministratoren und Berater, die in diesem Umfeld tätig sind. Da die Übergänge zwischen den Tätigkeitsfeldern meist fließend sind, können die Inhalte auch für Anwendungs- und Datenbankentwickler eine wertvolle Hilfe sein.
An Vorkenntnissen werden vor allem Grundkenntnisse mit SQL Server vorausgesetzt, insbesondere T-SQL und der Umgang mit dem SQL Server Management Studio sollten bekannt sein.
1 Im Laufe der Zeit werden Sie diese Aufgaben sicherlich vermehrt über SQL-Skripte durchführen. Wenn Sie aber wissen, welche Daten Sie analysieren müssen, sind im Internet dazu zahlreiche Skriptvarianten zu finden. Über kurz oder lang stellen sich die meisten erfahrenen Datenbankadministratoren eine eigene individuelle Skriptbibliothek zusammen, mit der die Analysen dann auch schnell per SQL-Skript durchgeführt werden können.
2 Erste Hilfe bei Performanceproblemen
2.1 Vorgehensweise
Das Vorgehen zur schnellen Abhilfe von akuten Performanceproblemen ist mit den Sofortmaßnahmen am Unfallort nach einem Verkehrsunfall vergleichbar. Dabei ist der wichtigste Punkt, den man immer im Kopf behalten muss, nicht in Panik oder gar blinden Aktionismus zu verfallen. Auch wenn die Lösung offensichtlich erscheint und der Druck durch die sich beklagenden Anwender (oder schlimmer noch Manager) hoch sein mag, gilt es zwar zügig, aber dennoch nicht übereilt zu handeln. Denn auf der einen Seite kann ein unüberlegter Schnellschuss das akute Problem im Extremfall sogar verschlimmern oder andere Probleme nach sich ziehen. In jedem Fall wird jedoch eine spätere Analyse der Problemursachen erschwert oder sogar gänzlich verhindert, wodurch nicht auszuschließen ist, dass dieselben Probleme bald wieder auftreten.
Blenden Sie Überflüssiges aus. Es geht nicht darum, den Patienten (die Datenbank) von allen großen und kleinen „Wehwehchen“ zu befreien oder gar den SQL Server (das Auto) wieder komplett zu reparieren. Stattdessen muss der Fokus darauf liegen, mit minimalinvasiven Eingriffen den laufenden Betrieb wieder zu ermöglichen und dafür zu sorgen, dass die Datenbank ansprechbar bleibt. Dies geschieht in drei Schritten:
Best Practices
Wenn Sie mit mehreren Personen parallel arbeiten können, teilen Sie die Aufgaben auf, um noch weniger Zeit zu verlieren. Während eine Person die Anwender befragt, kann ein Zweiter schon den allgemeinen Zustand des Datenbankservers prüfen. Im Idealfall kann ein Dritter währenddessen das Management beruhigen und damit den anderen beiden den Rücken freihalten. Denn es erschwert die Konzentration auf die Fehlersuche erheblich, wenn man sich gleichzeitig rechtfertigen muss, wo das Problem liegen könnte, und Prognosen abgeben soll, wie lange die Behebung denn dauert.
Befragung der Anwender
Beginnen Sie mit einer kurzen Anamnese, indem Sie dem Mitarbeiter, der das Problem gemeldet hat, ein paar einfache, aber wichtige Fragen stellen:
Mit den Antworten auf diese Fragen lässt sich das Problem meist schon etwas eingrenzen.
Im Idealfall sind die Symptome reproduzierbar, sodass immer, wenn eine bestimmte Aktion ausgeführt wird, diese extrem lange dauert. Damit ist dann meist auch bekannt, welche Abfragen und dahinterliegenden Tabellen genauer analysiert werden sollten.
Aber auch wenn das Problem nur zu einer bestimmten Uhrzeit auftritt, lassen sich daraus weitere Schlüsse ziehen. Eventuell läuft zur selben Zeit ein regelmäßiger Batch, der dieselben Daten verwendet, sodass es zu Zugriffskonflikten kommt.
Gelegentlich kann es sogar vorkommen, dass das Problem nur bei einem einzigen User auftritt, was einerseits die Dringlichkeit der Angelegenheit deutlich entschärft, aber auch ein Hinweis dafür sein kann, dass eine mögliche Ursache der Clientrechner ist, mit dem der Anwender arbeitet.
Handelt es sich aber um ein Problem, das nahezu alle Anwender in verschiedensten Teilen der Anwendung betrifft, ist davon auszugehen, dass der SQL Server (oder die Datenbank) ein generelles Problem hat.
2.2 Prüfung des allgemeinen Systemzustands
Bei der Prüfung des Systemzustands kann man wieder eine Analogie aus dem Erste-Hilfe-Szenario nutzen. Um herauszufinden, wie es dem Verletzten (der Datenbank bzw. dem Datenbankserver) geht, sind zuerst drei Dinge zu prüfen:
Bewusstsein (Ansprechbarkeit)
Prüfen Sie, ob Server und Datenbank ansprechbar sind. Im einfachsten Fall lässt sich mit dem SQL Server Management Studio eine Verbindung zum Server herstellen und dort auch eine Abfrage auf die Datenbank absetzen.
Wenn die Verbindung nicht möglich ist, weil SQL Server keine weiteren Verbindungen zulässt, können Sie versuchen, die Verbindung über die so genannte Dedicated Administrator Connection (DAC) herzustellen.
Voraussetzungen für die Dedicated Administrator Connection
Damit die Dedicated Administrator Connection genutzt werden kann, muss der Browserdienst von SQL Server auf dem Server laufen.
Per Default funktioniert die DAC dann allerdings erst einmal nur lokal, lässt sich aber durch die folgenden Anweisungen auch für die Remote-Nutzung konfigurieren:
sp_configure
'remote admin connections', 1;
GO
RECONFIGURE;
GO
Außerdem funktioniert die Dedicated Administrator Connection nur im Abfragefenster und nicht im Objekt-Explorer.
Die Nutzung der Dedicated Administrator Connection wird aktiviert, indem Sie dem Servernamen die Zeichenfolge admin: voranstellen, also an Stelle von localhost als Servernamen admin:localhost angeben.
Atmung (Systemressourcen)
Hier ist zu prüfen, ob der Server mit ausreichenden Ressourcen versorgt wird. Für SQL Server sind vor allem vier Ressourcen von Bedeutung:
Wenn Sie sich per Fernzugriff (engl. Remote Desktop Connection) direkt auf dem Server anmelden können, lassen sich diese Kriterien leicht und unkompliziert über den Windows Task-Manager oder den etwas mehr ins Detail gehenden Ressourcenmonitor prüfen.
Die einfachste Art, den Task-Manager aufzurufen, ist über einen Rechtsklick auf die Windows-Symbolleiste am unteren Bildschirmrand (oder alternativ über die Tastenkombination STRG + ALT + ENTF), gefolgt von der Auswahl des entsprechenden Menüpunkts.
SystemleistungNetzwerkLeistungCPUArbeitsspeicherDatenträgerEthernetWi-Fi