Basisprincipes van sys.dm_exec_requests

Prestatiebewaking en probleemoplossing in SQL Server is een uitgebreid onderwerp. In SQL Server 2005 zijn dynamische beheerweergaven, ook wel DMV's genoemd, geïntroduceerd en zijn een essentieel hulpmiddel geworden voor het diagnosticeren van prestatieproblemen met SQL Server. Tegelijkertijd kunnen we dynamische beheerweergaven gebruiken voor Azure SQL Database. Sommige kunnen verschillen van de on-premise database van SQL Server, maar de logica van het werk is nog steeds hetzelfde. Microsoft heeft zeer goede documentatie over dynamische beheerweergaven. Het enige is dat u voorzichtig moet zijn met de versie- en productvalidatie van dynamische beheerweergaven. Zoals sys.dm_exec_request is beschikbaar voor SQL Server 2008 en latere versies en voor Azure SQL-database, maar sys.dm_db_wait_stats is alleen geldig voor Azure SQL-database.

In dit bericht zullen we het hebben over de basisprincipes van de sys.dm_exec_request. sys.dm_exec_requests is een dynamische beheerweergave die alleen de momenteel uitgevoerde verzoeken retourneert. Het betekent dat wanneer u de sys.dm_exec_requests-query uitvoert, het snapshots verzoekt dat in die tijd wordt uitgevoerd en geen historische gegevens bevat. Daarom is deze weergave erg handig voor het bewaken van realtime verzoeken. Met andere woorden, het geeft het antwoord op "wat gebeurt er op dit moment op mijn server?" Deze weergave bevat veel details, maar we zullen de belangrijkste bespreken.

session_id :Deze waarde definieert een sessie-identificatienummer. In SQL Server worden sessie-ID's die gelijk zijn aan of kleiner zijn dan 50 toegewezen aan het achtergrondproces.

start_time :Deze waarde definieert de startdatum en -tijd van het verzoek.

status :Deze waarde definieert een status van de aanvraag. De beschikbare statussen zijn:

• achtergrond
• rennen
• uitvoerbaar
• slapen
• opgeschort

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

achtergrond :Dit statustype definieert de achtergrondprocessen. Sommigen van hen zijn LAZY WRITER, CHECKPOINT en 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

hardlopen :Dit statustype definieert dat het verzoek wordt verwerkt door de CPU.

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

uitvoerbaar :Dit statustype kan eenvoudig worden gedefinieerd als een verzoek dat in de CPU-wachtrij wacht om te worden uitgevoerd. Als u veel uitvoerbare processen in sys.dm_exec_requests detecteert, kan dit een symptoom zijn van CPU-druk. Deze statistiek is niet voldoende om dit probleem met de CPU-prestaties te diagnosticeren. Om deze reden moeten we deze zaak met meer bewijs ondersteunen. Dit is belangrijk voor ons om onze theorie te bewijzen. De dynamische beheerweergave sys.dm_os_wait_stats bevat een kolom die signal_wait_time_ms is. Deze kolomwaarde kan een hulpmiddel zijn om het CPU-probleem te bepalen. De volgende query toont ons het percentage van Signalwait. Als deze statistiek een hoge waarde heeft, heeft u hoogstwaarschijnlijk te maken met een CPU-prestatieprobleem. U kunt uw beoordeling op deze manier verdiepen.

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

opgeschort :Dit statustype definieert het wachtproces van een bepaalde bron. Het kan I/O, LOCK en LATCH enz. zijn. Zoals hierboven vermeld, kunnen we de sys.dm_os_wait_stats gebruiken dynamische beheerweergave om wait_time_ms te detecteren.

slapen :Dit betekent dat het verzoek is verbonden met SQL Server maar momenteel geen opdrachten uitvoert.

opdracht :Deze kolom definieert een type commando dat wordt uitgevoerd. Tegelijkertijd kunnen we aanvullende informatie vinden voor bepaalde opdrachten, wat een voltooiingsratio is. Volgens de online boeken zijn dit;

ALTER INDEX REORGANISEREN

AUTO_SHRINK optie met ALTER DATABASE

BACK-UPDATABASE

DBCC CHECKDB

DBCC CHECKFILEGROUP

DBCC-CONTROLETABEL

DBCC INDEXDEFRAG

DBCC SHRINKDATABASE

DBCC SHRINKFILE

HERSTEL

DATABASE HERSTELLEN

ROLLBACK

TDE-ENCRYPTIE

Demo :

• Verbind de hoofddatabase en start de back-up voor elke database.

  BACKUP DATABASE WideWorldImporters TO DISK ='NUL'

  Tip :Wanneer u de databaseback-up naar het "NUL" -apparaat brengt, schrijft SQL Server nergens een back-upbestand en vermijdt u het verwijderen van een testback-upbestand. Gebruik deze opdracht echter niet in uw productieomgeving. Het kan ertoe leiden dat de LSN-keten wordt verbroken.

Voer de volgende vraag uit:

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

sql_handle :Deze waarde definieert de SQL-instructie van de aanvraag. Maar deze waarde is in het bitmapformaat. Om deze reden moeten we de sys.dm_exec_sql_text tabelwaardefunctie gebruiken om de waarde om te zetten in betekenisvolle 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

database_id :Deze waarde definieert welke database de aanvraag doet. We kunnen dit veld samenvoegen met sys.databases om de databasenaam te krijgen.

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 :Deze waarde definieert het huidige wachttype van de aanvraag. Als de uitvoering van de query langer duurt dan verwacht, kunt u het wachttype van de query controleren en bepalen.

transaction_isolation_level :Deze waarde definieert het transactieniveau van de ingediende vraag:

0=Niet gespecificeerd

1=ReadUncomitted

2=ReadCommitted

3=Herhaalbaar

4=Serialiseerbaar

5=Momentopname

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 :Het is de id van de sessie die het verzoek blokkeert. Als deze kolom NULL is, heeft het verzoek geen enkele sessie geblokkeerd.

Demo :

• Open SQL Server Management Studio en voer de volgende query uit.

  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

  

Open een nieuw queryvenster en voer de volgende query uit.

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

Open nog een nieuw queryvenster en voer deze DMV-query uit.

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

Met deze demonstratie hebben we de reden ontdekt waarom de tweede query wordt geblokkeerd en welke sessie het verzoek blokkeert. Wanneer u sp_BlitzWho 65 uitvoert, kunt u de details van het blokkeren en de geblokkeerde sessiedetails vinden.

sp_BlitzWho 65

In deze demonstratie hebben we de details van blokkerende en geblokkeerde sessies opgehaald en tegelijkertijd de details over deze sessies. Dit is een zeer eenvoudige demonstratie, maar het laat zien hoe het probleem kan worden opgelost.

In dit bericht hebben we het gehad over sys.sys.dm_exec_requests. Deze dynamische beheerweergave geeft ons de flexibiliteit om een ​​momentopname te krijgen tijdens de huidige trede van een verzoek. Deze gedetailleerde gegevens kunnen ons ook helpen of begeleiden bij het ontdekken van het probleem.

Referenties

• sys.dm_exec_requests (Transact-SQL)
• Bewaking van Azure SQL Database met dynamische beheerweergaven
• sys.dm_db_wait_stats (Azure SQL Database)

Handig hulpmiddel:

dbForge Monitor – add-in voor Microsoft SQL Server Management Studio waarmee u de prestaties van SQL Server kunt volgen en analyseren.