لماذا تحديث كتل حدد على صفوف غير ذات صلة؟

Question

وجود الجدول ، محدد بواسطة البرنامج النصي [1] ، أقوم بتنفيذ البرامج النصية في نوافذ من 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

وبعد 1)

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

بشكل مستقل على مستوى عزل المعاملة في 1) نافذة ، يتم حظر تحديد 2).
لماذا ا؟

هل يكون لمستوى العزلة للتحديث أي تأثير على البيانات على المعاملات الأخرى؟

أعلى مستوى العزلة هو الافتراضي قراءة ارتكبت في 2).
لا تُعزى أي أقفال النطاق ، وينبغي أن يكون Select قد عانى من القراءات الملتزمة (قراءات غير قابلة للتكاثر) ومشاكل القراءات الوهمية (القراءات المتكررة) [2
كيف تجعلها تعاني؟

كيف يمكن إجراء التحديث دون حظر الاختيار؟

[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]
نسخ ولصق أو أضف زائدة) عند النقر فوق
http://en.wikipedia.org/wiki/isolation_(database_systems)

تحديث:
حدد مع (نولوك) غير محظور ...

Update2:
أو مع ، ما هو نفسه ، اقرأ غير ملتزم

لاحظ أن التحديث يختلف عن Select Row.
حتى ، إذا كان هذا السلوك يتناقض مع وصف مستويات العزلة [2

النقاط هي:

• لنفترض أنني لا أستطيع أن أعرف من الذي سيختار من نفس الجدول (التحديث-D) ولكن على غير مرتبط بتحديث الصفوف
• لفهم مستويات العزلة [2

SQL Server 2008 R2 Dev

Answer 1

أعتقد أن ذلك لأنه ليس لديك مفتاح أساسي ، أعتقد أنه ينتج عنه تصاعد الأقفال ، وبالتالي تمنع الاختيار. إذا قمت بإضافة مفتاح أساسي على عمود المعرف ، فستلاحظ أنه إذا حاولت مرة أخرى ، فسيقوم Select بإرجاع الصفوف الثلاثة الأخرى الآن - لا مع تلميح (Nolock) المطلوب.

Answer 2

تكرار الاختبارات بعد

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

SELECT 2) لا يزال محظورًا

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

حدد 2) لم يتم حظره

إذا تم تعديل 2) كما

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

يوضح أن 2 ب) لم يتم حظره حتى في حالة عدم وجود أي فهرس أو PK.

رغم ذلك ، 2 ب) ، بدون أي فهارس ، يتم حظره بعد تعديل 1) التحديث للتشغيل تحت تسلسل ولكن ليس تحت قراءة أو أقل

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

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

لذلك ، يبدو أن اختيار صف متعدد المحاولات لاكتساب قفل غير قابل للحماية؟

تحديث:
حسنًا ، في جميع حالات الاختيار المحظورة ، تنتظر الحصول على LCK_M_IS
سبب وجيه ل uderstand هذا المطبخ

Update2:
حسنًا ، لا يتم تصعيد قفل التحديث الذي يتم تصعيده على الجدول ، ويتم تصعيد الأقفال المحددة (المشتركة) (عندما يحاول تحديد قراءة صفوف متعددة) إلى قفل جدول ولا يمكن منحه لأن الجدول يحتوي بالفعل على قفل (تحديث) حصري.

وكان وجود أو عدم وجود فهرس غير مرتبط بسؤالي الأساسي

أقوم بتحويل مناقشة هذا الموضوع إلى اقتراحي المقدم "لا ينبغي تصعيد Rowlocks القصد إلى قفل جدول إذا كان جدول يحتوي بالفعل على قفل حصري"