Gemeinsame Sperre für IsolationLevel.ReadUncommitted

Ich habe gelesen, dass die Abfrage keine Sperren ausgeben sollte, wenn ich IsolationLevel.ReadUncommitted verwende. Als ich dies testete, sah ich jedoch das folgende Schloss:

Resource_Type: HOBT
Request_Mode: S (gemeinsam genutzt)

Was ist ein HOBT-Schloss? Etwas im Zusammenhang mit HBT (Heap oder Binary Tree Lock)?

Warum sollte ich immer noch ein S-Schloss bekommen?

Wie vermeide ich das gemeinsame Sperren bei Abfragen, ohne die Snapshot-Option für die Isolationsstufe zu aktivieren?

Ich teste dies auf SQLServer 2008 und die Snapshot-Option ist deaktiviert. Die Abfrage führt nur eine Auswahl durch.

Ich kann sehen, dass Sch-S erforderlich ist, obwohl SQL Server es in meiner Sperrabfrage nicht anzuzeigen scheint. Wie kommt es, dass immer noch ein Shared Lock ausgegeben wird? Gemäß:

SET TRANSACTION ISOLATION LEVEL (Transact-SQL)

Transaktionen, die auf dieser READ UNCOMMITTEDEbene ausgeführt werden, setzen keine gemeinsam genutzten Sperren aus, um zu verhindern, dass andere Transaktionen die von der aktuellen Transaktion gelesenen Daten ändern.

Ich bin also etwas verwirrt.

Was ist eine HOBT-Sperre?

Eine Sperre zum Schutz eines B-Baums (Index) oder der Heap-Datenseiten in einer Tabelle ohne Clustered-Index.

Warum sollte ich immer noch ein S-Schloss bekommen?

Dies geschieht auf Haufen. Beispiel

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;

Ausgabe 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 

Ausgabe 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 

Laut diesem Artikel, der auf Paul Randal verweist, besteht der Grund für die Verwendung dieser BULK_OPERATIONgemeinsam genutzten HOBT-Sperre darin, das Lesen unformatierter Seiten zu verhindern.

Die Isolationsstufe ReadUncommitted erfasst Sperren. Schemastabilitätssperren verhindern, dass die Objekte, die Abfragen sind, geändert werden, während die Abfrage ausgeführt wird. Diese Sperren werden unter allen Isolationsstufen einschließlich Snapshot und read_committed_snapshot (RCSI) erfasst. Aus Sperrmodi :

Schemasperren

Das Datenbankmodul verwendet Schemasperren (Sch-M) während einer DDL-Operation (Table Data Definition Language), z. B. Hinzufügen einer Spalte oder Löschen einer Tabelle. Während der Haltezeit verhindert die Sch-M-Sperre den gleichzeitigen Zugriff auf die Tabelle. Dies bedeutet, dass die Sch-M-Sperre alle externen Vorgänge blockiert, bis die Sperre aufgehoben wird.

Einige DML-Operationen (Data Manipulation Language), z. B. das Abschneiden von Tabellen, verwenden Sch-M-Sperren, um den Zugriff auf betroffene Tabellen durch gleichzeitige Operationen zu verhindern.

Das Datenbankmodul verwendet beim Kompilieren und Ausführen von Abfragen Sch-S-Sperren (Schemas). Sch-S-Sperren blockieren keine Transaktionssperren, einschließlich exklusiver (X) Sperren. Daher werden andere Transaktionen, einschließlich Transaktionen mit X-Sperren für eine Tabelle, weiterhin ausgeführt, während eine Abfrage kompiliert wird. Gleichzeitige DDL-Operationen und gleichzeitige DML-Operationen, die Sch-M-Sperren erwerben, können jedoch nicht für die Tabelle ausgeführt werden.