Спільний замок виданий на IsolationLevel.ReadUncommitted

Я прочитав, що якщо я використовую IsolationLevel.ReadUncommitted, запит не повинен видавати блокування. Однак, перевіривши це, я побачив наступний замок:

Тип ресурсу: HOBT Request_Mode
: S (Спільний)

Що таке замок HOBT? Щось пов’язане з HBT (замок Heap чи Binary Tree)?

Чому я все-таки отримаю S-замок?

Як я можу уникнути спільного блокування під час запиту, не вмикаючи варіант знімка рівня ізоляції?

Я тестую це на SQLServer 2008, і параметр "Знімок" вимкнено. Запит виконує лише вибір.

Я бачу, що потрібен Sch-S, хоча SQL Server, схоже, не відображає його в моєму запиті блокування. Як це все-таки видає Спільний замок? Згідно з:

НАСТРОЙКА РІВНЯ ІЗОЛЯЦІЇ ТРАНЗАКЦІЇ (Transact-SQL)

Операції, що виконуються на READ UNCOMMITTEDрівні, не видають загальні блокування, щоб запобігти іншим транзакціям змінювати дані, прочитані поточною транзакцією.

Тож я трохи розгублений.

Що таке замок HOBT?

Блокування, що захищає B-дерево (індекс) або сторінки даних купи в таблиці, що не має кластерного індексу.

Чому я все-таки отримаю S-замок?

Це відбувається на купи. Приклад

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;

Вихідні дані 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 

Вихідні дані 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 

Згідно з цією статтею, що посилається на Пола Рандала, причиною цього BULK_OPERATIONзагального блокування HOBT є запобігання читання неформатованих сторінок.

Рівень ізоляції ReadUncommitted дійсно набуває блокування. Блокування стабільності схеми запобігає зміні запитів об'єктів під час виконання запиту. Цей замок набувається під усіма рівнями ізоляції, включаючи знімок та read_committed_snapshot (RCSI). З режимів блокування :

Замки схеми

Database Engine використовує блокування модифікації схеми (Sch-M) під час операції з визначенням даних таблиці (DDL) таблиці, наприклад додавання стовпця або випадання таблиці. Під час його утримання замок Sch-M запобігає одночасному доступу до столу. Це означає, що замок Sch-M блокує всі зовнішні операції, поки замок не буде звільнений.

Деякі операції з мовою обробки даних (DML), наприклад, усічення таблиць, використовують блокування Sch-M для запобігання доступу до постраждалих таблиць шляхом одночасних операцій.

База даних Engine використовує блокування стабільності схеми (Sch-S) під час компіляції та виконання запитів. Замки Sch-S не блокують жодних замків транзакцій, включаючи ексклюзивні (X) замки. Тому інші транзакції, в тому числі транзакції з X замками на столі, продовжують виконуватись під час збирання запиту. Однак одночасні операції DDL і одночасні операції DML, які набувають замки Sch-M, не можуть бути виконані на столі.