Quando crio um caso de teste em uma sessão #1:
create table ##t (a int)
begin tran
insert into ##t select 1
e em outra sessão #2 correr
select * from ##t
e ainda em outra sessão executar
sp_who2 active
então nenhum contador de CPU e IO está aumentando na sessão bloqueada #2. Isso faz sentido, mas é sempre o caso de uma instrução bloqueada?
A resposta aqui é "depende" - Embora realmente bloqueado? Uma sessão não deve usar nenhum recurso. Está em um estado basicamente dizendo "Tenho certeza que gostaria de fazer meu trabalho, ei, SQL Server, posso bloquear tal e tal recurso" então, enquanto esse recurso está bloqueado - a sessão basicamente não é capaz de fazer nada, exceto esperar para disponibilidade de recursos. Depois de limpo, ele pode começar a executar ou ingressar na fila executável aguardando o horário do agendador.
Agora você ainda pode ver IO e CPU aumentando em uma sessão com muitas consultas ou etapas bloqueadas em pontos diferentes. Assim, você pode olhar e ver que está bloqueado no momento, mas ver a CPU aumentada ou IO - isso seria porque passou de um bloqueio, funcionou para uma instrução, mas foi bloqueado novamente.
Frequentemente, diagnostico o bloqueio com uma ferramenta que mostra a duração da consulta e as métricas de CPU/IO para uma sessão, mas talvez perca os blocos de rastreamento se a execução de uma consulta for maior que a duração normal, mas permanecer dentro de seus limites normais de CPU e IO. Não é apenas o bloqueio que se apresentará dessa maneira, mas geralmente é - então se torna uma ferramenta para dizer "ei, vamos olhar e ver se vemos algum bloqueio".
Também posso sugerir que você dê uma olhada em sp_whoisactive . Um ótimo script que será muito mais informativo do que SP_Who2.