Wie Sie wissen, liegt die Hauptverantwortung des Datenbankadministrators in der Überwachung der Leistung von SQL Server und dem Eingreifen in bestimmten Zeiten. Auf dem Markt sind mehrere SQL Server-Leistungsüberwachungstools erhältlich, aber manchmal benötigen wir zusätzliche Informationen zur SQL Server-Leistung, um die Leistungsprobleme zu diagnostizieren und zu beheben. Daher müssen wir über genügend Informationen zu SQL Server Dynamic Management Views verfügen, um Probleme mit SQL Server zu behandeln.
Dynamic Management View (DMV) ist ein Konzept, das uns hilft, Leistungsmetriken der SQL Server-Engine zu ermitteln. DMV wurde erstmals in der SQL Server 2005-Version angekündigt und danach in allen Versionen von SQL Server fortgesetzt. In diesem Beitrag werden wir über bestimmte DMV sprechen, deren Datenbankadministrator über ausreichende Informationen verfügen muss. Dies ist sys.dm_os_wait_stats .
sys.dm_os_wait_stats
sys.dm_os_wait_stats unterstützt wichtige Metriken für die Diagnose von SQL Server-Leistungsproblemen. Wenn Sie einige Probleme (CPU, Speicher, E/A, Sperre, Latch usw.) in der SQL Server-Engine haben, leiten uns die sys.dm_os_wait_stats-Daten an, um das Problem zu definieren. Der Aktivitätsmonitor in SQL Server Management Studio enthält einen Bereich mit dem Namen „Ressourcenwartezeiten “. „Resource Waits“ erhält diese Metriken von einer speziellen gespeicherten Prozedur. Der Name dieser temporären gespeicherten Prozedur lautet „#am_generate_waitstats “ und es verwendet sys.dm_os_wait_stats. Sie finden diese temporär gespeicherte Prozedur in „tempdb“. An dieser Stelle möchte ich einige Anmerkungen zur temporär gespeicherten Prozedur hinzufügen. Weil diese Art von gespeicherter Prozedur nicht allgemein verwendet wird.
Die temporär gespeicherte Prozedur unterscheidet sich nicht von dauerhaft gespeicherten Prozeduren. Es gibt zwei Arten:lokal und global wie temporäre Tabellen. Die lokal gespeicherte Prozedur bleibt in der aktuellen Sitzung aktiv und wird gelöscht, nachdem die Sitzung geschlossen wurde. Es kann folgendermaßen erstellt werden:
CREATE PROCEDURE #LocalTestSP AS PRINT Hello Local Stored Procedure
Die global gespeicherte Prozedur bleibt auch in allen Sitzungen aktiv und wird gelöscht, nachdem die erstellte Sitzung geschlossen wurde. Die globale gespeicherte Prozedur kann wie folgt erstellt werden:
CREATE PROCEDURE ##GlobalTestSP AS PRINT Hello Global Stored Procedure
Tipp: Wenn wir den Aktivitätsmonitor öffnen, erstellt er die #am_generate_waitstats temporär gespeicherte Prozedur und löscht sie nach dem Schließen.
Jetzt werden wir uns die Hauptidee und Details von sys.dm_os_wait_stats ansehen . Die folgende Abfrage gibt alle Daten über SQL Server „Wait Statistics“ zurück. Diese Abfrage ist in der reinsten Form. Es ist unpraktisch, Probleme mit einem solchen Formular zu erkennen. In den folgenden Abschnitten finden Sie nützlichere Abfragen als sys.dm_os_wait_stats. Nun erläutern wir die Beschreibung der SQL Server „Wait Statistics“-Spalten:
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC
Die Spalte wait_type enthält die Definition oder den Namen der Wartestatistik. Die Spaltendaten von wait_type sind für uns von Bedeutung, da die Definition der Wartestatistik den Hauptgrund für das Problem angibt. wait_tasks_count gibt die Häufigkeit des Wartetyps an, der in SQL Server aufgetreten ist.
wait_time_ms gibt die Gesamtwartezeit an. Die Maßeinheit ist eine Millisekunde.
max_wait_time_ms gibt die maximale Wartezeit an.
signal_wait_time_ms wird in MSDN als „Unterschied zwischen dem Zeitpunkt, zu dem der wartende Thread signalisiert wurde, und dem Zeitpunkt, zu dem er ausgeführt wurde“ beschrieben. Ein besonders hoher Wert dieser Spalte weist auf CPU-Druck hin. Die Abfrage wartet also in der ausführbaren Warteschlange und ist zur Ausführung bereit, aber die CPU ist mit anderen Abfragen beschäftigt. Aus diesem Grund wartet die Abfrage in der Warteschlange. Wenn die CPU-Ressource verfügbar ist, erhält die CPU eine neue Abfrage aus der ausführbaren Warteschlange und beginnt mit der Verarbeitung. Kurz gesagt können wir signal_wait_time_ms beschreiben als Wartezeit in der Runnable-Queue, die sich im Zustand turn runnable to running befindet.
Tipp: In der besten Praxis sind die verschiedenen Wartestatistiken wichtiger als die anderen. Diese können wie folgt aufgelistet werden:
• PAGEIOLATCH_*
• WRITELOG
• ASYNC_NETWORK_IO
• CXPACKET
• CPU
• LCK_M_*
• PREEMPTIVE_*
• PAGELATCH_*
Werfen Sie einen Blick auf die Wartezeit von Pinal Dave oder Paul S. Randal auf Statistikabfragen. Sie haben mehrere Typen von Wartestatistiken in ihren Abfragen eliminiert. Die unten aufgeführten Ressourcenwartetypen können in sys.dm_os_wait_stats eliminiert werden Abfragen:
• BROKER_EVENTHANDLER
• BROKER_RECEIVE_WAITFOR
• BROKER_TASK_STOP
• BROKER_TO_FLUSH
• BROKER_TRANSMITTER
• CHECKPOINT_QUEUE
• CHKPT
• CLR_AUTO_EVENT
• CLR_MANUAL_EVENT
• CLR_SEMAPHORE
• DBMIRROR_DBM_EVENT
• DBMIRROR_DBM_MUTEX
• DBMIRROR_EVENTS_QUEUE
• DBMIRROR_WORKER_QUEUE
• DBMIRRORING_CMD
• DIRTY_PAGE_POLL
• DISPATCHER_QUEUE_SEMAPHORE
• EXECSYNC
• FSAGENT
• FT_IFTS_SCHEDULER_IDLE_WAIT
• FT_IFTSHC_MUTEX
• HADR_CLUSAPI_CALL
• HADR_FILESTREAM_IOMGR_IOCOMPLETION
• HADR_LOGCAPTURE_WAIT
• HADR_NOTIFICATION_DEQUEUE
• HADR_TIMER_TASK
• HADR_WORK_QUEUE
• LAZYWRITER_SLEEP
• LOGMGR_QUEUE
• MEMORY_ALLOCATION_EXT
• ONDEMAND_TASK_QUEUE
• PREEMPTIVE_HADR_LEASE_MECHANISM
• PREEMPTIVE_OS_AUTHENTICATIONOPS
• PREEMPTIVE_OS_AUTHENTICATION_OPS
• PREEMPTIVE_OS_COMOPS
• PREEMPTIVE_OS_CREATEFILE
• PREEMPTIVE_OS_CRYPTOPS
• PREEM PTIVE_OS_DEVICEOPS
• PREEMPTIVE_OS_FILEOPS
• PREEMPTIVE_OS_GENERICOPS
• PREEMPTIVE_OS_LIBRARYOPS
• PREEMPTIVE_OS_PIPEOPS
• PREEMPTIVE_OS_QUERYREGISTRY
• PREEMPTIVE_OS_VERIFYTRUST
• PREEMPTIVE_OS_WAITFORSINGLE
• PREEMPTIVE_OS_WAITFORSINGLE
• PREEMPTIVE_OS_WAITFORSINGLE
• PREEMPTIVE_OS_WAITFORSINGLE
• PREEMPTIVE_OS_WAITFORSINGLE br />• PREEMPTIVE_SP_SERVER_DIAGNOSTICS
• PREEMPTIVE_XE_GETTARGETSTATE
• PWAIT_ALL_COMPONENTS_INITIALIZED
• PWAIT_DIRECTLOGCONSUMER_GETNEXT
• QDS_ASYNC_QUEUE
• QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP
• QDS_PERSIST_TASK_MAIN_LOOP_SLEEP
• QDS_SHUTDOWN_QUEUE
• REDO_THREAD_PENDING_WORK
• REQUEST_FOR_DEADLOCK_SEARCH
• RESOURCE_QUEUE
• SERVER_IDLE_CHECK
• SLEEP_BPOOL_FLUSH
• SLEEP_DBSTARTUP
• SLEEP_DCOMSTARTUP
• SLEEP_MASTERDBREADY
• SLEEP_MASTERMDREADY
• SLEEP_MASTERUPGRADED
• SLEEP_MSDBSTARTUP
• SLEEP_SYSTEMTASK
• SLEEP_TASK
• SP_SERVER_DIAGNOSTICS_SLEEP
• SQLTRACE_BUFFER_FLUSH
• SQLTRACE _INCREMENTAL_FLUSH_SLEEP
• SQLTRACE_WAIT_ENTRIES
• UCS_SESSION_REGISTRATIO
• WAIT_FOR_RESULTS
• WAIT_FOR_RESULTS
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_HOST_WAIT
• WAIT_XTP_OFFLINE•CKPT_NEW_LOG
• R WAIT_XTP
R WAIT_XTP
R WAIT_XTP
R WAIT_XTP br />• WAITFOR_TASKSHUTDOW
• XE_TIMER_EVENT
• XE_DISPATCHER_WAIT
• XE_LIVE_TARGET_TVF
Tipp: SQL Server beginnt mit dem Sammeln von DMV-Daten, wenn es gestartet oder neu gestartet wird. SQL Server setzt die Wartestatistik automatisch zurück, wenn es neu gestartet wird, und die folgende Abfrage erzwingt das Zurücksetzen der Wartestatistik seit dem letzten Neustart von SQL Server:
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) Darüber hinaus ist die Messgenauigkeit der Wartestatistik der entscheidende Punkt. An dieser Stelle können wir zwei Ansätze in Betracht ziehen:
• Setzen Sie die Wartestatistiken zurück und rufen Sie die Wartestatistiken ab.
• Erfassen Sie zwei verschiedene „Wartezeitstatistiken“ und messen Sie die Differenz der Werte.
Meiner Meinung nach ist das Erfassen und Speichern von Wartestatistiken für jeden Verlaufstabellenansatz besser als andere. Bei dieser Methode können Sie insbesondere Zeitintervalle messen und verlieren keine Wartestatistiken historischer Daten.
Jetzt werden wir ein Beispiel für die Erfassung von Wartestatistiken erstellen und erfasste Daten in Power BI mit Grafiken anzeigen.
Wir werden eine Verlaufstabelle erstellen, um Wartestatistiken zu speichern:
CREATE TABLE [dbo].[HistoryOfWaitStatistics]( [SQLStartTime] [datetime] NULL, [Dt] [datetime] NOT NULL, [WaitType] [nvarchar](60) NOT NULL, [WaitTimeSecond] [numeric](25, 6) NULL, [ResourcesWaitSecond] [numeric](25, 6) NULL, [SignalWaitSecond] [numeric](25, 6) NULL ) ON [PRIMARY]
Das folgende Skript fügt „Wartestatistiken“ in die Verlaufstabelle ein. Aber Sie müssen diese Abfrage im SQL Server Agent planen Verlaufstabelle speichern:
DROP TABLE IF exists #eliminate_WS
CREATE TABLE #eliminate_WS (wait_type NVARCHAR(100));
INSERT INTO #eliminate_WS VALUES ('ASYNC_IO_COMPLETION');
INSERT INTO #eliminate_WS VALUES ('CHECKPOINT_QUEUE');
INSERT INTO #eliminate_WS VALUES ('CHKPT');
INSERT INTO #eliminate_WS VALUES ('CXPACKET');
INSERT INTO #eliminate_WS VALUES ('DISKIO_SUSPEND');
INSERT INTO #eliminate_WS VALUES ('FT_IFTS_SCHEDULER_IDLE_WAIT');
INSERT INTO #eliminate_WS VALUES ('IO_COMPLETION');
INSERT INTO #eliminate_WS VALUES ('KSOURCE_WAKEUP');
INSERT INTO #eliminate_WS VALUES ('LAZYWRITER_SLEEP');
INSERT INTO #eliminate_WS VALUES ('LOGBUFFER');
INSERT INTO #eliminate_WS VALUES ('LOGMGR_QUEUE');
INSERT INTO #eliminate_WS VALUES ('MISCELLANEOUS');
INSERT INTO #eliminate_WS VALUES ('PREEMPTIVE_XXX');
INSERT INTO #eliminate_WS VALUES ('REQUEST_FOR_DEADLOCK_SEARCH');
INSERT INTO #eliminate_WS VALUES ('RESOURCE_QUERY_SEMAPHORE_COMPILE');
INSERT INTO #eliminate_WS VALUES ('RESOURCE_SEMAPHORE');
INSERT INTO #eliminate_WS VALUES ('SOS_SCHEDULER_YIELD');
INSERT INTO #eliminate_WS VALUES ('SQLTRACE_BUFFER_FLUSH ');
INSERT INTO #eliminate_WS VALUES ('THREADPOOL');
INSERT INTO #eliminate_WS VALUES ('WRITELOG');
INSERT INTO #eliminate_WS VALUES ('XE_DISPATCHER_WAIT');
INSERT INTO #eliminate_WS VALUES ('XE_TIMER_EVENT');
INSERT INTO HistoryOfWaitStatistics
SELECT
(SELECT sqlserver_start_time FROM sys.dm_os_sys_info ) as SQLStartTime,GETDATE() AS Dt,Wait_type as WaitType,
wait_time_ms / 1000. AS WaitTimeSecond,
(wait_time_ms - signal_wait_time_ms)/1000. AS ResourcesWaitSecond,
signal_wait_time_ms/1000. AS SignalWaitSecond
FROM sys.dm_os_wait_stats
WHERE wait_type IN(SELECT wait_type FROM #eliminate_WS) Nachdem die Verlaufsdaten gespeichert wurden, öffnen wir Power BI und entwickeln unser Wartestatistik-Dashboard.
Klicken Sie auf Daten abrufen und wählen Sie SQL-Server aus :
Legen Sie die Verbindungseinstellungen fest und schreiben Sie dann die Abfrage in eine SQL-Anweisung (optional, erfordert eine Datenbank) . Klicken Sie auf OK .
Klicken Sie auf Von Marketplace importieren
Finden Sie Sparkline von OKViz visuelle Komponente und Hinzufügen Power BI
Fügen Sie Sparkline zum Power BI-Designbereich hinzu und ziehen Sie Datensatzspalten per Drag-and-Drop wie in der folgenden Abbildung:
Fügen Sie zwei Tabellenkomponenten zum Filtern hinzu:SQLStartTime und WaitType . Schließlich sollte das Dashboard so aussehen:
So diagnostizieren Sie das Problem mit dem Warten von Ressourcen:
In diesem Abschnitt werden wir die Methodik und Disziplin der Diagnose von Wartestatistikproblemen erwähnen. Besonders einen Punkt müssen wir bei den Wartestatistiken herausfinden:Sie definieren einfach die Hauptstruktur des Problems, geben aber niemals Details an. Aus diesem Grund müssen wir Details und Gründe für Wartezeiten recherchieren. Daher ermöglicht uns die „Wartestatistik“, unsere Forschung in diese Richtung zu lenken. Danach sollten wir andere Tools (PerfMon, Extended Events, Überwachungstools von Drittanbietern usw.) und andere DMVs verwenden, um genaue Probleme zu definieren.
Unter der Annahme, dass wir ASYNC_NETWORK_IO in SQL Server beobachten, hängt diese Ressourcenwartezeit mit einer langsamen Netzwerkverbindung von einer Client- zur Serverseite zusammen. Diese Informationen helfen jedoch nicht, den Hauptgrund des Problems zu beheben, da wir möglicherweise mehrere Netzwerkkonfigurationen zwischen Server- und Clientseite haben. Für dieses Beispiel müssen wir nachsehen:
• Abfragen für große Ergebnismengen
• Netzwerkkartenkonfigurationen
• Einstellungen der Netzwerkumgebung zwischen Serverseite und Clientseite.
• Überprüfen Sie die Bandbreite des Netzwerkadapters.
Wie Sie im Beispiel sehen können, müssen wir einige Aufgaben erledigen, um das genaue Problem zu definieren. Wartestatistiken geben nicht das Ziel des Problems an.
Schlussfolgerungen
In diesem Beitrag haben wir über das Hauptkonzept der dynamischen Verwaltungsansicht sys.dm_os_wait_stats gesprochen. Gleichzeitig haben wir die Einfachheit der Nutzung und wichtige Punkte besprochen, auf die es zu achten gilt.
Nützliches Tool:
dbForge Monitor – Add-In für Microsoft SQL Server Management Studio, mit dem Sie die Leistung von SQL Server verfolgen und analysieren können.
