Podstawy sys.dm_exec_requests

Monitorowanie wydajności i rozwiązywanie problemów w SQL Server to obszerny temat. W SQL Server 2005 wprowadzono dynamiczne widoki zarządzania, znane również jako DMV, które stały się niezbędnym narzędziem pomocniczym do diagnozowania problemów z wydajnością SQL Server. Jednocześnie możemy korzystać z dynamicznych widoków zarządzania dla Azure SQL Database. Niektóre z nich mogą różnić się od lokalnej bazy danych SQL Server, ale logika pracy jest nadal taka sama. Microsoft ma bardzo dobrą dokumentację dotyczącą dynamicznych widoków zarządzania. Jedyna rzecz, to musisz uważać na wersję i walidację produktu dynamicznych widoków zarządzania. Takie jak sys.dm_exec_request jest dostępne dla SQL Server 2008 i nowszych wersji oraz dla bazy danych Azure SQL, ale sys.dm_db_wait_stats jest prawidłowy tylko dla bazy danych Azure SQL.

W tym poście omówimy podstawy sys.dm_exec_request. sys.dm_exec_requests to dynamiczny widok zarządzania, który zwraca tylko aktualnie wykonywane żądania. Oznacza to, że gdy uruchomisz zapytanie sys.dm_exec_requests, zrzutyka ono uruchomione w tym czasie i nie zawiera żadnych danych historycznych. Dlatego ten widok jest bardzo przydatny do monitorowania żądań w czasie rzeczywistym. Innymi słowy, daje odpowiedź na pytanie „co się teraz dzieje na moim serwerze?” Ten widok zawiera wiele szczegółów, ale omówimy najważniejsze.

identyfikator_sesji :Ta wartość określa numer identyfikacyjny sesji. W SQL Server identyfikatory sesji równe lub mniejsze niż 50 są dedykowane procesowi w tle.

czas_rozpoczęcia :ta wartość określa datę i godzinę rozpoczęcia żądania.

stan :Ta wartość określa status żądania. Dostępne statusy to:

• tło
• bieganie
• możliwy do uruchomienia
• spanie
• zawieszony

SELECT DISTINCT status
FROM sys.dm_exec_requests
WHERE session_id <>@@SPID

tło :Ten typ statusu definiuje procesy w tle. Niektóre z nich to LAZY WRITER, CHECKPOINT i 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

bieganie :Ten typ statusu określa, że ​​żądanie jest przetwarzane przez procesor.

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

możliwy do uruchomienia :Ten typ statusu można po prostu zdefiniować jako żądanie, które czeka w kolejce procesora na uruchomienie. Jeśli wykryjesz wiele uruchamialnych procesów w sys.dm_exec_requests, może to być objawem obciążenia procesora. Ta metryka nie wystarcza do zdiagnozowania tego problemu z wydajnością procesora. Z tego powodu musimy poprzeć tę sprawę większą liczbą dowodów. Jest to dla nas ważne, aby udowodnić naszą teorię. Dynamiczny widok zarządzania sys.dm_os_wait_stats zawiera kolumnę, która jest signal_wait_time_ms. Ta wartość w kolumnie może pomóc w ustaleniu problemu z procesorem. Poniższe zapytanie pokazuje nam procent Signalwait. Jeśli ta metryka ma dużą wartość, najprawdopodobniej masz problem z wydajnością procesora. W ten sposób możesz pogłębić swoją recenzję.

---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;

zawieszone :Ten typ statusu definiuje proces oczekiwania pewnego zasobu. Może to być I/O, LOCK i LATCH itp. Jak wspomniano powyżej, możemy użyć sys.dm_os_wait_stats dynamiczny widok zarządzania do wykrywania wait_time_ms.

spanie :Oznacza to, że żądanie jest połączone z serwerem SQL, ale aktualnie nie uruchamia żadnych poleceń.

polecenie :Ta kolumna definiuje typ wykonywanego polecenia. Jednocześnie możemy znaleźć dodatkowe informacje dla poszczególnych poleceń, jakimi jest stopień realizacji. Według książek online są to;

REORGANIZACJA ZMIANY INDEKSU

Opcja AUTO_SHRINK z ALTER DATABASE

KOPIA ZAPASOWA BAZY DANYCH

DBCC CHECKDB

DBCC CHECKFILEGROUP

TABELA KONTROLNA DBCC

DBCC INDEXDEFRAG

DBCC SHRINKDATABASE

PLIK DBCC ZMNIEJSZONY

ODZYSKIWANIE

PRZYWRÓĆ BAZĘ DANYCH

COFNIĘCIE

SZYFROWANIE TDE

Demo :

• Podłącz główną bazę danych i rozpocznij tworzenie kopii zapasowej dowolnej bazy danych.

  BACKUP DATABASE WideWorldImporters TO DISK ='NUL'

  Wskazówka :Kiedy wykonujesz kopię zapasową bazy danych na urządzeniu „NUL”, SQL Server nigdzie nie zapisuje pliku kopii zapasowej i unikasz usunięcia testowego pliku kopii zapasowej. Ale nie używaj tego polecenia w swoim środowisku produkcyjnym. Może to spowodować zerwanie łańcucha LSN.

Wykonaj następujące zapytanie:

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

sql_handle :ta wartość definiuje instrukcję SQL żądania. Ale ta wartość jest w formacie bitmapy. Z tego powodu musimy użyć funkcji wartości z tabeli sys.dm_exec_sql_text, aby przekonwertować wartość na zrozumiały tekst.

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

identyfikator bazy danych :ta wartość określa, która baza danych wysyła żądanie. Możemy połączyć to pole z sys.databases, aby uzyskać nazwę bazy danych.

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 :Ta wartość określa bieżący typ oczekiwania żądania. Jeśli czas wykonania zapytania trwa dłużej niż oczekiwano, możesz sprawdzić i określić typ oczekiwania na zapytanie.

transaction_isolation_level :ta wartość określa poziom transakcji przesłanego zapytania:

0=Nieokreślony

1=PrzeczytajNiezaangażowany

2=Przeczytaj zatwierdzone

3=Powtarzalne

4=Możliwość serializacji

5=Migawka

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 :Jest to identyfikator sesji, która blokuje żądanie. Jeśli ta kolumna ma wartość NULL, żądanie nie zablokowało żadnej sesji.

Demo :

• Otwórz SQL Server Management Studio i wykonaj następujące zapytanie.

  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

  

Otwórz nowe okno zapytania i wykonaj następujące zapytanie.

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

Otwórz kolejne nowe okno zapytania i uruchom to zapytanie DMV.

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

Dzięki tej demonstracji dowiedzieliśmy się, dlaczego drugie zapytanie jest zablokowane i która sesja jest zablokowana w żądaniu. Po uruchomieniu sp_BlitzWho 65 możesz znaleźć szczegóły blokowania i szczegóły zablokowanej sesji.

sp_BlitzWho 65

W tej demonstracji pobraliśmy szczegóły blokowania i blokowania sesji, a jednocześnie uzyskaliśmy szczegółowe informacje o tych sesjach. To jest bardzo prosta demonstracja, ale pokazuje, jak można rozwiązać problem.

W tym poście rozmawialiśmy o sys.sys.dm_exec_requests. Ten dynamiczny widok zarządzania daje nam elastyczność w uzyskaniu zrzutu obrazu podczas bieżącego szczebla żądania. Ponadto te szczegółowe dane mogą pomóc lub poprowadzić nas przez proces wykrywania problemu.

Referencje

• sys.dm_exec_requests (Transact-SQL)
• Monitorowanie Azure SQL Database za pomocą dynamicznych widoków zarządzania
• sys.dm_db_wait_stats (baza danych Azure SQL)

Przydatne narzędzie:

dbForge Monitor – dodatek do Microsoft SQL Server Management Studio, który pozwala śledzić i analizować wydajność SQL Server.