¿Por qué bloques Seleccione Actualización de filas no relacionadas?

Question

Tener la mesa, definido por la escritura [1], me ejecutar secuencias de comandos en 2 ventanas 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

y después de 1)

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

Independientemente del nivel de aislamiento de transacción en 1) ventana, el SELECT en 2) está bloqueada.
¿Por qué?

¿El nivel de aislamiento para la actualización tiene ninguna influencia en las declaraciones sobre otras transacciones?

El nivel de aislamiento más alta es leído por defecto cometidos en 2).
No hay bloqueos de rango se atribuyen, SELECT debería haber sufrido de COMPROMETIDO LEE (no repetibles lecturas) y las lecturas fantasma (repetible lecturas) problemas [2]
Cómo hacer que sufren?

¿Cómo puede actualizar hacerse sin bloquear 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]
Copiar y pegar o añadir final) Al hacer clic en
http://en.wikipedia.org/wiki/Isolation_(database_systems )

Actualización:
SELECT con (NOLOCK) no está bloqueado ...

Update2:
o, lo que es lo mismo, la lectura no confirmada

Tenga en cuenta que está en ACTUALIZACIÓN diferente de selección de fila.
Incluso, si en el mismo, este comportamiento contradice a la descripción de los niveles de aislamiento [2]

Los puntos son los siguientes:

• supongo que no puedo saber quién más se va a seleccionar de la misma tabla (ACTUALIZACIÓN-d), sino en relación a actualizar filas
• comprender los niveles de aislamiento [2]

SQL Server 2008 R2 Dev

Answer 1

Creo que es porque usted no tiene una clave principal, que creo que es lo que resulta en las cerraduras se intensificaron, por lo tanto, el bloqueo de la instrucción SELECT. Si se agregue una clave principal en la columna de ID, se dará cuenta que si intenta de nuevo, el SELECT devolverá los otros 3 filas ahora -. NO con (NOLOCK) pizca necesaria

Answer 2

Repetición de las pruebas después de

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

SELECT 2) todavía está bloqueado

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

SELECT 2) no está bloqueado

Si para modificar 2) como

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

muestra que 2b) no está bloqueado, incluso en ausencia de cualquier índice o PK.

Aunque, 2b), sin ningún tipo de índices, se bloquea después de modificar 1) UPDATE para ejecutar bajo serializable pero no bajo REPEATABLE READ o menor

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

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

Por lo tanto, parece que varios intentos de selección de fila para bloquear adquieren no compartible?

Actualización:
Pues bien, en todos los casos de SELECT siendo bloqueada que está a la espera de adquirir LCK_M_IS
Una buena razón para uderstand esta cocina

Update2:
Bueno, no es bloqueo de actualización que se intensificó en la mesa, es SELECT (compartidos) cerraduras (cuando SELECT intenta leer varias filas) se escalan a un bloqueo de tabla y no puede ser concedido porque la tabla ya ha exclusiva (ACTUALIZACIÓN ) de bloqueo.

Y la presencia o ausencia de índice no tenía relación con mi pregunta principal

Me desplazar la discusión de este tema a mi sugerencia presentada "chumaceras intención no debe ser escalada a un bloqueo de tabla si una tabla ya contiene bloqueo exclusivo"