Pourquoi blocs UPDATE SELECT sur les lignes non liées?

Question

Avoir la table, définie par le script [1], j'exécuter des scripts dans 2 fenêtres de 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

et après 1)

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

Indépendamment du niveau d'isolation des transactions en 1) fenêtre, le SELECT 2) est bloquée.
Pourquoi?

Est-ce que le niveau d'isolement UPDATE ont une influence sur les déclarations sur d'autres transactions?

Le niveau d'isolement le plus élevé est de lecture par défaut dans 2 ENGAGE).
Aucun verrou de gamme sont attribués, SELECT aurait dû souffert de COMMIS READS (Lectures non reproductibles) et PHANTOM READS (Reads répétable) problèmes [2]
Comment faire souffrir?

Comment effectuer la mise à jour sans bloquer SELECT?

[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]
Copier-coller ou ajouter de fin) après avoir cliqué sur
http://en.wikipedia.org/wiki/Isolation_(database_systems )

Mise à jour:
SELECT AVEC (NOLOCK) n'est pas bloqué ...

Update2:
ou, ce qui est la même chose, READ UNCOMMITTED

Notez que UPDATE est différent de la ligne SELECT.
Même si sur le même, ce comportement contredit à la description des niveaux d'isolement [2]

Les points sont les suivants:

• suppose que je ne peux pas savoir qui d'autre va SELECT de la même table (UPDATE-d) mais sans rapport avec les lignes à jour
• pour comprendre les niveaux d'isolement [2]

SQL Server 2008 R2 Dev

Answer 1

Je crois qu'il est parce que vous ne disposez pas d'une clé primaire, qui je pense est traduit par les verrous étant plus élevés, donc le blocage de la commande SELECT. Si vous ajoutez une clé primaire sur la colonne ID, vous remarquerez que si vous essayez à nouveau, le SELECT retournera les 3 autres lignes maintenant -. Aucune (NOLOCK) nécessaire indice

Answer 2

après de nouveaux essais

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

SELECT 2) est toujours bloqué

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

SELECT 2) n'est pas bloqué

Si de modifier 2)

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

montre que 2b) ne soit pas bloqué même en l'absence de tout indice ou PK.

Bien que, 2b), sans aucun index, est bloquée après avoir modifié 1) UPDATE pour fonctionner sous serializable mais pas sous REPEATABLE READ ou moins

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

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

Alors, il ressemble à une sélection multiple de la ligne tente d'acquérir un verrou non partageable?

Mise à jour:
Eh bien, dans tous les cas de SELECT bloqué, il est en attente d'acquérir LCK_M_IS
Une bonne raison de cette cuisine uderstand

Update2:
Eh bien, il est mise à jour ne verrou qui est escaladé sur la table, il est verrouille SELECT (partagé) (lorsque SELECT tente de lire plusieurs lignes) sont escaladé à un verrou de table et ne peut être accordée parce que la table a déjà exclusive (mise à jour ) verrouillage.

Et la présence ou l'absence d'index était sans rapport avec ma question principale

je déplace la discussion sur ce sujet à ma suggestion soumise "Intention tolets ne doit pas être aboutir à un verrou de table si une table contient déjà un verrou exclusif"