Database
 sql >> Datenbank >  >> RDS >> Database

Grundlagen von sys.dm_exec_requests

Leistungsüberwachung und Fehlerbehebung in SQL Server ist ein umfangreiches Thema. In SQL Server 2005 wurden dynamische Verwaltungsansichten, auch bekannt als DMVs, eingeführt und wurden zu einem unverzichtbaren Hilfsmittel für die Diagnose von SQL Server-Leistungsproblemen. Gleichzeitig können wir dynamische Verwaltungsansichten für Azure SQL-Datenbank verwenden. Einige von ihnen können sich von der lokalen SQL Server-Datenbank unterscheiden, aber die Arbeitslogik ist immer noch dieselbe. Microsoft verfügt über eine sehr gute Dokumentation zu dynamischen Verwaltungsansichten. Das Einzige, was Sie beachten müssen, ist die Versions- und Produktvalidierung dynamischer Verwaltungsansichten. Beispielsweise ist sys.dm_exec_request für SQL Server 2008 und höhere Versionen und für die Azure SQL-Datenbank verfügbar, aber sys.dm_db_wait_stats ist nur für die Azure SQL-Datenbank gültig.

In diesem Beitrag werden wir über die Grundlagen von sys.dm_exec_request sprechen. sys.dm_exec_requests ist eine dynamische Verwaltungsansicht, die nur die aktuell ausgeführten Anforderungen zurückgibt. Dies bedeutet, dass beim Ausführen der Abfrage sys.dm_exec_requests eine Momentaufnahme der Anforderung erstellt wird, die zu diesem Zeitpunkt ausgeführt wird, und keine historischen Daten enthält. Daher ist diese Ansicht sehr praktisch für die Überwachung von Echtzeitanforderungen. Mit anderen Worten, es gibt die Antwort auf die Frage „Was ist gerade auf meinem Server los?“. Diese Ansicht enthält viele Details, aber wir werden die wichtigsten besprechen.

Sitzungs-ID :Dieser Wert definiert eine Sitzungsidentifikationsnummer. In SQL Server werden Sitzungs-IDs, die gleich oder kleiner als 50 sind, dem Hintergrundprozess zugeordnet.

start_time :Dieser Wert definiert das Startdatum und die Uhrzeit der Anfrage.

Status :Dieser Wert definiert einen Status der Anfrage. Die verfügbaren Status sind:

  • Hintergrund
  • Laufen
  • lauffähig
  • schlafen
  • gesperrt
SELECT DISTINCT status
FROM sys.dm_exec_requests
WHERE session_id <>@@SPID

Hintergrund :Dieser Statustyp definiert die Hintergrundprozesse. Einige davon sind LAZY WRITER, CHECKPOINT und LOG WRITER.

select session_id, command, os_thread_id from sys.dm_exec_requests as r
 join sys.dm_os_workers as w on r.task_address = w.task_address
 join sys.dm_os_threads as t on t.thread_address = w.thread_address
 where session_id <= 50
 order by session_id

Laufen :Dieser Statustyp definiert, dass die Anfrage von der CPU verarbeitet wird.

 select * from sys.dm_exec_requests where status='running'
 and session_id <>@@SPID

lauffähig :Dieser Statustyp kann einfach als Anforderung definiert werden, die in der CPU-Warteschlange auf Ausführung wartet. Wenn Sie viele ausführbare Prozesse in sys.dm_exec_requests erkennen, kann dies ein Symptom für CPU-Auslastung sein. Diese Metrik reicht nicht aus, um dieses CPU-Leistungsproblem zu diagnostizieren. Aus diesem Grund müssen wir diesen Fall mit mehr Beweisen untermauern. Dies ist für uns von Bedeutung, um unsere Theorie zu beweisen. Die dynamische Verwaltungsansicht sys.dm_os_wait_stats enthält eine Spalte mit der Bezeichnung signal_wait_time_ms. Dieser Spaltenwert kann hilfreich sein, um das CPU-Problem zu ermitteln. Die folgende Abfrage zeigt uns den Prozentsatz von Signalwait. Wenn diese Metrik einen hohen Wert hat, haben Sie höchstwahrscheinlich ein Problem mit der CPU-Leistung. Auf diese Weise können Sie Ihre Bewertung vertiefen.

---https://sqlserverperformance.wordpress.com/page/146/
---Glenn Berry's SQL Server Performance 

SELECT signal_wait_time_ms=SUM(signal_wait_time_ms)
              ,'%signal (cpu) waits' = CAST(100.0 * SUM(signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2))
              ,resource_wait_time_ms=SUM(wait_time_ms - signal_wait_time_ms)
              ,'%resource waits'= CAST(100.0 * SUM(wait_time_ms - signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2))
FROM sys.dm_os_wait_stats;

gesperrt :Dieser Statustyp definiert den Warteprozess einer Ressource. Es kann I/O, LOCK und LATCH usw. sein. Wie oben erwähnt, können wir die sys.dm_os_wait_stats verwenden dynamische Verwaltungsansicht zum Erkennen von wait_time_ms.

schlafen :Dies bedeutet, dass die Anfrage mit SQL Server verbunden ist, aber derzeit keine Befehle ausgeführt werden.

Befehl :Diese Spalte definiert einen Befehlstyp, der ausgeführt wird. Gleichzeitig können wir zusätzliche Informationen für bestimmte Befehle finden, die eine Abschlussquote darstellen. Laut den Online-Büchern sind dies:

ALTER INDEX NEU ORGANISIEREN

AUTO_SHRINK-Option mit ALTER DATABASE

BACKUP-DATENBANK

DBCC-CHECKDB

DBCC CHECKFILEGROUP

DBCC-PRÜFTABELLE

DBCC INDEXDEFRAG

DBCC SHRINKDATABASE

DBCC SHRINKFILE

WIEDERHERSTELLUNG

DATENBANK WIEDERHERSTELLEN

ZURÜCKSETZEN

TDE-VERSCHLÜSSELUNG

Demo :

  • Verbinden Sie die Master-Datenbank und starten Sie das Backup für jede Datenbank.
    BACKUP DATABASE WideWorldImporters TO DISK ='NUL'

    Tipp Hinweis:Wenn Sie die Datenbanksicherung auf das „NUL“-Gerät legen, schreibt SQL Server nirgendwo eine Sicherungsdatei, und Sie vermeiden das Löschen einer Testsicherungsdatei. Verwenden Sie diesen Befehl jedoch nicht in Ihrer Produktionsumgebung. Dies kann dazu führen, dass die LSN-Kette unterbrochen wird.

Führen Sie die folgende Abfrage aus:

SELECT command,percent_complete ,*
FROM sys.dm_exec_requests
WHERE session_id <>@@SPID
and session_id>50 and command='BACKUP DATABASE'

sql_handle :Dieser Wert definiert die SQL-Anweisung der Anfrage. Aber dieser Wert ist im Bitmap-Format. Aus diesem Grund müssen wir die Tabellenwertfunktion sys.dm_exec_sql_text verwenden, um den Wert in aussagekräftigen Text umzuwandeln.

select session_id ,command , sqltxt.text ,database_id
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
where session_id<>@@SPID AND session_id>50

Datenbank-ID :Dieser Wert definiert, welche Datenbank die Anfrage stellt. Wir können dieses Feld mit sys.databases verknüpfen, um den Datenbanknamen zu erhalten.

select session_id ,command , sqltxt.text ,db.name
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50

wait_type :Dieser Wert definiert den aktuellen Wartetyp der Anfrage. Wenn die Dauer der Abfrageausführung länger als erwartet dauert, können Sie den Wartetyp der Abfrage überprüfen und bestimmen.

transaction_isolation_level :Dieser Wert definiert die Transaktionsebene der übermittelten Abfrage:

0=Nicht angegeben

1=ReadUncommitted

2=ReadCommitted

3=Wiederholbar

4=Serialisierbar

5=Schnappschuss

select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level,
CASE transaction_isolation_level
WHEN 0 THEN 'Unspecified'
WHEN 1 THEN 'ReadUncomitted'
WHEN 2 THEN 'ReadCommitted'
WHEN 3 THEN 'Repeatable'
WHEN 4 THEN 'Serializable'
WHEN 5 THEN 'Snapshot'
END
AS isolation_level_name
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50

blocking_session_id :Es ist die ID der Sitzung, die die Anfrage blockiert. Wenn diese Spalte NULL ist, hat die Anfrage keine Sitzung blockiert.

Demo :

  • Öffnen Sie SQL Server Management Studio und führen Sie die folgende Abfrage aus.
    DROP TABLE IF EXISTS TestPerfomon
GO
CREATE TABLE TestPerfomon
(ID INT ,
Nm VARCHAR(100))

INSERT INTO TestPerfomon
VALUES(1,1)
GO
BEGIN TRAN
UPDATE TestPerfomon SET Nm='2'
WHERE ID=1

SELECT @@SPID AS blocking_session_id

Öffnen Sie ein neues Abfragefenster und führen Sie die folgende Abfrage aus.

SET TRANSACTION ISOLATION LEVEL Serializable
BEGIN TRAN
UPDATE TestPerfomon SET Nm='3'
WHERE ID=1

Öffnen Sie ein weiteres neues Abfragefenster und führen Sie diese DMV-Abfrage aus.

select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level,
CASE transaction_isolation_level
WHEN 0 THEN 'Unspecified'
WHEN 1 THEN 'ReadUncomitted'
WHEN 2 THEN 'ReadCommitted'
WHEN 3 THEN 'Repeatable'
WHEN 4 THEN 'Serializable'
WHEN 5 THEN 'Snapshot'
END
AS isolation_level_name ,
blocking_session_id
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50

Mit dieser Demonstration haben wir herausgefunden, warum die zweite Abfrage blockiert wird und welche Sitzung die Anforderung blockiert. Wenn Sie sp_BlitzWho 65 ausführen, können Sie die Details der Blockierung und die Details der blockierten Sitzungen herausfinden.

sp_BlitzWho 65

In dieser Demonstration haben wir die Details zum Blockieren und zu blockierten Sitzungen abgerufen und gleichzeitig die Details zu diesen Sitzungen erhalten. Dies ist eine sehr einfache Demonstration, aber sie zeigt, wie das Problem gelöst werden kann.

In diesem Beitrag haben wir über sys.sys.dm_exec_requests gesprochen. Diese dynamische Verwaltungsansicht gibt uns die Flexibilität, eine Momentaufnahme während der aktuellen Stufe einer Anfrage zu erhalten. Diese detaillierten Daten können uns auch dabei helfen oder uns durch den Prozess der Problemerkennung führen.

Referenzen

  • sys.dm_exec_requests (Transact-SQL)
  • Überwachen der Azure SQL-Datenbank mithilfe dynamischer Verwaltungsansichten
  • sys.dm_db_wait_stats (Azure SQL-Datenbank)

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.