Bloqueio compartilhado emitido em IsolationLevel.ReadUncommitted

Li que, se eu usar IsolationLevel.ReadUncommitted, a consulta não deve emitir nenhum bloqueio. No entanto, quando testei isso, vi o seguinte bloqueio:

Resource_Type: HOBT
Request_Mode: S (compartilhado)

O que é um bloqueio HOBT? Algo relacionado ao HBT (bloqueio de Heap ou Árvore Binária)?

Por que eu ainda receberia uma trava em S?

Como evito o bloqueio compartilhado ao consultar sem ativar a opção de captura instantânea no nível de isolamento?

Estou testando isso no SQLServer 2008 e a opção de instantâneo está desativada. A consulta realiza apenas uma seleção.

Percebo que o Sch-S é necessário, embora o SQL Server pareça não estar aparecendo na minha consulta de bloqueio. Como ele ainda gera um bloqueio compartilhado? De acordo com:

DEFINIR O NÍVEL DE ISOLAMENTO DA TRANSAÇÃO (Transact-SQL)

As transações em execução no READ UNCOMMITTEDnível não emitem bloqueios compartilhados para impedir que outras transações modifiquem os dados lidos pela transação atual.

Então, eu estou um pouco confuso.

O que é o bloqueio HOBT?

Um bloqueio que protege uma árvore B (índice) ou as páginas de dados de heap em uma tabela que não possui um índice em cluster.

Por que eu ainda receberia uma trava em S?

Isso acontece em montões. Exemplo

SET NOCOUNT ON;

DECLARE @Query nvarchar(max) = 
   N'DECLARE @C INT; 
     SELECT @C = COUNT(*) FROM master.dbo.MSreplication_options';

/*Run once so compilation out of the way*/
EXEC(@Query);

DBCC TRACEON(-1,3604,1200) WITH NO_INFOMSGS;

PRINT 'READ UNCOMMITTED';
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
EXEC(@Query);

PRINT 'READ COMMITTED';
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
EXEC(@Query);

DBCC TRACEOFF(-1,3604,1200) WITH NO_INFOMSGS;

Resultado READ UNCOMMITTED

Process 56 acquiring Sch-S lock on OBJECT: 1:1163151189:0  (class bit0 ref1) result: OK

Process 56 acquiring S lock on HOBT: 1:72057594038910976 [BULK_OPERATION] (class bit0 ref1) result: OK

Process 56 releasing lock on OBJECT: 1:1163151189:0 

Resultado READ COMMITTED

Process 56 acquiring IS lock on OBJECT: 1:1163151189:0  (class bit0 ref1) result: OK

Process 56 acquiring IS lock on PAGE: 1:1:169 (class bit0 ref1) result: OK

Process 56 releasing lock on PAGE: 1:1:169

Process 56 releasing lock on OBJECT: 1:1163151189:0 

De acordo com este artigo que faz referência a Paul Randal, a razão para usar esse BULK_OPERATIONbloqueio HOBT compartilhado é impedir a leitura de páginas não formatadas.

O nível de isolamento ReadCommitted adquire bloqueios. Os bloqueios de estabilidade do esquema impedem que os objetos que estão sendo consultados sejam alterados enquanto a consulta é executada. Esses bloqueios são adquiridos em todos os níveis de isolamento, incluindo snapshot e read_committed_snapshot (RCSI). Nos modos de bloqueio :

Bloqueios de esquema

O Mecanismo de Banco de Dados usa bloqueios de modificação de esquema (Sch-M) durante uma operação de DDL (tabela de definição de dados de tabela), como adicionar uma coluna ou descartar uma tabela. Durante o tempo em que é mantido, o bloqueio Sch-M impede o acesso simultâneo à tabela. Isso significa que a trava Sch-M bloqueia todas as operações externas até que a trava seja liberada.

Algumas operações da linguagem de manipulação de dados (DML), como truncamento de tabela, usam bloqueios Sch-M para impedir o acesso às tabelas afetadas por operações simultâneas.

O Mecanismo de Banco de Dados usa bloqueios de estabilidade do esquema (Sch-S) ao compilar e executar consultas. Os bloqueios Sch-S não bloqueiam nenhum bloqueio transacional, incluindo bloqueios exclusivos (X). Portanto, outras transações, incluindo aquelas com bloqueios X em uma tabela, continuam sendo executadas enquanto uma consulta está sendo compilada. No entanto, operações DDL simultâneas e operações DML simultâneas que adquirem bloqueios Sch-M, não podem ser executadas na tabela.