Durante il monitoraggio delle prestazioni o la risoluzione di problemi come la lentezza del sistema, potrebbe essere necessario trovare o acquisire query con durata elevata, CPU elevata o che generano I/O significativi durante l'esecuzione. È possibile utilizzare DMV o Query Store per ottenere informazioni sulle prestazioni delle query, ma le informazioni in entrambe le origini sono aggregate. I DMV rappresentano la CPU media, l'I/O, la durata e così via per una query solo per il tempo in cui è rimasta nella cache. Query Store fornisce anche metriche medie per numerose risorse, ma è aggregato in un intervallo di tempo definito (ad es. 30 minuti o un'ora). Ci sono ovviamente soluzioni di monitoraggio di terze parti che sono più che in grado di darti tutto questo e altro (come SentryOne), ma per questo post ho voluto concentrarmi sugli strumenti nativi.
Se si desidera comprendere le prestazioni delle query per singole esecuzioni per individuare la query esatta o l'insieme di query che potrebbero rappresentare un problema, l'opzione più semplice è utilizzare gli eventi estesi. E uno dei modi più rapidi per iniziare è utilizzare XEvent Profiler, disponibile tramite SQL Server Management Studio (a partire dalla versione 17.3):
XEvent Profiler in SSMS
Utilizzo di base
Ci sono due opzioni per XEvent Profiler:Standard e TSQL. Per utilizzare uno dei due è sufficiente fare doppio clic sul nome. Dietro le quinte, viene creata e avviata una sessione evento definita internamente (se non esiste già) e il Visualizzatore dati live si apre immediatamente con lo stato attivo. Tieni presente che dopo aver avviato la sessione, apparirà anche sotto Gestione | Eventi estesi | Sessioni. Supponendo che tu abbia attività sul server, dovresti iniziare a visualizzare le voci nel visualizzatore in cinque secondi o meno.
Visualizzatore dati live (dopo aver fatto doppio clic per avviare la sessione standard)
Le sessioni Standard e TSQL condividono alcuni eventi, mentre lo Standard ne ha di più in totale. Ecco un elenco degli eventi per ciascuno:
Standard TSQL
sql_batch_starting sql_batch_starting
sql_batch_completed
rpc_starting
rpc_completed
logout logout
login login
existing_connection existing_connection
attention Se stai cercando di comprendere le informazioni sull'esecuzione della query, come il tempo impiegato per l'esecuzione della query o la quantità di I/O consumata, Standard è un'opzione migliore grazie ai due eventi completati. Per entrambe le sessioni, l'unico filtro consiste nell'escludere le query di sistema per gli eventi batch, rpc e di attenzione.
Visualizzazione e salvataggio dei dati
Se avviamo la sessione Standard ed eseguiamo alcune query, nel visualizzatore vediamo l'evento, il testo della query e altre informazioni utili come cpu_time, logical_reads e duration. Uno dei vantaggi dell'utilizzo di rpc_completed e sql_batch_completed è che viene visualizzato il parametro di input. In un caso in cui è presente una procedura memorizzata che presenta grandi variazioni nelle prestazioni, l'acquisizione del parametro di input può essere estremamente utile in quanto è possibile abbinare un'esecuzione che richiede più tempo con un valore specifico passato alla procedura memorizzata. Per trovare un tale parametro, dobbiamo ordinare i dati in base alla durata, cosa che non possiamo fare quando il feed di dati è attivo. Per eseguire qualsiasi tipo di analisi, il feed di dati deve essere interrotto.
Interruzione del feed di dati nel visualizzatore live
Ora che le mie query non scorrono più in modo sfocato, posso fare clic sulla colonna della durata per ordinare i miei eventi. La prima volta che faccio clic, verrà ordinato in ordine crescente e, poiché sono pigro e non voglio scorrere in basso, farò di nuovo clic per ordinare in ordine decrescente.
Eventi ordinati per durata decrescente
Ora posso vedere tutti gli eventi che ho catturato in ordine dalla durata più alta a quella più bassa. Se stavo cercando una stored procedure specifica che fosse lenta, potrei scorrere verso il basso finché non la trovo (il che potrebbe essere doloroso) oppure potrei raggruppare o filtrare i dati. Il raggruppamento è più semplice qui, perché conosco il nome della procedura memorizzata.
Il nome_oggetto viene visualizzato nella parte superiore del visualizzatore, ma facendo clic su qualsiasi evento rpc_completed vengono visualizzati tutti gli elementi acquisiti nel riquadro Dettagli. Fare clic con il pulsante destro del mouse su nome_oggetto, che lo evidenzierà, e selezionare Mostra colonna nella tabella.
Aggiungi nome_oggetto al visualizzatore di dati
Nel riquadro in alto ora posso fare clic con il pulsante destro del mouse su nome_oggetto e selezionare Raggruppa per questa colonna. Se espando gli eventi in usp_GetPersonInfo e poi li ordino di nuovo per durata, ora vedo che l'esecuzione con PersonID=3133 ha avuto la durata più alta.
Eventi raggruppati per nome_oggetto, usp_GetPersonInfo ordinati per durata decrescente
Per filtrare i dati:utilizzare il pulsante Filtri..., l'opzione di menu (Eventi estesi | Filtri...) o CTRL + R per visualizzare una finestra in cui ridurre il set di risultati in base ai diversi campi visualizzati. In questo caso abbiamo filtrato su object_name =usp_GetPersonInfo, ma potresti anche filtrare su campi come server_principal_name o client_app_name, poiché quelli sono stati raccolti.
Vale la pena sottolineare che né la sessione Standard né quella TSQL vengono scritte su un file. In effetti, non esiste un obiettivo per nessuna delle due sessioni di eventi (se non sapevi che puoi creare una sessione di eventi senza una destinazione, ora lo sai). Se desideri salvare questi dati per ulteriori analisi, devi eseguire una delle seguenti operazioni:
- Interrompi il feed di dati e salva l'output in un file tramite il menu Eventi estesi (Esporta in | File XEL...)
- Interrompi il feed di dati e salva l'output in una tabella in un database tramite il menu Eventi estesi (Esporta in | Tabella...)
- Modifica la sessione dell'evento e aggiungi event_file come destinazione.
L'opzione 1 è la mia raccomandazione, in quanto crea un file su disco che puoi condividere con altri e rivedere in seguito in Management Studio per ulteriori analisi. All'interno di Management Studio hai la possibilità di filtrare i dati non rilevanti, ordinare per una o più colonne, raggruppare i dati ed eseguire calcoli (ad es. medie). Puoi farlo se i dati sono una tabella, ma devi scrivere il TSQL; l'analisi dei dati nell'interfaccia utente è più semplice e veloce.
Modifica delle sessioni di XEvent Profiler
È possibile modificare le sessioni di eventi Standard e TSQL e le modifiche apportate persisteranno durante il riavvio dell'istanza. Tuttavia, se le sessioni di eventi vengono eliminate (dopo aver apportato modifiche), verranno ripristinate ai valori predefiniti. Se ti ritrovi a apportare continuamente le stesse modifiche, ti suggerisco di creare uno script per le modifiche e creare una nuova sessione di eventi che persisterà anche durante i riavvii. Ad esempio, se osserviamo l'output catturato finora, possiamo vedere che sono state eseguite sia le query ad hoc che le stored procedure. E mentre è fantastico poter vedere i diversi parametri di input per le stored procedure, non vedo le singole istruzioni in esecuzione con questo insieme di eventi. Per ottenere queste informazioni, dovrei aggiungere l'evento sp_statement_completed.
Tieni presente che sia le sessioni di eventi Standard che TSQL sono progettate per essere leggere. Gli eventi statement_completed verranno attivati più frequentemente rispetto agli eventi batch e rpc, quindi può esserci un sovraccarico maggiore quando questi eventi fanno parte di una sessione di eventi. Quando utilizzo gli eventi di istruzione, io molto consiglia di includere predicati aggiuntivi. Come promemoria, gli eventi rpc e batch stanno solo filtrando le query di sistema:non ci sono altri predicati. In generale, raccomando anche predicati aggiuntivi per questi eventi, soprattutto per un carico di lavoro ad alto volume.
Se sei preoccupato che l'esecuzione delle sessioni Standard o TSQL possa causare un calo delle prestazioni sul tuo sistema, tieni presente che il Visualizzatore dati live si disconnetterà se sta creando un sovraccarico sul sistema. Questa è una grande sicurezza, ma sarei comunque premuroso quando utilizzo queste sessioni di eventi. Ritengo che siano un fantastico primo passo per la risoluzione dei problemi, in particolare per coloro che non conoscono SQL Server o eventi estesi. Tuttavia, se hai il Visualizzatore dati in tempo reale aperto e ti allontani dal tuo computer, la sessione dell'evento continua a essere eseguita . L'arresto o la chiusura di Live Data Viewer interromperà la sessione dell'evento, che è ciò che consiglio al termine della raccolta dei dati o della risoluzione dei problemi.
Per le sessioni di eventi che si desidera eseguire per un periodo di tempo più lungo, creare sessioni di eventi separate che scrivano nella destinazione event_file e abbiano predicati appropriati. Se hai bisogno di ulteriori informazioni su come iniziare con gli eventi estesi, dai un'occhiata alla sessione che ho fornito a SQLBits l'anno scorso sulla migrazione da Profiler a Eventi estesi.
