Existem várias postagens de blog neste site relacionadas a estatísticas de espera; elas são uma das métricas mais importantes que você pode usar ao solucionar problemas de desempenho no SQL Server. As estatísticas de espera foram disponibilizadas no SQL Server 2005 e, tradicionalmente, representam esperas no nível da instância por meio de sys.dm_os_wait_statistics. Essas informações são ótimas para solucionar problemas de desempenho do sistema em geral, mas ao analisar o desempenho da consulta, as informações de espera só podiam ser vistas quando a consulta estava em execução e se estivesse aguardando um recurso por meio de sys.dm_os_waiting_tasks. Os dados em sys.dm_os_waiting_tasks são transitórios (é o que está esperando agora) e não são fáceis de capturar e reter durante a vida útil de uma consulta para ajuste de desempenho posteriormente.
No SQL Server 2016, um novo DMV é exposto, sys.dm_exec_session_wait_stats, que fornece informações sobre esperas por uma sessão ativa existente. Se você souber o session_id, poderá rastrear as esperas por uma consulta quando ela for iniciada e quando ela for concluída (capture as informações no início e no final da consulta e, em seguida, diferencie as informações). O desafio é que você precisa conhecer o session_id da consulta e configurar a captura de dados com antecedência – o que não é trivial quando você está no meio de um problema de alta prioridade.
As informações de estatísticas de espera existem em um plano de execução real a partir do SQL Server 2016 SP1. Apenas as 10 principais esperas são capturadas e há limitações em termos do que esses dados representam. Por exemplo, CXPACKET é ignorado e não incluído na saída, mas será incluído no 2016 SP2 e 2017 CU3 e superior – onde as esperas de paralelismo irrelevantes são capturadas pelo CXCONSUMER (que não será incluído nas esperas do plano real).
Então, como podemos ver o que uma consulta específica está realmente esperando? Podemos usar o Query Store! O SQL Server 2017 inclui a captura de informações de estatísticas de espera no Repositório de Consultas, e essa funcionalidade também está disponível no Banco de Dados SQL do Azure. As estatísticas de espera estão vinculadas a um plano de consulta e são capturadas ao longo do tempo, assim como as estatísticas de tempo de execução. A adição de informações de estatísticas de espera no Query Store foi a solicitação de recurso número um após seu lançamento inicial, e todas essas informações juntas criam recursos poderosos de solução de problemas.
Primeiros passos
A captura de estatísticas de espera no Repositório de Consultas é habilitada por padrão para o Banco de Dados SQL do Azure. Quando um novo banco de dados é criado no SQL Server 2017 ou um banco de dados é atualizado do SQL Server 2014 ou anterior, o Repositório de Consultas é desabilitado por padrão... e, portanto, a captura de estatísticas de espera é desabilitada. Quando um banco de dados é atualizado do SQL Server 2016, se ele tiver o Repositório de Consultas habilitado, a coleta de estatísticas de espera para o Repositório de Consultas será habilitada na atualização.
Para fins de demonstração, restaurei o banco de dados WideWorldImporters, executei as consultas abaixo para habilitar o Query Store e limpar quaisquer dados que possam ter existido anteriormente (necessário apenas porque este é um banco de dados de exemplo):
ALTER DATABASE [WideWorldImporters] SET QUERY_STORE = ON; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE ( OPERATION_MODE = READ_WRITE ); GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE CLEAR; GO
As configurações padrão são usadas com as instruções acima e, se você quiser alterar qualquer uma das opções, poderá fazê-lo por meio da interface do usuário ou da instrução ALTER DATABASE. Agora que o Repositório de Consultas está habilitado, ele começará a capturar dados de consulta, incluindo o texto da consulta, o(s) plano(s), estatísticas de tempo de execução e estatísticas de espera.
Examinando as estatísticas de espera
Para gerar alguns dados, criaremos um procedimento armazenado que executa uma consulta paralela repetidamente.
DROP PROCEDURE IF EXISTS [Sales].[OrderInfo];
GO
CREATE PROCEDURE [Sales].[OrderInfo]
AS
BEGIN
WHILE 1=1
BEGIN
SELECT *
FROM Sales.OrderLines ol
INNER JOIN Warehouse.StockItems s
ON ol.StockItemID = s.StockItemID
OPTION (QUERYTRACEON 8649);
END
END Em seguida, crie um arquivo .cmd com o seguinte código:
start sqlcmd -S WIN2016\SQL2017 -d WideWorldImporters -q"EXECUTE [Vendas].[OrderInfo];"
sair
Isso nos permite não execute o SP dentro do Management Studio, o que cria esperas ASYNC_NETWORK_IO significativas; queremos ver as esperas relacionadas ao paralelismo. Salve o arquivo .cmd e clique duas vezes para executar. Você pode gerar carga adicional executando vários arquivos. Com esse cenário, veremos principalmente as esperas relacionadas a essa consulta, pois não temos outra carga de trabalho. Sinta-se à vontade para executar outras consultas no banco de dados WideWorldImporters simultaneamente se desejar gerar ainda mais dados de espera.
Após alguns minutos, interrompa os arquivos de comando e expanda o banco de dados WideWorldImporters no Management Studio para ver a pasta Repositório de consultas e os relatórios abaixo. Se você abrir o relatório Principais consultas de consumo de recursos, deverá ver a consulta de procedimento armazenado como a consulta principal.
A visualização padrão deste relatório mostra as consultas com a maior duração total. Para visualizar as consultas com base nas estatísticas de espera, podemos selecionar o botão Configurar e alterá-lo para Tempo de espera (ms).
Botão Configurar na visualização do relatório (canto superior direito) 
Alterando o recurso para o relatório Observe que você também pode configurar o intervalo de tempo e o número de consultas retornadas. Para este exemplo, a última hora é aceitável. Se você passar o mouse sobre a barra para a primeira consulta, poderá ver os tempos de espera da consulta. Essa visualização é atualmente a única maneira de visualizar as informações de espera na interface do usuário, mas esperamos que relatórios adicionais específicos para estatísticas de espera cheguem em uma versão futura do Management Studio.
Aguarde informações na interface do usuário Aqueles de vocês que trabalharam com estatísticas de espera por um tempo perceberão que as descrições do tipo de espera são diferentes. Ou seja, em vez de um tipo de espera CXPACKET para indicar paralelismo, você simplesmente vê "Tipo de espera de paralelismo". Esta é uma diferença fundamental no Repositório de Consultas:Os tipos de espera são agrupados em categorias. Existem mais de 900 tipos de espera diferentes no SQL Server neste momento, e tentar rastrear cada um separadamente é extremamente caro. Além disso, o Query Store foi projetado com todos os profissionais de dados em mente – seja você um especialista em ajuste de desempenho ou apenas começando a entender como o SQL Server funciona, você poderá usar o Query Store para encontrar facilmente consultas com baixo desempenho. Isso também significa tornar as informações de espera mais fáceis de entender. Para obter uma lista completa das categorias de espera e dos tipos de espera, visite a documentação de sys.query_store_wait_stats.
Você também pode exibir informações de espera usando T-SQL. Um exemplo de consulta é o abaixo, que inclui a consulta, o plan_id(s) dessa consulta e as estatísticas de espera por um determinado intervalo de tempo:
SELECT TOP (10)
[ws].[wait_category_desc],
[ws].[avg_query_wait_time_ms],
[ws].[total_query_wait_time_ms],
[ws].[plan_id],
[qt].[query_sql_text],
[rsi].[start_time],
[rsi].[end_time]
FROM [sys].[query_store_query_text] [qt]
JOIN [sys].[query_store_query] [q]
ON [qt].[query_text_id] = [q].[query_text_id]
JOIN [sys].[query_store_plan] [qp]
ON [q].[query_id] = [qp].[query_id]
JOIN [sys].[query_store_runtime_stats] [rs]
ON [qp].[plan_id] = [rs].[plan_id]
JOIN [sys].[query_store_runtime_stats_interval] [rsi]
ON [rs].[runtime_stats_interval_id] = [rsi].[runtime_stats_interval_id]
JOIN [sys].[query_store_wait_stats] [ws]
ON [ws].[runtime_stats_interval_id] = [rs].[runtime_stats_interval_id]
AND [ws].[plan_id] = [qp].[plan_id]
WHERE [rsi].[end_time] > DATEADD(MINUTE, -5, GETUTCDATE())
AND [ws].[execution_type] = 0
ORDER BY [ws].[avg_query_wait_time_ms] DESC; 
Saída da consulta Embora agora você possa ver todas as esperas por uma determinada consulta e seu plano, ainda terá que se aprofundar no desempenho para entender, por exemplo, por que uma consulta está sendo executada em paralelo (quando talvez você não queira) ou o que pode estar bloqueando uma consulta. Observe que as estatísticas de espera, assim como as estatísticas de tempo de execução, estão vinculadas ao plano de consulta ao longo do tempo. Nesta saída, a duração do intervalo para o Repositório de Consultas é definida para 10 minutos, portanto, as estatísticas de espera são para cada plano para esse intervalo de 10 minutos (23h50 de 21 de novembro de 2017 à meia-noite de 22 de novembro de 2017). Por padrão, a duração do intervalo quando você habilita o Repositório de Consultas é de 60 minutos.
Resumo
As estatísticas de espera, combinadas com planos de consulta individuais, tornam o Query Store uma ferramenta ainda mais formidável ao solucionar problemas de sistema e desempenho de consulta. O Query Store é o único recurso que permite capturar nativamente consultas, planos, métricas de desempenho e estatísticas de espera em um único local. Para aqueles que estão acostumados com a infinidade de tipos de espera, o ajuste às categorias usadas no Repositório de Consultas deve ser simples. Para quem é novo nas estatísticas de espera, as categorias são um ótimo lugar para começar a entender o recurso pelo qual uma consulta está aguardando.
