Como você sabe, a principal responsabilidade do administrador de banco de dados é monitorar o desempenho do SQL Server e intervir em determinado tempo. Você pode encontrar várias ferramentas de monitoramento de desempenho do SQL Server no mercado, mas às vezes precisamos de informações adicionais sobre o desempenho do SQL Server para diagnosticar e solucionar problemas de desempenho. Portanto, devemos ter informações suficientes sobre as Exibições de Gerenciamento Dinâmico do SQL Server para lidar com problemas sobre o SQL Server.
Dynamic Management View (DMV) é um conceito que nos ajuda a descobrir as métricas de desempenho do SQL Server Engine. O DMV foi anunciado pela primeira vez na versão do SQL Server 2005 e continuou em todas as versões do SQL Server posteriormente. Neste post, falaremos sobre determinado DMV cujo administrador de banco de dados deve ter informações suficientes. Este é sys.dm_os_wait_stats .
sys.dm_os_wait_stats
sys.dm_os_wait_stats oferece suporte a métricas essenciais para diagnosticar problemas de desempenho do SQL Server. Se você tiver alguns problemas (CPU, Memória, E/S, Bloqueio, Trava etc.) no SQL Server Engine, os dados sys.dm_os_wait_stats nos guiarão para definir o problema. O Activity Monitor no SQL Server Management Studio inclui um painel chamado “Resource Waits ”. “Resource Waits” obtém essas métricas de um procedimento armazenado especial. Este nome de procedimento armazenado temporário é “#am_generate_waitstats ” e usa sys.dm_os_wait_stats. Você pode encontrar esse procedimento armazenado temporário em “tempdb”. Neste ponto, gostaria de adicionar algumas notas sobre o procedimento armazenado temporário. Porque esse tipo de procedimento armazenado não tem um uso comum.
O procedimento armazenado temporário não difere dos procedimentos armazenados permanentes. Tem dois tipos:local e global como tabelas temporárias. O procedimento armazenado local permanece ativo na sessão atual e é descartado após o fechamento da sessão. Ele pode ser criado assim:
CREATE PROCEDURE #LocalTestSP AS PRINT Hello Local Stored Procedure
O procedimento armazenado global também permanece ativo em todas as sessões e descartado após o fechamento da sessão criada. O procedimento armazenado global pode ser criado como:
CREATE PROCEDURE ##GlobalTestSP AS PRINT Hello Global Stored Procedure
Dica: Quando abrimos o Monitor de atividades, ele cria o #am_generate_waitstats procedimento armazenado temporário e o descarta após o fechamento.
Agora analisaremos a ideia principal e os detalhes de sys.dm_os_wait_stats . A consulta abaixo retornará todos os dados sobre as “Estatísticas de Espera” do SQL Server. Esta consulta está na forma mais pura. É inconveniente detectar problemas com esse formulário. Nas seções a seguir, você encontrará consultas mais úteis do que sys.dm_os_wait_stats. Agora vamos explicar a descrição das colunas “Estatísticas de Espera” do SQL Server:
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC
A coluna wait_type contém a definição ou o nome das estatísticas de espera. Os dados da coluna wait_type são significativos para nós porque a definição das estatísticas de espera que indica o principal motivo do problema. wait_tasks_count indica a frequência do tipo de espera ocorrido no SQL Server.
wait_time_ms indica o tempo total de espera. A unidade de medida é um milissegundo.
max_wait_time_ms indica o tempo máximo de espera.
signal_wait_time_ms é descrito no MSDN como “Diferença entre a hora em que o thread em espera foi sinalizado e quando ele começou a ser executado”. O valor especialmente alto desta coluna indica a pressão da CPU. Portanto, a consulta está esperando na fila executável e pronta para execução, mas a CPU está ocupada com outras consultas. Por esse motivo, a consulta está aguardando na fila. Quando o recurso da CPU estiver disponível, a CPU obterá uma nova consulta da fila executável e iniciará o processamento. Em resumo, podemos descrever signal_wait_time_ms como tempo de espera na fila executável, que é o estado de executável para execução.
Dica: Na prática recomendada, as várias estatísticas de espera são mais importantes que as outras. Estes podem ser listados como:
• PAGEIOLATCH_*
• WRITELOG
• ASYNC_NETWORK_IO
• CXPACKET
• CPU
• LCK_M_*
• PREEMPTIVE_*
• PAGELATCH_*
Dê uma olhada no Pinal Dave ou Paul S. Randal esperar por consultas de estatísticas. Eles eliminaram vários tipos de estatísticas de espera em suas consultas. Os tipos de espera de recurso abaixo podem ser eliminados em sys.dm_os_wait_stats consultas:
• BROKER_EVENTHANDLER
• BROKER_RECEIVE_WAITFOR
• BROKER_TASK_STOP
• BROKER_TO_FLUSH
• BROKER_TRANSMITTER
• CHECKPOINT_QUEUE
• CHKPT
• CLR_AUTO_EVENT
• CLR_MANUAL_EVENT
• CLR_SEMAPHORE
• DBMIRROR_DBM_EVENT
• DBMIRROR_DBM_MUTEX
• DBMIRROR_EVENTS_QUEUE
• DBMIRROR_WORKER_QUEUE
• DBMIRRORING_CMD
• DIRTY_PAGE_POLL
• DISPATCHER_QUEUE_SEMAPHORE
• EXECSYNC
• FSAGENT
• FT_IFTS_SCHEDULER_IDLE_WAIT
• FT_IFTSHC_MUTEX
• HADR_CLUSAPI_CALL
• HADR_FILESTREAM_IOMGR_IOCOMPLETION
• HADR_LOGCAPTURE_WAIT
• HADR_NOTIFICATION_DEQUEUE
• HADR_TIMER_TASK
• HADR_WORK_QUEUE
• LAZYWRITER_SLEEP
• LOGMGR_QUEUE
• MEMORY_ALLOCATION_EXT
• ONDEMAND_TASK_QUEUE
• PREEMPTIVE_HADR_LEASE_MECHANISM
• PREEMPTIVE_OS_AUTHENTICATIONOPS
• PREEMPTIVE_OS_AUTHENTICATIONOPS
•
• PREEMPTIVE_OS_COMOPS
• PREEMPTIVE_OS_CREATEFILE
• PREEMPTIVE_OS_CRYPTOPS
• PREEM PTive_OS_DeviceOps
• Preemptive_OS_FILEOPS
• Preemptive_OS_GERERICOPS
• preemptive_os_libraryops
• Preemptive_os_PipeOps
• Preemptive_OS_QueryGistry
• prevntive_osntive
• Preemptive_OS_QueryGistry
• prevntive_osntive
• preemptive_os_quergistry
• prevntive_ostive) br />• PREEMPTIVE_SP_SERVER_DIAGNOSTICS
• PREEMPTIVE_XE_GETTARGETSTATE
• PWAIT_ALL_COMPONENTS_INITIALIZED
• PWAIT_DIRECTLOGCONSUMER_GETNEXT
• QDS_ASYNC_QUEUE
• QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP
• QDS_PERSIST_TASK_MAIN_LOOP_SLEEP
• QDS_SHUTDOWN_QUEUE
• REDO_THREAD_PENDING_WORK
• REQUEST_FOR_DEADLOCK_SEARCH
• RESOURCE_QUEUE
• SERVER_IDLE_CHECK
• SLEEP_BPOOL_FLUSH
• SLEEP_DBSTARTUP
• SLEEP_DCOMSTARTUP
• SLEEP_MASTERDBREADY
• SLEEP_MASTERMDREADY
• SLEEP_MASTERUPGRADED
• SLEEP_MSDBSTARTUP
• SLEEP_SYSTEMTASK
• SLEEP_TASK
• SP_SERVER_DIAGNOSTICS_SLEEP
• SQLTRACE_BUFFER_FLUSH
• SQLTRACE _INCREMENTAL_FLUSH_SLEEP
• SQLTRACE_WAIT_ENTRIES
• UCS_SESSION_REGISTRATIO
• WAIT_FOR_RESULTS
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_HOST_WAIT
• WAIT_XTP_OFFLINE_CKPT_NEW_LOG
• WAIT_XTP_OFFLINE_CKPT_NEW_LOG
• br />• WAITFOR_TASKSHUTDOW
• XE_TIMER_EVENT
• XE_DISPATCHER_WAIT
• XE_LIVE_TARGET_TVF
Dica: O SQL Server começa a coletar dados DMV quando é iniciado ou reiniciado. O SQL Server redefine automaticamente as estatísticas de espera quando é reiniciado e a consulta abaixo força a redefinição das estatísticas de espera desde que o SQL Server foi reiniciado pela última vez:
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) Além disso, a precisão da medição das estatísticas de espera é o ponto-chave. Neste ponto, podemos considerar duas abordagens:
• Redefina as estatísticas de espera e recole as estatísticas de espera.
• Capture duas “estatísticas de tempo de espera” diferentes e meça a diferença nos valores.
Na minha opinião, capturar e armazenar estatísticas de espera para qualquer abordagem de tabela de histórico é melhor do que outras. Neste método, você pode medir particularmente o intervalo de tempo e não perder estatísticas de espera de dados históricos.
Agora vamos fazer uma amostra da captura de estatísticas de espera e mostrar os dados capturados no Power BI com gráficos.
Vamos criar uma tabela de histórico para armazenar estatísticas de espera:
CREATE TABLE [dbo].[HistoryOfWaitStatistics]( [SQLStartTime] [datetime] NULL, [Dt] [datetime] NOT NULL, [WaitType] [nvarchar](60) NOT NULL, [WaitTimeSecond] [numeric](25, 6) NULL, [ResourcesWaitSecond] [numeric](25, 6) NULL, [SignalWaitSecond] [numeric](25, 6) NULL ) ON [PRIMARY]
O script abaixo insere “estatísticas de espera” na tabela de histórico. Mas você precisa agendar essa consulta no SQL Server Agent para armazenar a tabela de histórico:
DROP TABLE IF exists #eliminate_WS
CREATE TABLE #eliminate_WS (wait_type NVARCHAR(100));
INSERT INTO #eliminate_WS VALUES ('ASYNC_IO_COMPLETION');
INSERT INTO #eliminate_WS VALUES ('CHECKPOINT_QUEUE');
INSERT INTO #eliminate_WS VALUES ('CHKPT');
INSERT INTO #eliminate_WS VALUES ('CXPACKET');
INSERT INTO #eliminate_WS VALUES ('DISKIO_SUSPEND');
INSERT INTO #eliminate_WS VALUES ('FT_IFTS_SCHEDULER_IDLE_WAIT');
INSERT INTO #eliminate_WS VALUES ('IO_COMPLETION');
INSERT INTO #eliminate_WS VALUES ('KSOURCE_WAKEUP');
INSERT INTO #eliminate_WS VALUES ('LAZYWRITER_SLEEP');
INSERT INTO #eliminate_WS VALUES ('LOGBUFFER');
INSERT INTO #eliminate_WS VALUES ('LOGMGR_QUEUE');
INSERT INTO #eliminate_WS VALUES ('MISCELLANEOUS');
INSERT INTO #eliminate_WS VALUES ('PREEMPTIVE_XXX');
INSERT INTO #eliminate_WS VALUES ('REQUEST_FOR_DEADLOCK_SEARCH');
INSERT INTO #eliminate_WS VALUES ('RESOURCE_QUERY_SEMAPHORE_COMPILE');
INSERT INTO #eliminate_WS VALUES ('RESOURCE_SEMAPHORE');
INSERT INTO #eliminate_WS VALUES ('SOS_SCHEDULER_YIELD');
INSERT INTO #eliminate_WS VALUES ('SQLTRACE_BUFFER_FLUSH ');
INSERT INTO #eliminate_WS VALUES ('THREADPOOL');
INSERT INTO #eliminate_WS VALUES ('WRITELOG');
INSERT INTO #eliminate_WS VALUES ('XE_DISPATCHER_WAIT');
INSERT INTO #eliminate_WS VALUES ('XE_TIMER_EVENT');
INSERT INTO HistoryOfWaitStatistics
SELECT
(SELECT sqlserver_start_time FROM sys.dm_os_sys_info ) as SQLStartTime,GETDATE() AS Dt,Wait_type as WaitType,
wait_time_ms / 1000. AS WaitTimeSecond,
(wait_time_ms - signal_wait_time_ms)/1000. AS ResourcesWaitSecond,
signal_wait_time_ms/1000. AS SignalWaitSecond
FROM sys.dm_os_wait_stats
WHERE wait_type IN(SELECT wait_type FROM #eliminate_WS) Depois que os dados históricos forem armazenados, abrimos o Power BI e desenvolvemos nosso painel de estatísticas de espera.
Clique em Obter dados e selecione SQL Server :
Defina as configurações de conexão e grave a consulta em instrução SQL (opcional, requer um banco de dados) . Clique em OK .
Clique em Importar do Marketplace
Encontre Sparkline by OKViz componente visual e Adicionar Power BI
Adicione Sparkline ao painel de design do Power BI e arraste e solte as colunas do conjunto de dados como na imagem abaixo:
Adicione dois componentes de tabela para filtrar:SQLStartTime e WaitType . Por fim, o painel deve ficar assim:
Como diagnosticar o problema de espera do recurso:
Nesta seção, mencionaremos a metodologia e a disciplina de diagnóstico de problemas de estatísticas de espera. Particularmente, temos que descobrir um ponto sobre as estatísticas de espera:ele simplesmente define a estrutura principal do problema, mas nunca fornece detalhes. Por esse motivo, precisamos pesquisar detalhes e motivos de espera. Portanto, as “estatísticas de espera” nos permitem direcionar nossa pesquisa nessa direção. Depois, devemos usar outras ferramentas (PerfMon, Extended Events, ferramentas de monitoramento de terceiros, etc.) e outros DMVs para definir problemas exatos.
Supondo que, observamos ASYNC_NETWORK_IO no SQL Server, essa espera de recurso está relacionada à conexão de rede lenta de um cliente para o lado do servidor. Mas essas informações não ajudam a solucionar o principal motivo do problema, pois podemos ter várias configurações de rede entre servidor e cliente. Para este exemplo, precisamos olhar:
• Grandes consultas de conjuntos de resultados
• Configurações da placa de interface de rede
• Configurações do ambiente de rede entre os lados do servidor e o lado do cliente.
• Verifique a largura de banda do adaptador de rede.
Como você pode ver no exemplo, precisamos concluir algumas tarefas para definir o problema exato. As estatísticas de espera não indicam o destino do problema.
Conclusões
Neste post, falamos sobre o conceito principal da exibição de gerenciamento dinâmico sys.dm_os_wait_stats. Ao mesmo tempo, discutimos a simplicidade de uso e pontos significativos, nos quais é necessário prestar atenção.
Ferramenta útil:
dbForge Monitor – add-in para Microsoft SQL Server Management Studio que permite rastrear e analisar o desempenho do SQL Server.
