Blokada współdzielona wydana w IsolationLevel.ReadUncommitted

Przeczytałem, że jeśli użyję IsolationLevel.ReadUncommitted, zapytanie nie powinno powodować żadnych blokad. Jednak kiedy to przetestowałem, zobaczyłem następującą blokadę:

Resource_Type: HOBT
Request_Mode: S (Shared)

Co to jest blokada HOBT? Coś związanego z HBT (blokada sterty lub drzewa binarnego)?

Dlaczego nadal miałbym dostać blokadę S?

Jak uniknąć wspólnego blokowania podczas wysyłania zapytań bez włączania opcji migawki poziomu izolacji?

Testuję to na SQLServer 2008, a opcja migawki jest wyłączona. Zapytanie wykonuje tylko zaznaczenie.

Widzę, że Sch-S jest wymagany, chociaż SQL Server wydaje się nie wyświetlać go w moim zapytaniu blokującym. Dlaczego nadal wydaje wspólną blokadę? Według:

USTAW POZIOM IZOLACJI TRANSAKCJI (Transact-SQL)

Transakcje wykonywane na READ UNCOMMITTEDpoziomie nie powodują blokad współdzielonych, aby uniemożliwić innym transakcjom modyfikowanie danych odczytanych przez bieżącą transakcję.

Więc jestem trochę zdezorientowany.

Co to jest blokada HOBT?

Blokada chroniąca B-drzewa (indeks) lub strony danych sterty w tabeli, która nie ma indeksu klastrowego.

Dlaczego nadal miałbym dostać blokadę S?

Dzieje się tak na stosach. Przykład

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;

Wynik 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 

Wynik 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 

Zgodnie z tym artykułem odnoszącym się do Paula Randala powodem podjęcia tej BULK_OPERATIONwspólnej blokady HOBT jest uniemożliwienie czytania niesformatowanych stron.

Odczyt niezatwierdzony poziom izolacji nabywa blokady. Blokady stabilności schematu zapobiegają zmianie obiektów będących zapytaniami podczas wykonywania zapytania. Blokady są uzyskiwane na wszystkich poziomach izolacji, w tym na migawce i read_committed_snapshot (RCSI). Z trybów blokady :

Blokowanie schematu

Aparat baz danych używa blokad modyfikacji schematu (Sch-M) podczas operacji języka definicji danych tabeli (DDL), takich jak dodawanie kolumny lub upuszczanie tabeli. Podczas trzymania zamek Sch-M uniemożliwia równoczesny dostęp do stołu. Oznacza to, że zamek Sch-M blokuje wszystkie operacje zewnętrzne, dopóki zamek nie zostanie zwolniony.

Niektóre operacje w języku manipulacji danymi (DML), takie jak obcinanie tabel, używają blokad Sch-M, aby uniemożliwić dostęp do tabel podlegających usterce przez jednoczesne operacje.

Aparat baz danych używa blokad stabilności schematu (Sch-S) podczas kompilacji i wykonywania zapytań. Blokady Sch-S nie blokują żadnych blokad transakcyjnych, w tym blokad wyłącznych (X). Dlatego inne transakcje, w tym transakcje z blokadami X w tabeli, są kontynuowane podczas kompilowania zapytania. Jednak współbieżne operacje DDL i współbieżne operacje DML, które uzyskują blokady Sch-M, nie mogą być wykonywane na stole.