Performance-Fehlerbehebung ist eine Kunst und eine Wissenschaft. Die Kunst kommt aus Erfahrung (und dem Lernen aus den Erfahrungen anderer) und die Wissenschaft kommt von bekannten Richtlinien darüber, was in welchen Szenarien zu tun ist.
Oder zumindest ist es das, was ich gerne denke und lehre.
In Wirklichkeit praktizieren viele DBAs und Entwickler da draußen das, was ich als „kurze Performance-Fehlerbehebung“ bezeichne. Dies tritt häufig auf, wenn ein Leistungsproblem die kritische Phase erreicht hat, z. B. bei Zeitüberschreitungen bei Abfragen, langsamen oder fehlgeschlagenen Prozessen, verärgerten Benutzern und dem Wunsch des Managements nach schnellen Antworten und Maßnahmen!
Der 'Kniereflex' kommt von einer oberflächlichen Analyse des Problems und dem vorschnellen Schluss (eigentlich ist es ein Greifen nach einem Strohhalm), dass das am weitesten verbreitete Symptom die Grundursache sein muss, und dem Versuch, das anzugehen, ohne oder mit wenig Erfolg, verwenden oft fehlgeleitete oder geradezu falsche Ratschläge, die online gefunden werden. Dies führt zu viel Frustration und verschwendeter Zeit und führt oft zu verschwendetem Geld, wenn das Unternehmen beschließt, das Problem mit Hardware zu bekämpfen, indem es den Server und/oder das I/O-Subsystem aktualisiert, nur um festzustellen, dass das Problem immer noch besteht , oder taucht ziemlich schnell wieder auf.
Die Analyse von Wartestatistiken ist einer der Bereiche, in denen es am einfachsten ist, einen Reflex zu machen, und in diesem Beitrag werde ich über einige der häufigsten Wartetypen und die Fehler sprechen, die Menschen in ihrer Umgebung machen. In einem Artikel wie diesem ist nicht genug Platz, um ausführlich darauf einzugehen, was in jedem Fall zu tun ist, aber ich gebe Ihnen genügend Informationen, um Sie in die richtige Richtung zu weisen.
LCK_M_XX
Die meisten Leute gehen davon aus, dass, wenn Sperrwartezeiten am weitesten verbreitet sind, es sich um eine Art Blockierungsproblem handeln muss, das das Problem darstellt. Häufig ist dies der Fall, z. B. das Fehlen eines geeigneten nicht gruppierten Index, der einen Tabellenscan in den Isolationsstufen REPEATABLE_READ oder SERIALIZABLE verursacht, der zu einer S-Tabellensperre eskaliert. (Und als kurzen Hinweis:Wenn Sie glauben, dass Sie SERIALIZABLE nie verwenden, tun Sie dies, wenn Sie verteilte Transaktionen verwenden – alles wird unter der Decke in SERIALIZABLE konvertiert, was zu unerwarteten Blockierungen und Deadlocks führen kann.)
Es ist jedoch oft der Fall, dass die Blockierung durch etwas anderes verursacht wird. Unter der standardmäßigen Isolationsstufe READ_COMMITTED werden Sperren, die Änderungen abdecken, gehalten, bis die Transaktion festgeschrieben wird, und blockieren Lesevorgänge und andere Aktualisierungen derselben Zeile(n). Wenn irgendetwas das Festschreiben einer Transaktion verhindert, könnte dies dazu führen, dass eine Blockierung angezeigt wird.
Wenn die Datenbank beispielsweise synchron gespiegelt wird, kann die Transaktion ihre Sperren nicht festschreiben und freigeben, bis die Protokolldatensätze an den Spiegel gesendet und auf das Protokolllaufwerk des Spiegels geschrieben wurden. Wenn das Netzwerk stark überlastet ist oder massive E/A-Konflikte auf dem Mirror auftreten, kann dies den Mirroring-Vorgang ernsthaft verzögern und dazu führen, dass die Transaktion viel länger zum Festschreiben braucht. Dies würde wie eine Blockierung aussehen, aber die Hauptursache sind Ressourcenkonflikte, die mit der Spiegelung zu tun haben.
Sperren Sie für Sperrwartezeiten, es sei denn, die Ursache ist aus dem Abfrageplan ersichtlich, Sperren Sie die Ressource (z Schauen Sie nach, worauf der Thread am Anfang der Blockierungskette wartet. Das wird auf die eigentliche Ursache hinweisen.
ASYNC_NETWORK_IO
Der Name von diesem sorgt für viel Verwirrung. Auf welches Wort konzentrierst du dich? NETZWERK. Die Ursache dieses Wartetyps hat normalerweise nichts mit dem Netzwerk zu tun. Es sollte eigentlich WAITING_FOR_APP_ACK (nowledgement) oder ähnlich heißen, denn genau das passiert:SQL Server hat einige Daten an einen Client gesendet und wartet darauf, dass der Client bestätigt, dass er die Daten verbraucht hat.
Eine meiner Lieblingsdemos beim Unterrichten von Wartestatistiken besteht darin, eine Abfrage auszuführen, die eine große Ergebnismenge in Management Studio zurückgibt, und zu beobachten, wie der Server ASYNC_NETWORK_IO-Wartezeiten aufbaut. Es ist eindeutig kein Netzwerk beteiligt – es ist nur so, dass SSMS lange braucht, um auf SQL Server zu antworten. Es macht das, was als RBAR (Row-By-Agonizing-Row) bekannt ist, bei dem jeweils nur eine Zeile aus den Ergebnissen gezogen und verarbeitet wird, anstatt alle Ergebnisse zwischenzuspeichern und dann sofort an SQL Server zu antworten und mit der Verarbeitung fortzufahren zwischengespeicherte Zeilen.
Dies ist die Hauptursache für ASYNC_NETWORK_IO-Wartezeiten – schlechtes Anwendungsdesign. Ich würde dann prüfen, ob der Server, auf dem der Anwendungscode ausgeführt wird, ein Leistungsproblem hat, selbst wenn der Anwendungscode selbst gut gestaltet ist. Gelegentlich ist es das Netzwerk, aber das ist meiner Erfahrung nach selten.
OLEDB
Die übliche spontane Reaktion hier ist, diesen Wartetyp mit Verbindungsservern gleichzusetzen. Diese Wartezeit wurde jedoch häufiger, als SQL Server 2005 ausgeliefert wurde, da 2005 eine Reihe neuer DMVs enthielt und DMVs meistens OLE DB im Verborgenen verwenden. Bevor ich nach Verbindungsserverproblemen suche, würde ich prüfen, ob ein Überwachungstool ständig DMVs auf dem Server ausführt.
Wenn Sie verknüpfte Server haben, fahren Sie mit der Fehlerbehebung fort, indem Sie zum verknüpften Server gehen und dort die Wartestatistiken ansehen, um zu sehen, was das häufigste Problem ist, und dann mit derselben Analyse fortfahren.
Eine andere Sache, die OLEDB-Wartezeiten verursachen kann, ist DBCC CHECKDB (und verwandte Befehle). Es verwendet ein OLE DB-Rowset, um Informationen zwischen seinen Subsystemen Query Processor und Storage Engine auszutauschen.
Andere Wartezeiten
Einige der anderen Wartezeiten, die reflexartige Reaktionen hervorrufen, sind CXPACKET, PAGEIOLATCH_XX, SOS_SCHEDULER_YIELD und WRITELOG, und ich werde sie nächsten Monat in meinem Post behandeln.
Zusammenfassung
Wenn Sie ein Leistungsproblem haben, nehmen Sie sich die Zeit, die Daten zu verstehen, die Sie sich ansehen, und führen Sie weitere Untersuchungen durch, um die Ursache des Problems einzugrenzen. Greifen Sie nicht einfach nach der scheinbar besten Wartestatistik und befolgen Sie den ersten Ratschlag, den Sie online finden (es sei denn, er stammt aus einer bekannten und seriösen Quelle), sonst werden Sie Ihr Problem wahrscheinlich nicht lösen, vielleicht sogar noch schlimmer machen.
In Bezug auf allgemeine Wartestatistiken finden Sie weitere Informationen zu ihrer Verwendung für die Fehlerbehebung in:
- Meine Blog-Post-Serie, beginnend mit Wait-Statistiken, oder sag mir bitte, wo es wehtut
- Meine Wartetypen- und Latch-Klassen-Bibliothek hier
- Mein Pluralsight-Online-Schulungskurs SQL Server:Fehlerbehebung bei der Leistung mithilfe von Wartestatistiken
- SQL Sentry Performance Advisor
Dies war der erste in einer Reihe von Beiträgen, die ich im Laufe dieses Jahres schreiben werde und in denen es um spontane (Re-)Aktionen rund um SQL Server geht und warum sie das Falsche sind. Bis zum nächsten Mal, viel Spaß bei der Fehlersuche!
