Como controlar o bloqueio que ocorre por menos de um segundo - SQL Server

Estou tentando solucionar um problema de bloqueio que ocorre por menos de um segundo. O aplicativo OLTP é muito sensível e precisa ter um tempo de resposta inferior a 200ms para algumas transações, conforme o SLA acordado. Tivemos alguns problemas de escalação de bloqueios com o novo lançamento de código que pudemos resolver com a redução do tamanho do lote nas atualizações. Mesmo com o tamanho pequeno do lote, suspeitamos que o novo sp esteja bloqueando as mesmas linhas que as transações OLTP estão atualizando.

Preciso encontrar a sessão que está sendo bloqueada e o recurso está aguardando. De acordo com meu entendimento, "limite do processo bloqueado" pode ser definido por no mínimo 1 segundo e, portanto, isso não capturará o bloqueio.

Estou experimentando os eventos wait_info e wait_completed x.

Existe alguma outra maneira de rastrear isso. obrigado

Como você está especificamente interessado em bloquear, em vez de esperar em geral, o locks_lock_waitsevento estendido parece mais adequado.

Com um filtro ligado increment >= 200

CREATE EVENT SESSION [locks_lock_waits] ON SERVER 
ADD EVENT sqlserver.locks_lock_waits(
        ACTION(sqlserver.sql_text)
            WHERE  ( [sqlserver].[is_system] = 0
                     AND [increment] >= 200
                     AND [counter] <= 1000 ) 
    )
ADD TARGET package0.ring_buffer;

GO

ALTER EVENT SESSION [locks_lock_waits]  
ON SERVER  STATE = start;  

O item acima reúne as instruções aguardando bloqueios pelo tempo limite, mas não fornece o recurso de bloqueio específico.

Eu nunca usei esse evento e não tenho ideia de quanto sobrecarga essa sessão causaria no seu servidor de produção.

Encontrei este vídeo sobre o assunto. Isso recomenda enfaticamente a filtragem counterpara reduzir o número de eventos coletados, e eu fiz isso acima.

Também menciona um antigo comando não documentado legado

dbcc lock(StallReportThreshold, 200) -- 200 is threshold in ms

Qual (se o sinalizador de rastreamento 3605 estiver ativado) despeja informações limitadas, como as abaixo, no log de erros do SQL Server.

O processo 53 esperou 6844 ms pelo bloqueio S no RID: 2: 1: 120: 2 resultado: OKWAIT

Eu apenas mencionei isso de passagem, pois os eventos estendidos seriam claramente preferíveis de qualquer maneira, pois estão documentados e muito mais poderosos.

Se você estiver interessado em bloquear, há vários eventos estendidos disponíveis:

lock_acquired
lock_released
lock_escalation

Os dois primeiros eventos têm uma durationcoluna (microssegundos) na qual você pode filtrar seus limites. Eles também têm uma resource_descriptionação que fornecerá alguns detalhes sobre os recursos envolvidos.

O lock_escalationevento também possui uma statementação que você pode adicionar para coletar a instrução T-SQL que acionou a escalação do bloqueio. Também tem escalation_cause. Aqui está uma sessão de amostra:

CREATE EVENT SESSION [locking] ON SERVER 
ADD EVENT sqlserver.lock_acquired( SET collect_resource_description = (1) ),
ADD EVENT sqlserver.lock_escalation( SET collect_statement = (1) ),
ADD EVENT sqlserver.lock_released( SET collect_resource_description = (1) )
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO

Eu suspeito que provavelmente haja um motivo para você não definir o limite do relatório de processo bloqueado para menos de um segundo: o bloqueio é perfeitamente normal em um RDBMS - o mecanismo de banco de dados precisa bloquear recursos para protegê-los. Embora não exista uma definição oficial de quando o bloqueio se torna bloqueado, o bloqueio do tique por mais de um segundo parece normal para mim.