Ebbene si, dopo anni di onoratissimo servizio anche per Sql Server Profiler è giunta l'ora della meritata pensione...
Ma chi lo sostituirà !?!?! Gli Extended Events !!!
Gli Extended Events sono stati introdotti sin dall'edizione 2008 ma il loro utilizzo era un tantino macchinoso dato che nel Management studio 2008 non era presente nessun tool di configurazione e a meno che non si installasse questo Addin la configurazione doveva essere implementata via T-SQL.
Ma cosa sono questi Extended Events (d'ora in poi EE) ? Sono la nuova architettura che consente ai DBA di raccogliere una vastissima gamma di informazioni relative all'Engine di SQL Server per operazioni di monitoring, debug e troubleshooting.
Sono molto facili da comprendere e da utilizzare e nel Management Studio di SQL 2012 è integrata anche la loro configurazione attraverso una comoda UI.
Ma perché mettere in pensione SQL Server Profiler ?
Perché è molto invasivo e molto pesante mentre gli extended events sono estremamente leggeri e scalabili.
A dirla tutta SQL Server profiler non va totalmente in pensione, resterà il tool di Trace e Replay per Analysis Services.
Ma cosa posso implementare con gli EE ?
Praticamente tutto ciò che era implementabile con SQL Profiler....
Facciamo un esempio.... Come identificare un problema di DeadLock con gli EE.
Genero un DB di test su cui causerò un DeadLock
Use Master Go Create Database ExtEvnDb Go Use ExtEvnDb Go Create table Tab_A ( idA int ) Go Create table Tab_B ( idB int ) Go Insert into Tab_A values(1),(2),(3) Insert into Tab_B values(4) Go Select * from Tab_A Select * from Tab_B Go
Prepariamo ora la sessione di monitoring utilizzando gli EE.
Dal management studio ci connettiamo all'istanza di SQL che vogliamo monitorare e selezioniamo la folder Management, all'interno della quale troviamo
il configuratore degli EE
Nella page General del configuratore diamo un nome alla sessione, nel mio caso DeadLockMonitor.
Possiamo configurare se l'event session deve essere avviata automaticamente allo start dell'engine e/o al termine della configurazione.
Nella page Events possiamo selezionare gli eventi necessari alla sessione di monitoring.
Un Event altro non è che un'azione, un'attività scatenata da un'operazione all'interno dell'engine di SQL Server.
Utilizzando la textbox Event Library ricerchiamo gli eventi adeguati alle nostre necessità, digitando il nome dell'evento stesso o parte di esso.
Per ogni evento selezionato il configuratore mette a diposizione una descrizione e la lista dei campi ad esso associati, cioè quali informazioni possiamo estrarre dall'evento stesso.
Per monitorare un DeadLock ci possono essere utili i seguenti eventi:
1. xml_deadlock_report = Grafico che rappresenta il deadlock
2. lock_deadlock = Evento di deadlock
3. sql_batch_starting = Avvio di un batch T-Sql
4. sql_batch_completed = Conclusione di un batch T-Sql
Una volta selezionati gli Eventi necessari passiamo alla loro configurazione premendo il button Configure
Il tab Global Fields(Actions) consente di selezionare i campi che devono essere restituiti dall'evento selezionato.
Per monitorare un DeadLock ci possono essere utili i seguenti campi:
1. client_app_name = Nome dell'applicazione che si connette a SQL Server
2. event_sequence = Numero sequenziale che identifica l'ordine delle operazioni
3. session_id = Id della sessione
4. transaction_id = Id della transazione
Possiamo poi filtrare quali eventi tracciare. Per esempio vogliamo monitorare gli eventi selezionati ma solo quelli che si verificano in un determinato Db o che nel testo del comando hanno una stringa particolare.
NB: Non impostare il filtro sull'evento xml_deadlock_graph, lo perderemmo....
Nella page Data Storage configuriamo dove gli eventi debbano essere collezionati.
Un target è un consumatore di eventi, una locazione contenente gli eventi che si sono verificati. Possiamo collezionare gli eventi su file, in un buffer etc... e possiamo avere più target per ogni sessione di EE.
Un target può processare gli eventi in modo Sincrono o Asincrono.
A questo punto la configurazione è terminata, Click su OK e l'EE Session verrà avviata e comincerà a monitorare gli eventi selezionati.
NB: la session verrà avviata se abbiamo messo il flag di auto start nella configurazione.
In caso contrario click dx del mouse sulla sessione di EE e selezioniamo Start o Stop Session.
Vediamo di causare un dead lock
Dal management studio apro 2 connessioni avendo cura di utilizzare la Keyword Application Name per simulare l'accesso da parte di una applicazione utente.
La prima connessione si chiamerà Application_1, la seconda Application_2
Ecco il command di Application_1
Use [ExtEvnDb] Go Begin tran Update Tab_A set ida = idA + 10 --Eseguire la prima parte del command di application_2 Update Tab_B Set idb = idb + 10 --Eseguire la seconda parte del command di application_2 commit
mentre questo è il command di Application_2
Use [ExtEvnDb] Go Begin tran Update Tab_B Set idb = idb + 30 --Eseguire la seconda parte del command di application_1 Update Tab_A set ida = idA + 30 --DeadLock Error commit
La seguenza di operazioni sarà:
1. Application_1 : Begin tran Update Tab_A set ida = idA + 10
2. Application_2 : Begin tran Update Tab_B Set idb = idb + 30
3. Application_1 : Update Tab_B Set idb = idb + 10
4. Application_2 : Update Tab_A set ida = idA + 30
Ecco il DeadLock
Come facciamo a verificare la nostra session di EE per reperire le info relative al DeadLock?
Utilizzando management studio...
Ed ecco che si aprono gli eventi consumati dal target
L'evento lock_deadlock mi indica che si è verificato un deadlock e l'evento xml_deadlock_graph mostra il grafico
Il grafico indica che la session id 53 è stata killata per risolvere un deadlock con la session id 51. (SQL fa il Kill della sessione per cui è più semplice effettuare il rollback, sostanzialmente fa il kill della transazione più piccola)
Quale è il comando che ha scatenato il deadlock ?
Grazie agli eventi ed ai fields selezionati in fase di configurazione possiamo risalire alla sequenza di operazioni e alle applicazioni che hanno causato il deadlock.
Così come con il profiler potevamo creare delle trace da inviare al cliente, lo stesso lo possiamo implementare con gli EE.
Generiamo lo script di configurazione da inviare al cliente ed il gioco è fatto....
Il cliente poi non farà altro che inviarci uno o più file *.xel che potremo leggere facendo drag & drop in Management Studio.
Possiamo attivare più session EE contemporaneamente e per ciascuna di esse selezionare Events, Actions, Filter e Targets personalizzati con un overhead per l'engine di molto inferiore a quello che avremmo utilizzando SQL Trace o addirittura il SQL Server Profiler.
Qui trovate un interessante post sull'overhead dato da EE e SQL Server Profiler.
Quindi buon troubleshooting con gli Extended Events !!!
Ciao
Luca
Nessun commento:
Posta un commento