SQL Server: Arbeiten mit dynamischen Verwaltungsobjekte
Mithilfe von dynamischen Verwaltungsobjekten können Sie Arbeitsauslastungsdetails in SQL Server verwalten und überwachen, was für die Leistungsoptimierung wesentlich ist.
Ein Auszug aus "SQL Server DMV Startpaket," veröffentlicht von Red Gate Bücher (2010).
Glenn Berry, Louis Davidson und Tim Ford
Dynamic Management Objects (DMOs) sind eine Reihe von SQL Server-Objekten, die in den System-Schema gespeichert. Sie bieten Ihnen ein Fenster in die Tätigkeiten der verschiedenen Instanzen von SQL Server und die Ressourcen, die diese Aktivitäten in Anspruch nehmen.
Mit anderen Worten, aussetzen DMOs wertvolle Informationen über Verbindungen, Sitzungen, Transaktionen, SQL-Anweisungen und Prozesse, die gegen eine Datenbankinstanz, die resultierende Arbeitsauslastung auf dem Server generiert werden, wie es ausgeliefert wird, wobei die Druckpunkte usw. ausführen. Korruptionsverdacht einer bestimmten Engpass oder Druckpunkt, Sie können dann geeignete Maßnahmen, das Problem zu lindern – vielleicht durch das Optimieren einer Abfrage, Hinzufügen eines Indexes oder einfach eine blockierende Sitzung zu töten.
Der Begriff "dynamisch" bezieht sich auf die Tatsache, dass die in DMOs gespeicherte Informationen aus einer Vielzahl von Instrumentation Punkte dynamisch generiert wird. Dies sind die Speicherstrukturen in der gesamten SQL Server-Engine. Diese Daten werden dann in tabellarischer Form in der Sys-Datenbankschema verfügbar gemacht. Die Daten werden in Ansichten, in welchem Fall sie als dynamische Verwaltungsansichten (DMVs) bezeichnet sind oder in Tabellenwerte Funktionen, womit sie Dynamic Management-Funktionen (DMFs) genannt sind.
DMVs und DMFs sind im Wesentlichen die Systemansichten und Systemfunktionen. Sie verwenden, wie Sie andere anzeigen und Funktion innerhalb der SQL Server: Diese Abfragen, verknüpfen, Parameterübergabe und letztendlich ein einzelnes Ergebnis zurückgeben festgelegt, enthält die Daten, die Sie benötigen, um ein bestimmtes Problem bezüglich der Status oder Zustand der SQL Server-Instanz zu untersuchen.
Performance-Tuning mit DMVs
DMOs machen einen manchmal Schwindel erregende Array mit Informationen verfügbar. Die ursprüngliche Ansicht der Sysprocesses-System hat im wesentlichen Denormalisieren wurde, und viele neue DMOs hinzugefügt wurden. Viele neue Datenspalten sind jetzt für Abfragen verfügbar. Wie die Datenbank-Engine besser instrumentiert wird, wird die Menge der Daten verfügbar über das Modul und die Arbeit, was, die es tut, die weiter wachsen.
Die zunehmende Komplexität der Zusammenfügen von Daten aus einem unterschiedlichen Array von DMOs, gepaart mit der ursprünglich unverständliche Auswahl der Spalten, in denen ausgesetzt, hat einige DBAs vergleichen DMOs zur Erfassung der silbernen Zaubersprüche Abfragen führen.
Allerdings hat, die De-normalization in vielerlei Hinsicht die Daten zusammen, die DMOs viel einfacher zurückgeben zu analysieren und zu verstehen. Sobald Sie beginnen, Ihre eigenen Skripts schreiben, sehen Sie die gleichen Tricks und ähnliche Join Patterns, immer wieder verwendet wird. Als solche kann ein relativ kleinen Kernsatz von Skripts leicht viele Anforderungen angepasst werden.
In mancher Hinsicht über DMOs für die Diagnosedaten arbeiten Sie benötigen einen Prozess der hintere Schichten abziehen. In der äußeren Schicht finden wir heraus, wer auf unserer SQL Server-Instanzen verbunden ist und wie sie verbunden sind; Welche gegen sie Sitzungen ausgeführt werden; und welche Anforderungen durch diese Sitzungen durchgeführt werden. Wir können die Details der von diesen Anforderungen, die Abfragepläne, die verwendet werden und so weiter ausführen ausgeführten Anweisungen SQL herausfinden.
Eine Ebene Herunterfallen, haben wir die Transaktionsebene, wo wir herausfinden können, welche Sperren aufgrund dieser Transaktionen aufrechterhalten werden, untersuchen mögliche blockieren und so weiter. Unten eine andere Ebene verschieben, können wir finden, wie die Arbeitsauslastung, vertreten durch die eingereichten Anträge in Arbeit in der OS übersetzt. Wir können, z. B. bestimmen:
- Welche tatsächlichen Aufgaben (Threads) ausgeführt werden, um die Anforderungen zu erfüllen.
- Welche Arbeit sind sie an i/O, CPU- und Speichernutzung durchführen.
- Verteilung der e/A zwischen den verschiedenen Dateien
- Wie lange Threads wartet verbringen, kann nicht fortgesetzt werden und warum
Es ist Ihre Aufgabe, alle Teile der Daten aus den unterschiedlichen Ebenen der Ergebnisse erforderlich sind, markieren Sie die spezifischen Probleme im System zusammenstellen.
Point-in-Time-Vs. Kumulative
Wie bereits erwähnt, können wir nur auf DMOs gespeicherte Daten Abfragen wie jede andere Tabelle, anzuzeigen oder zu funktionieren. Jedoch immer daran denken Sie, dass die Daten, die Sie sehen, "dynamic" in der Natur. Es wird aus einer Reihe von unterschiedlichen Strukturen in der Datenbank-Engine gesammelt und repräsentiert eine Point-in-Time "Snapshot" der Aktivität, die zur Zeit auf dem Server aufgetreten ist, dass Sie die DMO-Abfrage ausgeführt haben.
Manchmal ist dies genau was Sie wollen. Sie haben eine Leistung auszustellen und herausfinden möchten, welche Abfragen auf dem Server ausgeführt werden, die es verursacht werden. In manchen Fällen jedoch finden Sie es ziemlich schwierig, die Daten in diese Point-in-Time-DMOs in der Hoffnung, Abfragen, die das Problem einfach "heraus Sie gesprungen wird."
Wenn Sie beispielsweise ein Performance-Problem haben und keine Sperren "ungewöhnliche" Muster überprüfen möchten, dann ist es unwahrscheinlich, dass eine "select [Spalten] from [Sperren DMV]" wird dir viel, wenn Sie sehr vertraut mit, welche "normalen" Sperren nicht aussieht wie auf Ihrem System und kann ganz einfach Anomalien vor Ort.
Denken Sie daran, dass die Point-in-Time-Daten können und wahrscheinlich ändern jedes, wenn Sie Mal wird Abfragen, wie der Status der Server ändert. Rechnen gelegentlich anomale oder nicht repräsentative Ergebnisse sehen, und möglicherweise zur Ausführung eines Skripts oft einen realistischen Überblick über die Aktivitäten in Ihrer Instanz abgerufen wird.
In anderen Fällen sind DMOs kumulativ. Mit anderen Worten, sind die Daten in einer bestimmten Spalte kumulativ und in Zehnerschritten erhöht für jedes Mal, wenn ein bestimmtes Ereignis auftritt. Jedes Mal, wenn eine Sitzung wartet, einen Zeitraum für eine Ressource verfügbar wird, ist dies z. B. in einer Spalte mit der DMV sys. dm_os_wait_stats aufgezeichnet. Beim Abfragen von einer DMV, werden Sie sehen, z. B. die Gesamtzeit Wartezeit, für verschiedene Ressourcen über alle Sitzungen seit SQL Server gestartet oder neu gestartet wurde, es sei denn, eine Überprüfung der Datenbankkonsistenz oder DBCC, Befehl ausgeführt wurde, um gespeicherten statistischen Informationen manuell löschen.
Während dies Ihnen wird eine umfassende Übersicht über wo Zeit investiert wurde machen warten, über einen langen Zeitraum, es schwer zu sehen, die kleinere Details es. Wenn Sie die Auswirkungen einer bestimmten Änderungen an der Datenbank (z. B. ein neuer Index) messen möchten, müssen Sie einen Vergleichswert nehmen, nehmen Sie die Änderung und messen Sie den Unterschied.
Schließlich immer Bedenken Sie, die viele Daten, die Sie, in solchen DMOs sehen Aggregatdaten gesammelt über viele Sitzungen, viele Anfragen und viele Transaktionen ist. Die zuvor erwähnten Wait_stats DMV, z. B. zeigen an eine Instanz Ebene Ihnen wo SQL Server Wartezeiten, aggregiert über alle Sitzungen ausgegeben. Sie können nicht die Wartezeiten auf eine einzelne Sitzungsebene verfolgen – es sei denn natürlich, Sie auf einen isolierten Server arbeiten.
.png)
.png)
.png)
Glenn Berry arbeitet als Datenbankarchitekt bei NewsGator Technologies in Denver, Colorado Er ist ein SQL Server-MVP und hat eine ganze Sammlung von Microsoft-Zertifizierungen, einschließlich MCITP, MCDBA, MCSE, MCSD, MCAD und MCTS, was beweist, dass er mag Tests machen.
Louis Davidson in der IT-Branche wurde 16 Jahre lang als Unternehmensdatenbank Entwickler und Architekten. Er ist seit sechs Jahren SQL Server Microsoft MVP und hat vier Bücher zum Entwerfen von Datenbanken geschrieben. Er ist derzeit datenarchitekt und manchmal DBA für die Christian Broadcasting Network, Unterstützung der Büros in Virginia Beach, Virginia, und Nashville, Tennessee
Timothy Ford ein SQL Server-MVP und arbeitet mit SQL Server für mehr als 10 Jahren. Er ist der primäre DBA und Experte für die SQL Server-Plattform für die Gesundheit des Spektrums. Er wurde schriftlich über Technologie seit 2007 für eine Vielzahl von Websites und verwaltet seinen eigenen Blog unter thesqlagentman.com, SQL als auch Telearbeit und professionelle Entwicklungsthemen abdecken.
Erfahren Sie mehr über "SQL Server DMV Starter Pack" unter red-gate.com/our-company/about/book-store.