Monitorar a carga de trabalho do pool de SQL dedicado do Azure Synapse Analytics usando DMVs

Artigo
06/01/2023

Este artigo descreve como usar as DMVs (exibições de gerenciamento dinâmico) para monitorar a carga de trabalho e investigar a execução de consulta em um pool de SQL dedicado.

Permissões

Para consultar as DMVs deste artigo, você precisa ou da permissão VIEW DATABASE STATE ou da CONTROL. Em geral, é preferível conceder a permissão VIEW DATABASE STATE, pois ela é muito mais restritiva.

GRANT VIEW DATABASE STATE TO myuser;

Conexões do monitor

Todos os logons em seu data warehouse são registrados em sys.dm_pdw_exec_sessions. Essa DMV contém os últimos 10.000 logons. A session_id é a chave primária e é atribuída em sequência para cada novo logon.

-- Other Active Connections
SELECT * FROM sys.dm_pdw_exec_sessions where status <> 'Closed' and session_id <> session_id();

Monitorar a execução de consultas

Todas as consultas executadas no pool de SQL são registradas em sys.dm_pdw_exec_requests. Essa DMV contém as últimas 10.000 consultas executadas. A request_id identifica cada consulta exclusivamente e é a chave primária dessa DMV. A request_id é atribuída em sequência para cada nova consulta e é precedida por QID, que representa a ID da consulta. A consulta dessa DMV para uma session_id especificada mostra todas as consultas de um logon específico.

Observação

Os procedimentos armazenados usam vários request_ids. As IDs de solicitação são atribuídas em ordem sequencial.

Estas são as etapas para investigar os planos de execução da consulta e as horas para uma consulta específica.

ETAPA 1: identificar a consulta que você deseja investigar

-- Monitor active queries
SELECT *
FROM sys.dm_pdw_exec_requests
WHERE status not in ('Completed','Failed','Cancelled')
  AND session_id <> session_id()
ORDER BY submit_time DESC;

-- Find top 10 queries longest running queries
SELECT TOP 10 *
FROM sys.dm_pdw_exec_requests
ORDER BY total_elapsed_time DESC;

Nos resultados da consulta anterior, observe a ID da Solicitação da consulta que você deseja investigar.

As consultas no estado suspenso podem ser enfileiradas devido a um grande número de consultas ativas em execução. Essas consultas também aparecem em sys.dm_pdw_waits. Nesse caso, procure esperas como UserConcurrencyResourceType. Para obter informações sobre limites de simultaneidade, veja Limites de memória e de simultaneidade ou Classes de recursos para gerenciamento de carga de trabalho. As consultas também podem esperar por motivos, como bloqueios. Se sua consulta estiver aguardando um recurso, confira Investigar consultas aguardando recursos mais adiante neste artigo.

Para simplificar a pesquisa de uma consulta na tabela sys.dm_pdw_exec_requests, use LABEL para atribuir um comentário à consulta, que pode ser pesquisada na exibição sys.dm_pdw_exec_requests.

-- Query with Label
SELECT *
FROM sys.tables
OPTION (LABEL = 'My Query')
;

-- Find a query with the Label 'My Query'
-- Use brackets when querying the label column, as it is a key word
SELECT  *
FROM    sys.dm_pdw_exec_requests
WHERE   [label] = 'My Query';

ETAPA 2: investigar o plano de consulta

Use a ID da solicitação para recuperar o DSQL (plano de SQL distribuído) da consulta de sys.dm_pdw_request_steps

-- Find the distributed query plan steps for a specific query.
-- Replace request_id with value from Step 1.

SELECT * FROM sys.dm_pdw_request_steps
WHERE request_id = 'QID####'
ORDER BY step_index;

Quando um plano DSQL estiver demorando mais do que o esperado, a causa pode ser um plano complexo com muitas etapas de DSQL ou apenas uma etapa demorando muito tempo. Se o plano tiver muitas etapas com várias operações de movimentação, considere otimizar suas distribuições de tabela para reduzir a movimentação de dados. O artigo Distribuição da tabela explica por que os dados devem ser movidos para resolver uma consulta. O artigo também explica algumas estratégias de distribuição para minimizar a movimentação de dados.

Para investigar mais detalhes sobre uma única etapa, verifique a coluna operation_type da etapa de consulta de execução longa e observe o Índice da etapa:

Para Operações SQL (OnOperation, RemoteOperation, ReturnOperation), prossiga com a ETAPA 3
Para operações de Movimentação de dados (ShuffleMoveOperation, BroadcastMoveOperation, TrimMoveOperation, PartitionMoveOperation, MoveOperation, CopyOperation), prossiga com a ETAPA 4.

ETAPA 3: investigar o SQL nos bancos de dados distribuídos

Use a ID da Solicitação e o Índice de Etapas para recuperar os detalhes de sys.dm_pdw_sql_requests, que contém informações sobre a execução da consulta em todos os bancos de dados distribuídos.

-- Find the distribution run times for a SQL step.
-- Replace request_id and step_index with values from Step 1 and 3.

SELECT * FROM sys.dm_pdw_sql_requests
WHERE request_id = 'QID####' AND step_index = 2;

Se a consulta estiver em execução, DBCC PDW_SHOWEXECUTIONPLAN poderá ser usado para recuperar o plano estimado do SQL Server do cache do plano do SQL Server para a etapa em execução em uma distribuição específica.

-- Find the SQL Server execution plan for a query running on a specific SQL pool or control node.
-- Replace distribution_id and spid with values from previous query.

DBCC PDW_SHOWEXECUTIONPLAN(1, 78);

ETAPA 4: investigar a movimentação de dados em bancos de dados distribuídos

Use a ID da Solicitação e o Índice da Etapa para recuperar as informações sobre a etapa de movimentação dos dados em execução em cada distribuição em sys.dm_pdw_dms_workers.

-- Find information about all the workers completing a Data Movement Step.
-- Replace request_id and step_index with values from Step 1 and 3.

SELECT * FROM sys.dm_pdw_dms_workers
WHERE request_id = 'QID####' AND step_index = 2;

Verifique a coluna total_elapsed_time para ver se uma distribuição específica está demorando muito mais do que outras para movimentar dados.
Para a distribuição de longa execução, verifique a coluna rows_processed para verificar se o número de linhas sendo movidas dessa distribuição é significativamente maior do que outros. Nesse caso, essa localização pode indicar uma distorção dos dados subjacentes. Uma causa da distorção de dados é distribuir em uma coluna com muitos valores NULL (cujas linhas acabarão todas na mesma distribuição). Evite consultas lentas evitando a distribuição nesses tipos de colunas ou filtrando sua consulta para eliminar NULLs quando possível.

Se a consulta estiver em execução, você poderá usar DBCC PDW_SHOWEXECUTIONPLAN para recuperar o plano estimado do SQL Server do cache de planos do SQL Server para a Etapa de SQL em execução dentro de uma distribuição específica.

-- Find the SQL Server estimated plan for a query running on a specific SQL pool Compute or control node.
-- Replace distribution_id and spid with values from previous query.

DBCC PDW_SHOWEXECUTIONPLAN(55, 238);

Monitorar as consultas em espera

Caso você descubra que sua consulta não está fazendo progresso porque está aguardando um recurso, veja a seguir uma consulta que mostra todos os recursos que uma consulta está aguardando.

-- Find queries
-- Replace request_id with value from Step 1.

SELECT waits.session_id,
      waits.request_id,
      requests.command,
      requests.status,
      requests.start_time,
      waits.type,
      waits.state,
      waits.object_type,
      waits.object_name
FROM   sys.dm_pdw_waits waits
   JOIN  sys.dm_pdw_exec_requests requests
   ON waits.request_id=requests.request_id
WHERE waits.request_id = 'QID####'
ORDER BY waits.object_name, waits.object_type, waits.state;

Se a consulta estiver ativamente aguardando recursos de outra consulta, o estado será AcquireResources. Se a consulta tiver todos os recursos necessários, o estado será Concedido.

Monitorar o tempdb

O banco de dados tempdb é usado para armazenar os resultados intermediários durante a execução da consulta. A alta utilização do banco de dados tempdb pode gerar lentidão no desempenho de consulta. Para cada DW100c configurado, 399 GB de espaço do tempdb é alocado (o DW1000c terá 3,99 TB de espaço total no tempdb). Veja baixo dicas para monitorar o uso do tempdb e diminuir o uso do tempdb nas consultas.

Monitorar o tempdb com exibições

Para monitorar o uso do tempdb, primeiro, instale a exibição microsoft.vw_sql_requests do Microsoft Toolkit para o pool de SQL. Em seguida, você pode executar a seguinte consulta para ver o uso do tempdb por nó em todas as consultas executadas:

-- Monitor tempdb
SELECT
    sr.request_id,
    ssu.session_id,
    ssu.pdw_node_id,
    sr.command,
    sr.total_elapsed_time,
    exs.login_name AS 'LoginName',
    DB_NAME(ssu.database_id) AS 'DatabaseName',
    (es.memory_usage * 8) AS 'MemoryUsage (in KB)',
    (ssu.user_objects_alloc_page_count * 8) AS 'Space Allocated For User Objects (in KB)',
    (ssu.user_objects_dealloc_page_count * 8) AS 'Space Deallocated For User Objects (in KB)',
    (ssu.internal_objects_alloc_page_count * 8) AS 'Space Allocated For Internal Objects (in KB)',
    (ssu.internal_objects_dealloc_page_count * 8) AS 'Space Deallocated For Internal Objects (in KB)',
    CASE es.is_user_process
    WHEN 1 THEN 'User Session'
    WHEN 0 THEN 'System Session'
    END AS 'SessionType',
    es.row_count AS 'RowCount'
FROM sys.dm_pdw_nodes_db_session_space_usage AS ssu
    INNER JOIN sys.dm_pdw_nodes_exec_sessions AS es ON ssu.session_id = es.session_id AND ssu.pdw_node_id = es.pdw_node_id
    INNER JOIN sys.dm_pdw_nodes_exec_connections AS er ON ssu.session_id = er.session_id AND ssu.pdw_node_id = er.pdw_node_id
    INNER JOIN microsoft.vw_sql_requests AS sr ON ssu.session_id = sr.spid AND ssu.pdw_node_id = sr.pdw_node_id
    LEFT JOIN sys.dm_pdw_exec_requests exr on exr.request_id = sr.request_id
    LEFT JOIN sys.dm_pdw_exec_sessions exs on exr.session_id = exs.session_id
WHERE DB_NAME(ssu.database_id) = 'tempdb'
    AND es.session_id <> @@SPID
    AND es.login_name <> 'sa'
ORDER BY sr.request_id;

Observação

A movimentação de dados usa o tempdb. Para reduzir o uso de tempdb durante a movimentação de dados, verifique se a tabela está usando uma estratégia de distribuição que distribua dados uniformemente. Use o Assistente de Distribuição do SQL do Azure Synapse para obter recomendações sobre o método de distribuição adequado para suas cargas de trabalho. Use o kit de ferramentas do Azure Synapse para monitorar tempdb usando consultas T-SQL.

Se você tem uma consulta que está consumindo uma grande quantidade de memória ou recebeu uma mensagem de erro relacionada à alocação do tempdb, isso pode ser devido a uma instrução CTAS (CREATE TABLE AS SELECT) muito grande ou a uma instrução INSERT SELECT em execução que está falhando na operação final de movimentação de dados. Normalmente, isso pode ser identificado como uma operação ShuffleMove no plano de consulta distribuída logo antes do INSERT SELECT final. Use sys.dm_pdw_request_steps para monitorar as operações ShuffleMove.

A mitigação mais comum é dividir a instrução CTAS ou a INSERT SELECT em várias instruções de carga, para que o volume de dados não exceda o limite do tempdb de 399 GB por 100DWUc. Escale também seu cluster para um tamanho maior, a fim de aumentar o espaço tempdb que você tem.

Além das instruções CTAS e INSERT SELECT, as consultas grandes e complexas em execução com memória insuficiente podem ser despejadas no tempdb, causando falha nas consultas. Considere a execução com uma classe de recursos maior para evitar o despejo no tempdb.

Monitorar a memória

A memória pode ser a causa raiz de problemas de desempenho lento e memória insuficiente. Considere a possibilidade de dimensionar o data warehouse se descobrir que o uso de memória do SQL Server está atingindo seus limites durante a execução de consulta.

A seguinte consulta retorna o uso e a demanda de memória do SQL Server por nó:

-- Memory consumption
SELECT
  pc1.cntr_value as Curr_Mem_KB,
  pc1.cntr_value/1024.0 as Curr_Mem_MB,
  (pc1.cntr_value/1048576.0) as Curr_Mem_GB,
  pc2.cntr_value as Max_Mem_KB,
  pc2.cntr_value/1024.0 as Max_Mem_MB,
  (pc2.cntr_value/1048576.0) as Max_Mem_GB,
  pc1.cntr_value * 100.0/pc2.cntr_value AS Memory_Utilization_Percentage,
  pc1.pdw_node_id
FROM
-- pc1: current memory
sys.dm_pdw_nodes_os_performance_counters AS pc1
-- pc2: total memory allowed for this SQL instance
JOIN sys.dm_pdw_nodes_os_performance_counters AS pc2
ON pc1.object_name = pc2.object_name AND pc1.pdw_node_id = pc2.pdw_node_id
WHERE
pc1.counter_name = 'Total Server Memory (KB)'
AND pc2.counter_name = 'Target Server Memory (KB)'

Monitorar o tamanho do log de transações

A consulta a seguir retorna o tamanho do log de transações em cada distribuição. Se um dos arquivos de log estiver alcançando 160 GB, você deverá considerar a possibilidade de escalar verticalmente a instância ou limitar o tamanho da transação.

-- Transaction log size
SELECT
  instance_name as distribution_db,
  cntr_value*1.0/1048576 as log_file_size_used_GB,
  pdw_node_id
FROM sys.dm_pdw_nodes_os_performance_counters
WHERE
instance_name like 'Distribution_%'
AND counter_name = 'Log File(s) Used Size (KB)'

Monitorar a reversão do log de transações

Se as consultas estiverem falhando ou demorando muito para continuar, verifique e monitore se há transações sendo revertidas.

-- Monitor rollback
SELECT
    SUM(CASE WHEN t.database_transaction_next_undo_lsn IS NOT NULL THEN 1 ELSE 0 END),
    t.pdw_node_id,
    nod.[type]
FROM sys.dm_pdw_nodes_tran_database_transactions t
JOIN sys.dm_pdw_nodes nod ON t.pdw_node_id = nod.pdw_node_id
GROUP BY t.pdw_node_id, nod.[type]

Monitorar a carga do PolyBase

A consulta a seguir fornece uma estimativa aproximada do progresso da carga. A consulta mostra apenas os arquivos que estão sendo processados no momento.

-- To track bytes and files
SELECT
    r.command,
    s.request_id,
    r.status,
    count(distinct input_name) as nbr_files,
    sum(s.bytes_processed)/1024/1024/1024 as gb_processed
FROM
    sys.dm_pdw_exec_requests r
    inner join sys.dm_pdw_dms_external_work s
        on r.request_id = s.request_id
GROUP BY
    r.command,
    s.request_id,
    r.status
ORDER BY
    nbr_files desc,
    gb_processed desc;

Monitorar bloqueios de consulta

A consulta a seguir fornece as 500 principais consultas bloqueadas no ambiente.

--Collect the top blocking
SELECT
    TOP 500 waiting.request_id AS WaitingRequestId,
    waiting.object_type AS LockRequestType,
    waiting.object_name AS ObjectLockRequestName,
    waiting.request_time AS ObjectLockRequestTime,
    blocking.session_id AS BlockingSessionId,
    blocking.request_id AS BlockingRequestId
FROM
    sys.dm_pdw_waits waiting
    INNER JOIN sys.dm_pdw_waits blocking
    ON waiting.object_type = blocking.object_type
    AND waiting.object_name = blocking.object_name
WHERE
    waiting.state = 'Queued'
    AND blocking.state = 'Granted'
ORDER BY
    ObjectLockRequestTime ASC;

Recuperar texto de consultas de espera e bloqueio

A consulta a seguir fornece o texto e o identificador para as consultas de espera e bloqueio a fim de solucionar problemas facilmente.

-- To retrieve query text from waiting and blocking queries

SELECT waiting.session_id AS WaitingSessionId,
       waiting.request_id AS WaitingRequestId,
       COALESCE(waiting_exec_request.command,waiting_exec_request.command2) AS WaitingExecRequestText,
       waiting.object_name AS Waiting_Object_Name,
       waiting.object_type AS Waiting_Object_Type,
       blocking.session_id AS BlockingSessionId,
       blocking.request_id AS BlockingRequestId,
       COALESCE(blocking_exec_request.command,blocking_exec_request.command2) AS BlockingExecRequestText,
       blocking.object_name AS Blocking_Object_Name,
       blocking.object_type AS Blocking_Object_Type,
       waiting.type AS Lock_Type,
       waiting.request_time AS Lock_Request_Time,
       datediff(ms, waiting.request_time, getdate())/1000.0 AS Blocking_Time_sec
FROM sys.dm_pdw_waits waiting
       INNER JOIN sys.dm_pdw_waits blocking
       ON waiting.object_type = blocking.object_type
       AND waiting.object_name = blocking.object_name
       INNER JOIN sys.dm_pdw_exec_requests blocking_exec_request
       ON blocking.request_id = blocking_exec_request.request_id
       INNER JOIN sys.dm_pdw_exec_requests waiting_exec_request
       ON waiting.request_id = waiting_exec_request.request_id
WHERE waiting.state = 'Queued'
       AND blocking.state = 'Granted'
ORDER BY Lock_Request_Time DESC;

Próximas etapas

Para obter mais informações sobre DMVs, consulte Exibições do sistema.

Compartilhar via