Warum SELECT UPDATE Blöcke auf unabhängige Reihen?

Question

Mit der Tabelle, von Skript [1] definiert, führe ich Skripte in 2 Fenstern von SSMS

--1) first in first SSMS window
set transaction isolation level READ UNCOMMITTED;
begin transaction;
update aaa set Name ='bbb' 
    where id=1;
-- results in "(1 row(s) affected)"
--rollback

und nach 1)

--2)after launching 1)
select * from aaa --deleted comments
where id<>1
--is blocked

Unabhängig auf Transaktionsisolationsstufe in 1) Fenster wird das SELECT in 2) blockiert.
Warum?

Does Isolationsstufe für UPDATE hat keinen Einfluss auf Aussagen zu anderen Transaktionen?

Die höchste Isolationsstufe ist standardmäßig READ COMMITTED in 2).
Keine Bereichssperren zugeschrieben werden, sollte SELECT haben von ENGAGIERTE gelitten LIEST (nicht wiederholbare Lesevorgänge) und PHANTOM LIEST (wiederholbar Aufrufe) Probleme [2]
Wie man es leiden?

Wie kann UPDATE ohne Blockierung SELECT gemacht werden?

[1]

CREATE TABLE aaa
(
    Id int IDENTITY(1,1) NOT NULL,
    Name  varchar(13) NOT NULL
)


insert into  aaa(Name) 
   select '111' union all 
   select '222' union all 
   select '333' union all 
   select '444' union all 
   select '555' union all 
   select '666' union all 
   select '777' union all 
   select '888'  

[2]
Copy & Paste oder fügen Sie Hinter) beim Anklicken
http://en.wikipedia.org/wiki/Isolation_(database_systems )

Update:
SELECT WITH (NOLOCK) nicht blockiert ist ...

Update2:
oder mit, was dasselbe ist, READ UNCOMMITTED

Beachten Sie, dass UPDATE auf verschiedene von SELECT Reihe ist.
Selbst, wenn auf dem gleichen, dieses Verhalten im Widerspruch zur Beschreibung der Isolationsstufen [2]

Die Punkte sind folgende:

• nehme ich kann nicht wissen, wer sonst noch aus der gleichen (UPDATE-d) Tabelle auswählen wird, aber auf keinem Zusammenhang Zeilen zu aktualisieren
• Isolationsstufen [2]
verstehen

SQL Server 2008 R2 Dev

Answer 1

Ich glaube, es ist, weil Sie nicht über einen Primärschlüssel haben, was ich denke, ist was die Sperren eskaliert werden, damit die Blockierung der SELECT aus. Wenn Sie einen Primärschlüssel auf die ID-Spalte hinzufügen, werden Sie feststellen, dass, wenn Sie erneut versuchen, kehrt die SELECT die anderen drei Reihen jetzt - Nr. WITH (NOLOCK) Hinweis erforderlich

Answer 2

Wiederholen Tests nach

--3)
create index IX_aaa_ID on aaa(id)

SELECT 2) noch gesperrt

--4)
drop index IX_aaa_ID on aaa
create unique index IX_aaa_ID on aaa(id)
--or adding primary key constraint   

SELECT 2) nicht gesperrt

Wenn 2 ändern) als

--2b)
select * from aaa 
    where id=3 
    --or as
    --WHERE id=2 

zeigt, dass 2b) auch in Abwesenheit eines Index oder PK nicht blockiert wird.

Obwohl, 2b), ohne Indizes, blockiert nach der Änderung 1) UPDATE unter serializable laufen aber nicht unter WIEDERHOLBARE READ oder weniger

--1c)  
set transaction isolation level serializable;
--set transaction isolation level REPEATABLE READ;

begin transaction;
update aaa set Name ='bbb' 
    where id=1;
--rollback

So sieht es aus wie mehrere Zeilenauswahlversuche acquire nichtteilbaren Sperre?

Update:
Nun, in allen Fällen von SELECT blockiert es wartet auf acquire LCK_M_IS
Grund genug, diese Küche uderstand

Update2:
Nun, es nicht UPDATE Sperre ist, die auf dem Tisch eskaliert ist, ist es SELECT (gemeinsam) Schlösser (wenn SELECT versucht mehrere Zeilen zu lesen) zu einer Tabellensperre eskaliert sind und nicht gewährt werden, da Tabelle bereits exklusiv hat (UPDATE Sperre).

Und Vorhandensein oder Fehlen von Index war in keinem Zusammenhang mit meiner primären Frage

Ich verschiebe die Diskussion über dieses Thema zu meinen eingereichten Vorschlag "Intent Dollen sollte nicht zu einer Tabellensperre eskaliert werden, wenn eine Tabelle enthält bereits exklusive Sperre"