Exklusivität von X Sperren gegen U Schlösser
In der Schlosskompatibilitätsmatrix unten ist ersichtlich, dass das X lock ist nur mit den Sperrtypen Schemastabilität und Insert Range-Null kompatibel. U ist kompatibel mit den folgenden zusätzlichen Shared-Lock-Typen S /IS /RS-S /RI-S /RX-S
Kompatibilitätsmatrix für Sperren http://i.msdn.microsoft.com/ms186396.LockConflictTable(de-de,SQL.105).gif
Granularität von X Schlösser
Diese werden auf allen Ebenen gut herausgenommen. Das Skript und der Profiler-Trace unten zeigen, dass sie erfolgreich auf Zeilenebene entfernt wurden.
CREATE TABLE test_table (id int identity(1,1) primary key, col char(40))
INSERT INTO test_table
SELECT NEWID() FROM sys.objects
select * from test_table with (rowlock,XLOCK) where id=10
Aber Zeilen können trotzdem gelesen werden!
Es stellt sich heraus, dass bei read committed Isolationsstufe SQL Server entfernt S nicht immer locks, wird dieser Schritt übersprungen, wenn keine Gefahr besteht, nicht festgeschriebene Daten ohne sie zu lesen. Das bedeutet, dass es keine Garantie dafür gibt, dass jemals ein Sperrkonflikt auftritt.
Wenn die anfängliche Auswahl jedoch with (paglock,XLOCK) ist dann wird Stoppen Sie die Lesetransaktion als X lock auf der Seite blockiert den IS Seitensperre, die vom Leser immer benötigt wird. Dies wirkt sich natürlich auf die Parallelität aus.
Weitere Vorbehalte
Selbst wenn Sie die Zeile/Seite sperren, bedeutet dies nicht, dass Sie alle Zugriffe auf diese Zeile in der Tabelle blockieren. Eine Sperre für eine Zeile im Clustered-Index verhindert nicht, dass Abfragen Daten aus der entsprechenden Zeile in einem abdeckenden Non-Clustered-Index lesen.
