Bloqueo compartido emitido en IsolationLevel.ReadUncommitted

Leí que si uso IsolationLevel.ReadUncommitted, la consulta no debería emitir ningún bloqueo. Sin embargo, cuando probé esto, vi el siguiente bloqueo:

Resource_Type: HOBT
Request_Mode: S (Shared)

¿Qué es un bloqueo HOBT? ¿Algo relacionado con HBT (Heap o Binary Tree lock)?

¿Por qué todavía obtendría un bloqueo S?

¿Cómo evito el bloqueo compartido al realizar consultas sin activar la opción de instantánea de nivel de aislamiento?

Estoy probando esto en SQLServer 2008, y la opción de instantánea está desactivada. La consulta solo realiza una selección.

Puedo ver que se requiere Sch-S, aunque parece que SQL Server no lo muestra en mi consulta de bloqueo. ¿Cómo es que todavía emite un bloqueo compartido? De acuerdo a:

ESTABLECER NIVEL DE AISLAMIENTO DE TRANSACCIÓN (Transact-SQL)

Las transacciones que se ejecutan en el READ UNCOMMITTEDnivel no emiten bloqueos compartidos para evitar que otras transacciones modifiquen los datos leídos por la transacción actual.

Entonces estoy un poco confundido.

¿Qué es el bloqueo HOBT?

Un bloqueo que protege un árbol B (índice) o las páginas de datos del montón en una tabla que no tiene un índice agrupado.

¿Por qué todavía obtendría un bloqueo S?

Esto sucede en montones. Ejemplo

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;

Salida 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 

Salida 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 acuerdo con este artículo que hace referencia a Paul Randal, la razón para tomar este BULK_OPERATIONbloqueo HOBT compartido es evitar la lectura de páginas sin formato.

El nivel de aislamiento de ReadUncommitted adquiere bloqueos. Los bloqueos de estabilidad del esquema evitan que los objetos que son consultas se alteren mientras se ejecuta la consulta. Estos bloqueos se adquieren en todos los niveles de aislamiento, incluidas la instantánea y read_committed_snapshot (RCSI). Desde modos de bloqueo :

Schema Locks

El Motor de base de datos utiliza bloqueos de modificación de esquema (Sch-M) durante una operación de lenguaje de definición de datos de tabla (DDL), como agregar una columna o descartar una tabla. Durante el tiempo que se mantiene, el bloqueo Sch-M impide el acceso concurrente a la tabla. Esto significa que el bloqueo Sch-M bloquea todas las operaciones externas hasta que se libera el bloqueo.

Algunas operaciones del lenguaje de manipulación de datos (DML), como el truncamiento de tablas, usan bloqueos Sch-M para evitar el acceso a las tablas afectadas por operaciones concurrentes.

El Motor de base de datos utiliza bloqueos de estabilidad de esquema (Sch-S) al compilar y ejecutar consultas. Los bloqueos Sch-S no bloquean ningún bloqueo transaccional, incluidos los bloqueos exclusivos (X). Por lo tanto, otras transacciones, incluidas aquellas con bloqueos X en una tabla, continúan ejecutándose mientras se compila una consulta. Sin embargo, las operaciones DDL concurrentes y las operaciones DML concurrentes que adquieren bloqueos Sch-M no se pueden realizar en la tabla.