Verrou partagé émis sur IsolationLevel.ReadUncommitted

J'ai lu que si j'utilise IsolationLevel.ReadUncommitted, la requête ne devrait émettre aucun verrou. Cependant, lorsque j'ai testé cela, j'ai vu le verrou suivant:

Resource_Type: HOBT
Request_Mode: S (partagé)

Qu'est-ce qu'un verrou HOBT? Quelque chose en rapport avec HBT (Heap ou Binary Tree lock)?

Pourquoi devrais-je toujours obtenir un verrou S?

Comment éviter le verrouillage partagé lors d'une requête sans activer l'option d'instantané de niveau d'isolement?

Je teste cela sur SQLServer 2008 et l'option d'instantané est désactivée. La requête effectue uniquement une sélection.

Je peux voir que Sch-S est requis, bien que SQL Server ne semble pas l'afficher dans ma requête de verrouillage. Comment se fait-il qu'il émette toujours un verrou partagé? Selon:

DÉFINIR LE NIVEAU D'ISOLEMENT DE TRANSACTION (Transact-SQL)

Les transactions exécutées au READ UNCOMMITTEDniveau n'émettent pas de verrous partagés pour empêcher d'autres transactions de modifier les données lues par la transaction en cours.

Je suis donc un peu confus.

Qu'est-ce que le verrouillage HOBT?

Un verrou protégeant un arbre B (index) ou les pages de données du tas dans une table qui n'a pas d'index cluster.

Pourquoi devrais-je toujours obtenir un verrou S?

Cela se produit sur des tas. Exemple

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;

Production 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 

Production 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 

Selon cet article faisant référence à Paul Randal, la raison de la prise de ce BULK_OPERATIONverrou HOBT partagé est d'empêcher la lecture des pages non formatées.

Le niveau d'isolement ReadUncommitted acquiert des verrous. Les verrous de stabilité du schéma empêchent la modification des objets en cours de requête pendant l'exécution de la requête. Ces verrous sont acquis sous tous les niveaux d'isolement, y compris l'instantané et read_committed_snapshot (RCSI). Depuis les modes de verrouillage :

Verrous de schéma

Le moteur de base de données utilise des verrous de modification de schéma (Sch-M) lors d'une opération DDL (table data definition language), comme l'ajout d'une colonne ou la suppression d'une table. Pendant le temps qu'il est maintenu, le verrou Sch-M empêche l'accès simultané à la table. Cela signifie que le verrou Sch-M bloque toutes les opérations extérieures jusqu'à ce que le verrou soit libéré.

Certaines opérations du langage de manipulation de données (DML), telles que la troncature de table, utilisent des verrous Sch-M pour empêcher l'accès aux tables affectées par des opérations simultanées.

Le moteur de base de données utilise des verrous de stabilité de schéma (Sch-S) lors de la compilation et de l'exécution des requêtes. Les verrous Sch-S ne bloquent aucun verrou transactionnel, y compris les verrous exclusifs (X). Par conséquent, d'autres transactions, y compris celles avec des verrous X sur une table, continuent de s'exécuter pendant la compilation d'une requête. Toutefois, les opérations DDL simultanées et les opérations DML simultanées qui acquièrent des verrous Sch-M ne peuvent pas être effectuées sur la table.