Microsoft hat heutzutage nicht die Angewohnheit, Dinge abzulehnen, aber wenn sie es tun, dann aus einem bestimmten Grund – und sicherlich nicht, weil sie Ihnen das Leben schwerer machen wollen. Im Gegenteil, es liegt fast immer daran, dass sie bessere und modernere Methoden entwickelt haben, um dieselben Probleme zu lösen.
Aber Gewohnheiten sind schwer zu brechen; frag mich woher ich das weiß. Allzu oft sehe ich Menschen, die an einer älteren Methode festhalten, um eine Aufgabe zu erledigen, obwohl es eine bessere Methode gibt.
Ich möchte einige aktuelle Beispiele vorstellen, die veranschaulichen, wie uns die Verwendung veralteter SQL Server-Funktionen weiterhin belastet. In diesem ersten Teil möchte ich über … sprechen
Systemprozesse
Die Systemtabelle sys.sysprocesses wurde vor langer Zeit in SQL Server 2005 durch eine Reihe dynamischer Verwaltungsansichten (DMVs) ersetzt, insbesondere durch sys.dm_exec_requests , sys.dm_exec_sessions und sys.dm_exec_connections . Die offizielle Dokumentation für sys.sysprocesses warnt:
Ein aktuelles Beispiel
Kürzlich untersuchte eines unserer Teams ein Problem mit der Latenz des Protokolllesers. Wir achten hier sehr auf die Latenz, zusammen mit allen lang andauernden Transaktionen, da sie nachgelagerte Auswirkungen auf Technologien haben, die den Protokollleser verwenden – wie Verfügbarkeitsgruppen und Transaktionsreplikation. Unsere ersten Warnungen werden normalerweise auf einem Dashboard entdeckt, das die Latenz des Protokolllesers gegen die Transaktionsdauer darstellt (ich erkläre die Zeitpunkte, die ich mit t0 und t1 in Kürze):
Sie bestimmten, sagen wir zum Zeitpunkt t0 , dass eine bestimmte Sitzung eine offene Transaktion hatte, die den Protokollleseprozess blockierte. Sie überprüften zuerst die Ausgabe von DBCC INPUTBUFFER , um festzustellen, was diese Sitzung zuletzt getan hat, aber die Ergebnisse zeigten einfach, dass sie während ihrer Transaktion auch andere Stapel ausgegeben haben:
event_type parameters event_info -------------- ---------- --------------- Language Event 0 SET ROWCOUNT 0;
Beachten Sie, dass DBCC INPUTBUFFER hat in modernen Versionen auch einen leistungsfähigeren Ersatz:sys.dm_exec_input_buffer . Und obwohl es keine explizite Verfallswarnung gibt, ist die offizielle Dokumentation für DBCC Befehl hat diesen sanften Schubs:
Nachdem sie nichts aus dem Eingabepuffer erhalten hatten, haben sie sys.sysprocesses abgefragt :
SELECT spid, [status], open_tran, waittime, [cpu], physical_io, memusage, last_batch FROM sys.sysprocesses WHERE spid = 107;
Die Ergebnisse waren ähnlich nutzlos, zumindest in Bezug auf die Feststellung, was die Sitzung getan hatte, um ihre Transaktion offen zu halten und den Protokollleser zu stören:
Ich hebe das physical_io hervor Kolumne, weil dieser Wert eine Diskussion darüber auslöste, ob sie das Risiko eingehen wollten, die Schlafsitzung zu beenden. Die Überlegung war, dass für den Fall, dass all diese physischen I/Os Schreibvorgänge sind, das Beenden der Transaktion zu einem langwierigen und störenden Rollback führen könnte – was das Problem möglicherweise noch verschlimmert. Ich werde hier keine tatsächlichen Zeiten angeben, aber sagen wir einfach, dies wurde zu einem längeren Gespräch, und es ließ das System ab dem Zeitpunkt t0 zum Zeitpunkt t1 in der Grafik oben.
Warum dies ein Problem ist
Das Problem in diesem speziellen Fall ist, dass sie diese Zeit damit verbracht haben, eine Entscheidung auf der Grundlage unvollständiger Informationen zu erwägen. Handelt es sich bei diesen I/Os um Lese- oder Schreibvorgänge? Wenn der Benutzer eine offene Transaktion hat und nur viele Daten gelesen hat, hat das Zurücksetzen dieser Transaktion weitaus weniger Auswirkungen, als wenn er sich geändert hat viele Daten. Also statt sys.sysprocesses , mal sehen, was die modernere DMV, sys.dm_exec_sessions , kann uns etwas über diese Sitzung zeigen:
SELECT session_id, [status], open_transaction_count, cpu_time, [reads], writes, logical_reads, last_request_start_time, last_request_end_time FROM sys.dm_exec_sessions WHERE session_id = 107;
Ergebnisse:
Hier sehen wir, dass sys.dm_exec_sessions teilt die physischen E/A separat in Lese- und Schreibvorgänge auf. Dadurch können wir viel schneller eine viel fundiertere Entscheidung treffen als t1 - t0 , über die Auswirkungen eines möglichen Rollbacks. Wenn die E/A ausschließlich aus Schreibvorgängen besteht, und je nachdem, wie hoch die Zahl ist, zögern wir möglicherweise etwas länger und verbringen vielleicht die Zeit damit, den Benutzer ausfindig zu machen (damit wir ihm auf die Finger schlagen oder ihn fragen können, warum er eine offene Transaktion hat ). Wenn wir wissen, dass es sich hauptsächlich um Lesevorgänge handelt, können wir stattdessen dazu tendieren, die Sitzung zu beenden und ein Rollback der Transaktion zu erzwingen.
Sicher, sys.sysprocesses hat dbid und waittime . Aber dbid ist sowieso unzuverlässig und kaum nützlich, insbesondere für datenbankübergreifende Abfragen; es gibt viel bessere Informationen in sys.dm_tran_locks . Warteinformationen (Zeit und letzter Wartetyp) finden Sie in sys.dm_exec_requests , aber viel detailliertere Informationen werden in sys.dm_exec_session_wait_stats angeboten (in SQL Server 2016 hinzugefügt). Eine Ausrede, die ich oft hörte, war sys.dm_exec_sessions open_tran fehlte , aber open_transaction_count wurde in SQL Server 2012 wieder hinzugefügt. Es gibt also kaum einen Grund, überhaupt über die Verwendung von sys.sysprocesses nachzudenken heute.
Wenn Sie herausfinden möchten, wie oft sys.sysprocesses seit dem letzten Neustart von SQL Server verwiesen wurde, können Sie diese Abfrage für die Leistungsindikatoren DMV:
SELECT instance_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE N'%:Deprecated Features%'
AND instance_name = N'sysprocesses'
ORDER BY cntr_value DESC;
Wenn Sie heute Nacht wirklich nicht schlafen möchten oder einfach ständig Dinge auf die Wäscheliste setzen möchten, um die Sie sich Sorgen machen, entfernen Sie das Prädikat für instance_name . Dadurch erhalten Sie eine beängstigende allgemeine Vorstellung davon, wie viele Dinge auf Ihren Instanzen ausgeführt werden, die Sie eventuell ändern müssen.
Laden Sie in der Zwischenzeit sp_WhoIsActive herunter , die äußerst nützliche gespeicherte Prozedur von Adam Machanic zur Überwachung und Fehlerbehebung von SQL Server-Prozessen in Echtzeit. Wir haben diese gespeicherte Prozedur für jede Instanz in unserer Umgebung bereitgestellt, und Sie sollten dies auch tun, unabhängig davon, welche anderen High-End-Überwachungstools Sie möglicherweise ebenfalls verwenden.
Nächstes Mal
In Teil 2 werde ich ein wenig über SQL Server Profiler sprechen, eine Anwendung, die Menschen eher aus Vertrautheit als aus irgendetwas anderem verwenden – ohne zu wissen, wie gefährlich sie sein kann.
