Solución de problemas de bloqueo de consultas en Fabric Data Warehouse

Esto se aplica a:✅ Almacén en Microsoft Fabric

Si las consultas en Warehouse tardan inusualmente mucho en ejecutarse o parecen bloqueadas, una posible causa es el bloqueo. El bloqueo se produce cuando una sesión contiene un bloqueo que impide que otras consultas continúen.

En este artículo se muestra cómo determinar si el bloqueo afecta a la carga de trabajo y qué acciones puede realizar.

Prerequisites

• Un almacén con cargas de trabajo activas.
• La pertenencia al rol Visor del área de trabajo es el permiso mínimo para consultar las vistas de administración dinámica (DMV) mencionadas en este artículo.
  • Para obtener más información sobre cómo solucionar problemas con DMV, consulte Supervisión de conexiones, sesiones y solicitudes mediante DMV.

Paso 1: Comprobar si las consultas están esperando bloqueos

Comience comprobando si hay alguna consulta esperando actualmente a que se liberen bloqueos.

Ejecute la siguiente consulta:

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

Si la consulta devuelve filas, algunas sesiones están esperando recursos retenidos por otras sesiones. Cada fila indica una solicitud de bloqueo que no se puede conceder actualmente.

Paso 2: Identificación de consultas bloqueadas

A continuación, compruebe qué consultas están bloqueadas y qué sesión las 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;

Esta consulta devuelve lo siguiente:

• La sesión que ejecuta la consulta bloqueada (session_id)
• La sesión la bloquea actualmente (blocking_session_id)
• Cuánto tiempo ha estado esperando (total_elapsed_time, en milisegundos)
• Si la sesión de bloqueo tiene una transacción abierta (open_transaction_count)

Si una consulta muestra que blocking_session_id es distinto de cero y open_transaction_count > 0, está esperando a otra sesión que mantiene un bloqueo.

Paso 3: Búsqueda de la sesión de bloqueo

Para comprender qué recurso está bloqueado, inspeccione los bloqueos mantenidos actualmente por la sesión bloqueadora. Sustituya un session_id que identificó anteriormente por el <blocking_session_id> en la siguiente consulta de ejemplo:

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:

• Sobre qué recursos mantiene bloqueos actualmente la sesión bloqueadora. Por ejemplo, puede usar sys.objects para identificar el resource_associated_entity_id donde se encuentra resource_type = OBJECT.
• Modo de bloqueo (por ejemplo, Exclusivo (X), Schema-Modification (Sch-M))
• Si el bloqueo está relacionado con una operación DDL o una actualización de estadísticas (UPDSTATS)

Paso 4: Buscar el propietario de la transacción de bloqueo

En muchos casos, es posible que prefiera pedir al propietario de la transacción que bloquea que COMMIT o ROLLBACK su trabajo en lugar de finalizar la sesión. Considere la posibilidad de usar TRYCATCH estructuras para el control de errores con COMMIT o ROLLBACK. Para obtener más información, consulte TRY... CATCH.

Puede identificar el propietario y la consulta asociados a la sesión de bloqueo. Sustituya en la siguiente consulta de ejemplo el <blocking_session_id> por el session_id que identificó anteriormente:

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 es el propietario de la sesión de bloqueo.
• program_name es la aplicación que inició la sesión. El DMS_user valor indica el editor de consultas del portal de Fabric.
• command es el comando que se está ejecutando actualmente.

A continuación, puede ponerse en contacto con el propietario de la transacción para confirmarla o revertirla si procede.

Paso 5: Comprobar si la sesión de bloqueo está inactiva o no progresa

Es posible que una sesión de bloqueo aparezca activa, pero no está progresando realmente.

Entre los indicadores de una sesión inactiva o parada se incluyen:

• status = 'sleeping' indica que no se ejecuta ninguna consulta activa.
• Busque un last_request_start_time muy anterior a la hora actual, lo que indica una solicitud abierta que lleva mucho tiempo activa.
• Busque un total_elapsed_time que no aumente entre verificaciones, lo que indica una sesión bloqueada.

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>;

• Si el estado de la sesión es sleeping y open_transaction_count > 0, la sesión tiene una transacción abierta sin ninguna consulta activa; mantiene un bloqueo sin realizar ninguna operación.
• Si la sesión aparece en sys.dm_exec_requests y total_elapsed_time continúa aumentando entre comprobaciones, la sesión está progresando activamente. Puede ser preferible esperar a que se complete la transacción en lugar de terminarla y forzar una reversión.

Paso 6: Tomar medidas para resolver el bloqueo

Si necesita desbloquear consultas de bajada, considere si una sesión de bloqueo tiene las siguientes características:

• Tiene una transacción abierta
• Aparece inactivo o no progresa
• Mantiene un bloqueo bloqueante (por ejemplo, exclusivo (X) o Sch-M)

Si es así, un miembro del rol Administrador del espacio de trabajo puede finalizar una sesión usando:

KILL <session_id>;

El KILL comando hará lo siguiente:

• Finalizar la sesión
• Revertir todo el trabajo realizado en la transacción activa de esa sesión
• Liberar el bloqueo
• Permitir que las consultas posteriores continúen

Paso 7: Evitar problemas futuros de bloqueo

Para ayudar a evitar problemas similares:

• Evite dejar abiertas transacciones explícitas (BEGIN TRANSACTION sin una correspondiente COMMIT o ROLLBACK).
• Mantenga las transacciones de corta duración. Realice solo las operaciones necesarias dentro de la transacción.
• Siempre COMMIT o ROLLBACK las transacciones una vez completadas.
• Programe operaciones DDL (como ALTER TABLE) durante las ventanas de tráfico bajo.

Supervise proactivamente las transacciones abiertas mediante:

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;

Supervisar regularmente las transacciones abiertas e intervenir cuando sea adecuado ayuda a reducir la probabilidad de que se formen cadenas de bloqueo.

Contenido relacionado

• Supervisar conexiones, sesiones y solicitudes mediante DMV
• Transacciones en Fabric Data Warehouse
• Solución de problemas del almacenamiento
• Información detallada sobre consultas en Fabric Data Warehouse