XEVENTS SYSTEM HEALTH

Olá pessoal tudo certo? No assunto de hoje vou continuar a falar sobre os xevents, desta vez sobre a system_health, já ouviram falar sobre?

Com a chegada dos extended events, no SQL Server 2008, foi introduzida uma sessão default de extend events chamada de system_health que se inicia automaticamente junto com o serviço do SQL Server. O seu objetivo é dar base para o troubleshooting, mas com um foco de suporte, identificando problemas críticos que podem afetar adversamente a carga de trabalho.

Para uma visão melhor de como ela pode ser útil em um troubleshotting, abaixo está a listagem oficial dos eventos que ela pode coletar:

-The sql_text and session_id for any sessions that encounter an error that has a severity >=20.
-The sql_text and session_id for any sessions that encounter a memory-related error. The errors include 17803, 701, 802, 8645, 8651, 8657 and 8902.
-A record of any non-yielding scheduler problems. (These appear in the SQL Server error log as error 17883.)
-Any deadlocks that are detected.
-The callstack, sql_text, and session_id for any sessions that have waited on latches (or other interesting resources) for > 15 seconds.
-The callstack, sql_text, and session_id for any sessions that have waited on locks for > 30 seconds.
-The callstack, sql_text, and session_id for any sessions that have waited for a long time for preemptive waits. The duration varies by wait type. A preemptive wait is where SQL Server is waiting for external API calls.
-The callstack and session_id for CLR allocation and virtual allocation failures.
-The ring_buffer events for the memory broker, scheduler monitor, memory node OOM, security, and connectivity.
-System component results from sp_server_diagnostics.
-Instance health collected by scheduler_monitor_system_health_ring_buffer_recorded.
-CLR Allocation failures.
-Connectivity errors using connectivity_ring_buffer_recorded. 
-Security errors using security_error_ring_buffer_recorded.


Pela interface do SQL Server Management Studio podemos chegar na system_health indo em “Management > Extended Events > Sessions” conforme imagem abaixo:


Os arquivos XEL gerados pela sessão system_health ficam armazenados no mesmo diretório do ERRORLOG:

 

Clicando duas vezes em cada um deles você verá as informações no Management Studio:


Um outra forma de verificar o que foi coletado pelos arquivos XEL é através da utilização de queries utilizando a function sys.fn_xe_file_target_read_file, alguns exemplos podem ser encontrados no site abaixo: 


A Microsoft recomenda que a system_health não seja apagada, porém caso ocorra, é possível restaurar a mesma através do script u_tables.sql, localizado no diretório de instalação do seu SQL Server: 

C:\Program Files\Microsoft SQL Server\MSSQL11.<instanceid>\MSSQL\Install 

Outros links utilizados para escrita deste post:  


Espero que tenham gostado pessoal e até a próxima!

Desapegue do SQL Server Profiler! Use Extended Events!!!

Olá Pessoal! Tudo certo? Espero que sim!

Ainda continuando a falar sobre Extended Events, na minha opinião eles ainda não ganharam a atenção que deveriam, por isso resolvi montar este post gerando um comparativo entre eles e o SQL Server Profiler. De acordo com o Books Online do produto, o SQL Server Profiler está marcado como “deprecated” porque pode ser totalmente substituído (com vantagens) pelos eventos estendidos.

Mapeando eventos entre o SQL Server Profiler e Extended Events...        

Bom, para facilitar nossa vida, a partir do SQL Server 2012 surgiram algumas DMV’s relacionadas a Extended Events que se combinadas podem nos dar uma informação muito útil, quais eventos gerados pelo SQL Server Profiler são equivalentes aos eventos gerados pelo Extended Events, não precisamos escrever o script pois ele já existe oficialmente, abaixo está o mesmo e o link onde obtê-lo:

USE MASTER;
GO
SELECT DISTINCT
   tb.trace_event_id,
   te.name AS 'Event Class',
   em.package_name AS 'Package',
   em.xe_event_name AS 'XEvent Name',
   tb.trace_column_id,
   tc.name AS 'SQL Trace Column',
   am.xe_action_name as 'Extended Events action'
FROM (sys.trace_events te LEFT OUTER JOIN sys.trace_xe_event_map em
   ON te.trace_event_id = em.trace_event_id) LEFT OUTER JOIN sys.trace_event_bindings tb
   ON em.trace_event_id = tb.trace_event_id LEFT OUTER JOIN sys.trace_columns tc
   ON tb.trace_column_id = tc.trace_column_id LEFT OUTER JOIN sys.trace_xe_action_map am
   ON tc.trace_column_id = am.trace_column_id
ORDER BY te.name, tc.name


Ao rodar este script, veremos algo similar ao que esta na imagem abaixo:


A coluna “Event Class”, diz respeito ao nome do evento no SQL Server Profiler, para saber qual evento corresponde à ele no Extended Events, basta olharmos o nome que está na coluna “XEvent Name”, neste caso da imagem, temos que o “SP:Completed” do SQL Server Profiler corresponde ao evento do Extended Events chamado module_end. A coluna “SQL Trace Column” diz respeito as colunas que podemos colocar algum tipo de filtro no evento do SQL Server Profiler, olhando a coluna “Extended Events action”, teremos a correspondência para esta coluna no evento coletado pelo Extended Events, no caso da imagem, temos que a coluna “ApplicationName” do SQL Server Profiler, corresponde a coluna “client_app_name” no Extended Events.

Alguns exemplos práticos...

No Profiler, se eu quisesse coletar o término da execução de uma stored procedure, eu coletaria o evento “SP:Completed”, pois bem, vamos configurar uma coleta simples do profiler que colete este evento selecionando apenas as colunas “database_id”, “spid”, “database_name” e “text data”, conforme imagem abaixo:

Coloque o profiler para executar, volte no SQL Server e execute a procedure sp_readerrorlog, veja que o evento será coletado pelo Profiler:

 
Como seria esta coleta usando Extended Events?

Bom, primeiramente pare e encerre o SQL Server Profiler. Com a ajuda daquela query no início do post, já descobrimos qual evento no Extended Events equivale ao “SP:Completed” do SQL Server Profiler, no Management Studio, expanda Management>Extended Events, clique com o direto em “Sessions” e depois clique em “New Session...”.

Na aba General, Em “Session Name” vamos definir o nome para nossa coleta, vou chamar de “XCompare”, deixe marcadas as opções “Start the event session immediately after session creation” e “Watch live data on screen as it is captured”.

Na aba “Events”, na lista de eventos selecione o evento module_end e clique em “>”:

 
Clique no botão “Configure” localizado a direita na parte superior da janela, na lista e selecione “database_id”, “database_name”, “session_id” e “sql_text”, agora podemos clicar em “OK”.

Nossa coleta já está pronta, rode a procedure sp_readerrorlog e veja que na aba “Live Data” o evento foi coletado da mesma forma que ocorreu usando o SQL Server Profiler:

 
Informação adicional...

Você pode ainda converter scripts mais complexos gerados pelo SQL Server Profiler em eventos estendidos através do procedimento descrito no link abaixo:


Bom pessoal, é isso. Façam os seus testes com Extended Events, o seu uso ainda não é muito popular mas eles com certeza são uma escolha melhor que o SQL Server Profiler no momento de um troubleshooting de um ambiente com problemas de performance. 

Um abraço!