Nozioni di base su sys.dm_exec_requests

Il monitoraggio delle prestazioni e la risoluzione dei problemi in SQL Server sono un argomento vasto. In SQL Server 2005 sono state introdotte viste a gestione dinamica, note anche come DMV, che sono diventate uno strumento essenziale per la diagnosi dei problemi di prestazioni di SQL Server. Allo stesso tempo, possiamo usare le viste a gestione dinamica per il database SQL di Azure. Alcuni di essi possono differire dal database locale di SQL Server, ma la logica di lavoro è sempre la stessa. Microsoft dispone di un'ottima documentazione sulle visualizzazioni a gestione dinamica. L'unica cosa, è necessario prestare attenzione alla versione e alla convalida del prodotto delle viste a gestione dinamica. Ad esempio sys.dm_exec_request è disponibile per SQL Server 2008 e versioni successive e per il database SQL di Azure, ma sys.dm_db_wait_stats è valido solo per il database SQL di Azure.

In questo post parleremo delle basi di sys.dm_exec_request. sys.dm_exec_requests è una vista a gestione dinamica che restituisce solo le richieste attualmente in esecuzione. Significa che quando esegui la query sys.dm_exec_requests, acquisisce la richiesta che è in esecuzione in quel momento e non include alcun dato storico. Pertanto, questa visualizzazione è molto utile per monitorare le richieste in tempo reale. In altre parole, dà la risposta a "cosa sta succedendo nel mio server in questo momento?" Questa vista include molti dettagli, ma discuteremo i più importanti.

id_sessione :questo valore definisce un numero di identificazione della sessione. In SQL Server, gli ID di sessione uguali o inferiori a 50 sono dedicati al processo in background.

ora_di inizio :questo valore definisce la data e l'ora di inizio della richiesta.

stato :Questo valore definisce uno stato della richiesta. Gli stati disponibili sono:

• sfondo
• in esecuzione
• eseguibile
• dormire
• sospeso

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

background :questo tipo di stato definisce i processi in background. Alcuni di loro sono LAZY WRITER, CHECKPOINT e 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

in esecuzione :questo tipo di stato definisce che la richiesta viene elaborata dalla CPU.

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

eseguibile :Questo tipo di stato può essere semplicemente definito come una richiesta in attesa di esecuzione nella coda della CPU. Se rilevi molti processi eseguibili in sys.dm_exec_requests, può essere un sintomo della pressione della CPU. Questa metrica non è sufficiente per diagnosticare questo problema di prestazioni della CPU. Per questo motivo, dobbiamo supportare questo caso con più prove. Questo è importante per noi per dimostrare la nostra teoria. La vista di gestione dinamica sys.dm_os_wait_stats include una colonna che è signal_wait_time_ms. Questo valore di colonna può essere di aiuto per determinare il problema della CPU. La seguente query ci mostra la percentuale di Signalwait. Se questa metrica ha un valore elevato, molto probabilmente stai riscontrando un problema di prestazioni della CPU. Puoi approfondire la tua recensione in questo modo.

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

sospeso :questo tipo di stato definisce il processo di attesa di alcune risorse. Può essere I/O, LOCK e LATCH ecc. Come accennato in precedenza, possiamo utilizzare sys.dm_os_wait_stats vista a gestione dinamica per rilevare wait_time_ms.

dormire :significa che la richiesta è connessa a SQL Server ma attualmente non esegue alcun comando.

comando :Questa colonna definisce un tipo di comando in esecuzione. Allo stesso tempo, possiamo trovare informazioni aggiuntive per comandi particolari che è un rapporto di completamento. Secondo i libri online, questi sono;

ALTER INDEX RIORGANIZZA

Opzione AUTO_SHRINK con ALTER DATABASE

ARCHIVIO DI BACKUP

DBCC CHECKDB

GRUPPO DI CONTROLLO DBCC

TABELLA DI VERIFICA DBCC

DBCC INDEXDEFRAG

DBCC SHRINKDATABASE

SHRINKFILE DBCC

RECUPERO

RIPRISTINA DATABASE

ROLLBACK

CRITTOGRAFIA TDE

Dimostrazione :

• Collega il database master e avvia il backup di qualsiasi database.

  BACKUP DATABASE WideWorldImporters TO DISK ='NUL'

  Suggerimento :Quando si esegue il backup del database sul dispositivo "NUL", SQL Server non scrive un file di backup da nessuna parte e si evita l'eliminazione di un file di backup di prova. Ma non utilizzare questo comando nel tuo ambiente di produzione. Può causare la rottura della catena LSN.

Esegui la seguente query:

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

sql_handle :questo valore definisce l'istruzione SQL della richiesta. Ma questo valore è nel formato bitmap. Per questo motivo, è necessario utilizzare la funzione con valori di tabella sys.dm_exec_sql_text per convertire il valore in testo significativo.

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

id_database :questo valore definisce quale database effettua la richiesta. Possiamo unirci a questo campo con sys.databases per ottenere il nome del database.

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 :questo valore definisce il tipo di attesa corrente della richiesta. Se la durata dell'esecuzione della query richiede più tempo del previsto, puoi controllare e determinare il tipo di query di attesa.

transaction_isolation_level :questo valore definisce il livello di transazione della query inviata:

0=Non specificato

1=Leggi non confermato

2=Leggi Impegnato

3=Ripetibile

4=Serializzabile

5=Istantanea

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

id_sessione_blocco :È l'id della sessione che sta bloccando la richiesta. Se questa colonna è NULL, la richiesta non ha bloccato alcuna sessione.

Dimostrazione :

• Apri SQL Server Management Studio ed esegui la query seguente.

  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

  

Apri una nuova finestra di query ed esegui la query seguente.

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

Apri un'altra nuova finestra di query ed esegui questa query 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

Con questa dimostrazione, abbiamo scoperto il motivo per cui la seconda query è bloccata e quale sessione è bloccata la richiesta. Quando esegui sp_BlitzWho 65, puoi scoprire i dettagli del blocco e i dettagli della sessione bloccata.

sp_BlitzWho 65

In questa dimostrazione, abbiamo recuperato i dettagli del blocco e delle sessioni bloccate e, allo stesso tempo, abbiamo ottenuto i dettagli su queste sessioni. Questa è una dimostrazione molto semplice, ma mostra come risolvere il problema.

In questo post abbiamo parlato di sys.sys.dm_exec_requests. Questa visualizzazione a gestione dinamica ci offre la flessibilità di ottenere uno snapshot durante il rung corrente di una richiesta. Inoltre, questi dati dettagliati possono aiutarci o guidarci attraverso il processo di individuazione del problema.

Riferimenti

• sys.dm_exec_requests (Transact-SQL)
• Monitoraggio del database SQL di Azure tramite viste a gestione dinamica
• sys.dm_db_wait_stats (database SQL di Azure)

Strumento utile:

dbForge Monitor:componente aggiuntivo per Microsoft SQL Server Management Studio che consente di monitorare e analizzare le prestazioni di SQL Server.