Solucionar problemas de bloqueio de consulta no Fabric Data Warehouse

Aplica-se a:✅Armazém de dados no Microsoft Fabric

Se suas consultas no Warehouse demorarem muito para serem executadas ou parecerem paralisadas, uma causa possível será o bloqueio. O bloqueio ocorre quando uma sessão mantém um bloqueio que impede que outras consultas prossigam.

Este artigo mostra como determinar se o bloqueio está afetando sua carga de trabalho e quais ações você pode executar.

Pré-requisitos

• Um Warehouse com cargas de trabalho ativas.
• A participação na função de Visualizador no workspace é a permissão mínima necessária para consultar as DMVs (modos de exibição de gerenciamento dinâmico) mencionadas neste artigo.
  • Para obter mais informações sobre como solucionar problemas com DMVs, consulte Monitorar conexões, sessões e solicitações usando DMVs.

Etapa 1: Verificar se as consultas estão aguardando bloqueio

Comece verificando se as consultas estão aguardando bloqueios no momento.

Execute a seguinte consulta:

SELECT
    request_session_id,
    resource_type,
    resource_description,
    request_mode,
    request_status
FROM sys.dm_tran_locks
WHERE request_status = 'WAIT';

Se a consulta retornar linhas, algumas sessões estarão aguardando recursos mantidos por outras sessões. Cada linha indica uma solicitação de bloqueio que não pode ser concedida no momento.

Etapa 2: identificar consultas bloqueadas

Em seguida, verifique quais consultas estão bloqueadas e qual sessão as está bloqueando.

SELECT
    session_id,
    status,
    blocking_session_id,
    wait_type,
    total_elapsed_time,
    open_transaction_count
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

A consulta retorna:

• A sessão que executa a consulta bloqueada (session_id)
• A sessão que atualmente a está bloqueando (blocking_session_id)
• Há quanto tempo está esperando (total_elapsed_timeem milissegundos)
• Se a sessão de bloqueio tem uma transação aberta (open_transaction_count)

Se uma consulta mostrar blocking_session_id diferente de zero e open_transaction_count > 0, ela estará aguardando outra sessão que detém um bloqueio.

Etapa 3: Localizar a sessão de bloqueio

Para entender qual recurso está bloqueado, inspecione os bloqueios atualmente mantidos pela sessão de bloqueio. Substitua um session_id que você identificou anteriormente no lugar de <blocking_session_id> na consulta de exemplo a seguir:

SELECT
    request_session_id,
    resource_type,
    resource_associated_entity_id,
    request_mode,
    request_status
FROM sys.dm_tran_locks
WHERE
    request_status = 'GRANT'
    AND request_session_id = <blocking_session_id>;

Use esta consulta para determinar:

• Em quais recursos a sessão de bloqueio atualmente mantém bloqueios. Por exemplo, você pode usar sys.objects para identificar o resource_associated_entity_id onde o resource_type = OBJECT.
• O modo de bloqueio (por exemplo, Exclusivo (X), Schema-Modification (Sch-M))
• Se o bloqueio está relacionado a uma operação DDL ou atualização de estatísticas (UPDSTATS)

Etapa 4: localizar o proprietário da transação de bloqueio

Em muitos casos, você pode preferir pedir ao proprietário da transação que está bloqueando que COMMIT ou ROLLBACK o trabalho em vez de encerrar a sessão. Considere usar estruturas TRYCATCH para tratamento de erros com COMMIT ou ROLLBACK. Para obter mais informações, consulte TRY... CATCH.

Você pode identificar o proprietário e a consulta associados à sessão de bloqueio. Substitua um session_id que você identificou anteriormente pelo <blocking_session_id> na seguinte consulta de exemplo:

SELECT
    r.session_id,
    s.login_name,
    s.program_name,
    r.status,
    r.blocking_session_id,
    r.command,
    r.total_elapsed_time,
    s.last_request_start_time,
    s.last_request_end_time
FROM sys.dm_exec_requests r
JOIN sys.dm_exec_sessions s
    ON r.session_id = s.session_id
WHERE r.session_id = <blocking_session_id>;

• login_name é o proprietário da sessão de bloqueio.
• program_name é o aplicativo que iniciou a sessão. O DMS_user valor indica o editor de consultas do portal Fabric.
• command é o comando em execução no momento.

Em seguida, você pode entrar em contato com o proprietário da transação para confirmá-la ou revertê-la, se apropriado.

Etapa 5: Verificar se a sessão de bloqueio está ociosa ou não está progredindo

Uma sessão de bloqueio pode parecer ativa, mas não está realmente progredindo.

Os indicadores de uma sessão ociosa ou paralisada incluem:

• status = 'sleeping' indica que nenhuma consulta ativa está em execução.
• Procure por uma solicitação aberta last_request_start_time muito anterior ao horário atual, indicando uma solicitação aberta de longa duração.
• Procure um total_elapsed_time que não esteja aumentando entre verificações, indicando uma sessão paralisada.

SELECT
    session_id,
    status,
    last_request_start_time,
    last_request_end_time,
    open_transaction_count
FROM sys.dm_exec_sessions
WHERE session_id = <blocking_session_id>;

• Se o status da sessão for sleeping e open_transaction_count > 0, a sessão tem uma transação aberta sem nenhuma consulta ativa — ela retém um bloqueio sem executar nenhuma operação.
• Se a sessão aparecer em sys.dm_exec_requests e o total_elapsed_time continuar aumentando entre as verificações, a sessão está progredindo. Talvez seja preferível aguardar a conclusão da transação em vez de encerrá-la e forçar uma reversão.

Etapa 6: Tomar medidas para resolver o bloqueio

Se você precisar desbloquear consultas downstream, considere se uma sessão de bloqueio tem as seguintes características:

• Tem uma transação aberta
• Aparece ocioso ou não está progredindo
• Está mantendo um bloqueio bloqueante (por exemplo, Exclusivo (X) ou Sch-M)

Nesse caso, um membro da função de workspace do Administrador pode encerrar uma sessão usando:

KILL <session_id>;

O KILL comando será:

• Encerrar a sessão
• Reverter todo o trabalho realizado na transação ativa dessa sessão
• Desbloquear
• Permitir que consultas downstream prossigam

Etapa 7: Evitar problemas futuros de bloqueio

Para ajudar a evitar problemas semelhantes:

• Evite deixar transações explícitas abertas (BEGIN TRANSACTION sem um correspondente COMMIT ou ROLLBACK).
• Mantenha as transações de curta duração. Execute apenas as operações necessárias na transação.
• Sempre COMMIT ou ROLLBACK transações quando concluídas.
• Agende operações DDL (como ALTER TABLE) durante janelas de baixo tráfego.

Monitore proativamente as transações abertas usando:

SELECT
    session_id,
    login_name,
    open_transaction_count,
    program_name,
    status,
    blocking_session_id,
    last_request_start_time
FROM sys.dm_exec_sessions
WHERE open_transaction_count > 0;

Monitorar regularmente transações abertas e intervir quando apropriado ajuda a reduzir a probabilidade de formação de cadeias de bloqueio.

Conteúdo relacionado

• Monitorar conexões, sessões e solicitações usando DMVs
• Transações no Fabric Data Warehouse
• Solucionar problemas do Warehouse
• Consultar Insights no Fabric Data Warehouse