Grunderna i sys.dm_exec_requests

Prestandaövervakning och felsökning i SQL Server är ett stort ämne. I SQL Server 2005 har dynamiska hanteringsvyer, även kända som DMV, introducerats och blev ett viktigt hjälpverktyg för att diagnostisera SQL Server-prestandaproblem. Samtidigt kan vi använda dynamiska hanteringsvyer för Azure SQL Database. Vissa av dem kan skilja sig från SQL Server-databasen på plats, men logiken i arbetet är fortfarande densamma. Microsoft har mycket bra dokumentation om dynamiska hanteringsvyer. Det enda, du måste vara försiktig med versionen och produktvalideringen av dynamiska hanteringsvyer. Till exempel sys.dm_exec_request är tillgängligt för SQL Server 2008 och senare versioner och för Azure SQL-databas men sys.dm_db_wait_stats är endast giltigt för Azure SQL-databasen.

I det här inlägget kommer vi att prata om grunderna i sys.dm_exec_request. sys.dm_exec_requests är en dynamisk hanteringsvy som endast returnerar de förfrågningar som för närvarande körs. Det betyder att när du kör sys.dm_exec_requests-frågan, tar den ögonblicksbilder av begäran som körs under den tiden och inte inkluderar några historiska data. Därför är den här vyn väldigt praktisk för att övervaka förfrågningar i realtid. Med andra ord, det ger svaret på "vad händer på min server just nu?" Denna vy innehåller många detaljer men vi kommer att diskutera de viktigaste.

session_id :Detta värde definierar ett sessionsidentifikationsnummer. I SQL Server är sessions-ID:n som är lika med eller mindre än 50 dedikerade till bakgrundsprocessen.

starttid :Detta värde definierar startdatum och tid för begäran.

status :Detta värde definierar en status för begäran. Tillgängliga statusar är:

• bakgrund
• kör
• körbar
• sover
• avstängd

SELECT DISTINCT statusFROM sys.dm_exec_requestsWHERE session_id <>@@SPID

bakgrund :Denna statustyp definierar bakgrundsprocesserna. Några av dem är LAZY WRITER, CHECKPOINT och LOG WRITER.

välj session_id, kommando, os_thread_id från sys.dm_exec_requests som r join sys.dm_os_workers as w on r.task_address =w.task_address gå med sys.dm_os_threads som t på t.thread_address =w.thread_address =w.thread_address där 5 sessionsid_address där 5 session_id

löpar :Denna statustyp definierar att begäran bearbetas av CPU.

 välj * från sys.dm_exec_requests där status='running' och session_id <>@@SPID

körbar :Denna statustyp kan enkelt definieras som en begäran som väntar i CPU-kön för att köras. Om du upptäcker många körbara processer i sys.dm_exec_requests kan det vara ett symptom på CPU-tryck. Detta mått räcker inte för att diagnostisera detta problem med CPU-prestanda. På grund av denna anledning måste vi stödja detta fall med mer bevis. Detta är viktigt för oss att bevisa vår teori. Den dynamiska hanteringsvyn sys.dm_os_wait_stats innehåller en kolumn som är signal_wait_time_ms. Detta kolumnvärde kan vara en hjälp för att fastställa CPU-problemet. Följande fråga visar oss procentandelen av Signalwait. Om detta mått har ett högt värde, har du troligen problem med CPU-prestanda. Du kan fördjupa din recension på detta sätt.

---https://sqlserverperformance.wordpress.com/page/146/---Glenn Berrys SQL Server Performance SELECT signal_wait_time_ms=SUM(signal_wait_time_ms) ,'%signal (cpu) waits' =CAST(100.0 * SUMMA) (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) /NUM(wait_time_ms - signal_wait) 20,2))FRÅN sys.dm_os_wait_stats;

avstängd :Denna statustyp definierar vänteprocessen för någon resurs. Det kan vara I/O, LOCK och LATCH etc. Som nämnts ovan kan vi använda sys.dm_os_wait_stats dynamisk hanteringsvy för att upptäcka wait_time_ms.

sover :Det betyder att begäran är ansluten till SQL Server men för närvarande inte kör några kommandon.

kommando :Denna kolumn definierar en typ av kommando som exekveras. Samtidigt kan vi hitta ytterligare information för särskilda kommandon, vilket är ett kompletteringsförhållande. Enligt onlineböckerna är dessa;

ÄNDRA INDEX OMORGANISERA

AUTO_SHRINK-alternativet med ALTER DATABASE

SÄKERHETSDATABAS

DBCC CHECKDB

DBCC CHECKFILEGROUP

DBCC KONTROLLTABELL

DBCC INDEXDEFRAG

DBCC SHRINKDATABASE

DBCC SHRINKFILE

ÅTERHÄLLNING

ÅTERSTÄLL DATABAS

ÅTERSTÄLLNING

TDE KRYPTERING

Demo :

• Anslut huvuddatabasen och starta säkerhetskopieringen för valfri databas.

  BACKUP DATABASE WideWorldImporters TO DISK ='NUL'

  Tips :När du tar databassäkerhetskopieringen till "NUL"-enheten, skriver SQL Server ingen säkerhetskopia någonstans och du undviker radering av en testfil för säkerhetskopiering. Men använd inte det här kommandot i din produktionsmiljö. Det kan leda till att LSN-kedjan bryts.

Kör följande fråga:

SELECT command,percent_complete ,*FROM sys.dm_exec_requestsWHERE session_id <>@@SPIDand session_id>50 och command='BACKUP DATABASE'

sql_handle :Detta värde definierar SQL-satsen för begäran. Men detta värde är i bitmappsformatet. Av denna anledning måste vi använda funktionen sys.dm_exec_sql_text table-valued för att konvertera värdet till meningsfull text.

välj session_id ,command , sqltxt.text ,database_idfrom sys.dm_exec_requests reqCROSS APPLY sys.dm_exec_sql_text(req.sql_handle) som sqltxtwhere session_id<>@@SPID OCH session_id>50 

 
 

 database_id :Detta värde definierar vilken databas som gör begäran. Vi kan ansluta detta fält med sys.databases för att få databasnamnet.
 
select session_id ,command , sqltxt.text ,db.namefrom sys.dm_exec_requests reqCROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxtinner join sys.databases db =where-session session_id>50
 

 wait_type :Detta värde definierar den aktuella väntetypen för begäran. Om varaktigheten av exekveringen av frågan tar längre tid än förväntat kan du kontrollera och bestämma väntetypen för fråga.
 

 
 

 transaction_isolation_level :Detta värde definierar transaktionsnivån för den skickade frågan:
 

 0=Ospecificerat
 

 1=LäsOengagerad
 

 2=ReadCommitted
 

 3=Repeterbar
 

 4=Serialiserbar
 

 5=Ögonblicksbild
 
select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level,CASE transaction_isolation_levelWHEN 0 SÅ 'Ospecificerat'NÄR 1 SÅ 'ReadUncomitted'WHEN 2 THENHEN 'WHEN'Readable THENHEN 4 SEDAN 'Serialisable'WHEN 5 DÅ 'Snapshot'ENDAS isolation_level_namefrom sys.dm_exec_requests reqCROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxtinner join [email protected]_session 50
 

 
 

 blocking_session_id :Det är sessionens ID som blockerar begäran. Om denna kolumn är NULL, har begäran inte blockerat någon session.
 

 Demo :
 
 
Öppna SQL Server Management Studio och kör följande fråga.
SLÄPP TABELL OM FINNS TestPerfomonGOCREATE TABLE TestPerfomon(ID INT ,Nm VARCHAR(100))INSERT INTO TestPerfomonVALUES(1,1)GOBEGIN TRANSUPDATEN TestPerfomon 'WHERE ID=1SELECT @@SPID AS blocking_session_id
 

 
 
 

 Öppna ett nytt frågefönster och kör följande fråga.
 
STÄLL IN TRANSAKTIONSISOLATIONSNIVÅ Serialiserbar BÖRJA ÖVERFÖRA TestPerfomon SET Nm='3'WHERE ID=1
 

 Öppna ytterligare ett nytt frågefönster och kör denna DMV-fråga.
 
select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level,CASE transaction_isolation_levelWHEN 0 SÅ 'Ospecificerat'NÄR 1 SÅ 'ReadUncomitted'WHEN 2 THENHEN 'WHEN'Readable THENHEN 4 SEDAN 'Serialiserbar' NÄR 5 SEDAN 'Ögonblicksbild'ENDAS isolation_level_name ,blocking_session_idfrom sys.dm_exec_requests reqCROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as join sqlwherestxtsession_d@dsp session_id>50
 

 
 

 Med den här demonstrationen fick vi reda på orsaken till att den andra frågan blockeras och vilken session som blockerade begäran. När du kör sp_BlitzWho 65 kan du ta reda på detaljerna om blockering och information om blockerad session.
 
sp_BlitzWho 65
 

 I den här demonstrationen hämtade vi detaljerna om blockering och blockerade sessioner och samtidigt fick vi information om dessa sessioner. Detta är en mycket grundläggande demonstration men den visar hur problemet kan lösas.
 

 I det här inlägget pratade vi om sys.sys.dm_exec_requests. Denna dynamiska hanteringsvy ger oss flexibiliteten att få en ögonblicksbild under det aktuella steget av en begäran. Dessa detaljerade data kan också hjälpa eller vägleda oss genom processen för att upptäcka problemet.
 

 Referenser 
 
 
sys.dm_exec_requests (Transact-SQL)
 
Övervaka Azure SQL Database med dynamiska hanteringsvyer
 
sys.dm_db_wait_stats (Azure SQL Database)
 
 

 
 
Användbart verktyg:
 

 dbForge Monitor – tillägg för Microsoft SQL Server Management Studio som låter dig spåra och analysera SQL Server-prestanda.