CHỌN / CHERTN Bế tắc

Trường hợp này lưu trữ cơ sở dữ liệu SharePoint 2007 (SP). Chúng tôi đã trải qua nhiều bế tắc CHỌN / CHERTN đối với một bảng được sử dụng nhiều trong cơ sở dữ liệu nội dung SP. Tôi đã thu hẹp các tài nguyên liên quan, cả hai quá trình đều yêu cầu khóa trên chỉ mục không được nhóm.
INSERT cần khóa IX trên tài nguyên SELECT và SELECT cần khóa S trên tài nguyên INSERT. Biểu đồ khóa chết mô tả và ba tài nguyên, 1.) hai từ CHỌN (các luồng song song của nhà sản xuất / người tiêu dùng) và 2.) INSERT.
Tôi đã đính kèm biểu đồ bế tắc cho đánh giá của bạn. Bởi vì đây là cấu trúc mã và bảng của Microsoft, chúng tôi không thể thực hiện bất kỳ thay đổi nào.
Tuy nhiên, tôi đã đọc, trên trang web MSFT SP, họ khuyên bạn nên đặt tùy chọn cấu hình mức Instance MAXDOP thành 1. Vì trường hợp này được chia sẻ giữa nhiều cơ sở dữ liệu / ứng dụng khác, cài đặt này không thể bị tắt.

Do đó, tôi quyết định thử và ngăn các câu lệnh CHỌN này đi song song. Tôi biết đây không phải là một giải pháp mà là sửa đổi tạm thời để giúp khắc phục sự cố. Do đó, tôi đã tăng Ngưỡng chi phí của bộ xử lý song song từ 25 đến 40 tiêu chuẩn của chúng tôi khi làm như vậy, mặc dù khối lượng công việc không thay đổi (CHỌN / XÁC thường xuyên xảy ra) các bế tắc đã biến mất. Câu hỏi của tôi là tại sao?

SPID 356 INSERT có khóa IX trên một trang thuộc chỉ mục không phân cụm
SPID 690 CHỌN ID thực thi 0 có khóa S trên một trang thuộc cùng một chỉ mục không được phân cụm

Hiện nay

SPID 356 muốn khóa IX trên tài nguyên SPID 690 nhưng không thể giữ được vì SPID 356 đang bị chặn bởi SPID 690 ID thực thi 0 S khóa
SPID 690 ID thực thi 1 muốn khóa S trên tài nguyên SPID 356 nhưng không thể lấy được vì ID thực thi SPID 690 1 đang bị chặn bởi SPID 356 và bây giờ chúng tôi có bế tắc.

Kế hoạch thực hiện có thể được tìm thấy trên SkyDrive của tôi

Chi tiết bế tắc đầy đủ có thể được tìm thấy ở đây

Nếu ai đó có thể giúp tôi hiểu tại sao tôi thực sự đánh giá cao nó.

Bảng EventReceivers.
Id uniqueidentifier không 16
Tên nvarchar không 512
SiteID uniqueidentifier không 16
WebId uniqueidentifier không 16
hostid uniqueidentifier không 16
HOSTTYPE int không 4
ItemID int không 4
dirname nvarchar không 512
LeafName nvarchar không 256
Loại int không 4
SequenceNumber int không 4
hội nvarchar không 512
Lớp nvarchar không 512
Dữ liệu nvarchar no 512
Bộ lọc nvarchar no 512
SourceId tContentTypeId no 512
SourceType int no 4
Credential int no 4
ContextType varbinary no 16
ContextEventType varbinary không 16
ContextId varbinary không 16
ContextObjectId varbinary không 16
ContextCollectionId varbinary không 16

INDEX_NAME index_description index_keys
EventReceivers_ByContextCollectionId nonclustered nằm trên TIỂU SiteID, ContextCollectionId
EventReceivers_ByContextObjectId nonclustered nằm trên TIỂU SiteID, ContextObjectId
EventReceivers_ById nonclustered, độc đáo nằm trên TIỂU SiteID, Id
EventReceivers_ByTarget nhóm, độc đáo nằm trên TIỂU SiteID, WebId, hostid, HOSTTYPE, Type, ContextCollectionId, ContextObjectId, ContextId, ContextType, ContextEventType, SequenceNumber, hội, Class
EventReceivers_IdUnique không bao gồm, khóa duy nhất, duy nhất nằm trên Id PRIMARY

Trên mặt của nó, điều này trông giống như một bế tắc tra cứu cổ điển . Các thành phần thiết yếu cho mẫu bế tắc này là:

• một SELECTtruy vấn sử dụng một chỉ mục không bao gồm không bao gồm với Tra cứu khóa
• một INSERTtruy vấn sửa đổi chỉ mục được nhóm và sau đó là chỉ mục không bao gồm

Các SELECTtruy cập chỉ mục không bao gồm đầu tiên, sau đó chỉ mục cụm. Việc INSERTtruy cập chỉ mục được nhóm trước, sau đó là chỉ mục không bao gồm. Truy cập cùng một tài nguyên theo một thứ tự khác có được các khóa không tương thích là một cách tuyệt vời để 'đạt được' một sự bế tắc tất nhiên.

Trong trường hợp này, SELECTtruy vấn là:

... và INSERTtruy vấn là:

Lưu ý bảo trì chỉ mục không phân cụm màu xanh lá cây nổi bật.

Chúng ta sẽ cần phải xem phiên bản nối tiếp của SELECTkế hoạch trong trường hợp nó rất khác so với phiên bản song song, nhưng như Jonathan Kehayias lưu ý trong hướng dẫn của mình về Xử lý các bế tắc , mẫu khóa cụ thể này rất nhạy cảm với các chi tiết thực hiện truy vấn nội bộ và thời gian. Loại bế tắc này thường đến và đi mà không có lý do bên ngoài rõ ràng.

Được cấp quyền truy cập vào hệ thống có liên quan và các quyền phù hợp, tôi chắc chắn cuối cùng chúng ta cũng có thể tìm ra chính xác lý do tại sao bế tắc xảy ra với kế hoạch song song nhưng không phải là nối tiếp (giả sử có cùng hình dạng chung). Dòng tiềm năng của cuộc điều tra bao gồm kiểm tra các vòng lặp lồng nhau tối ưu hóa và / hoặc tìm nạp trước - cả hai đều có nội có thể leo thang mức độ cách ly để REPEATABLE READtrong suốt thời gian báo cáo kết quả. Cũng có thể một số tính năng của chỉ mục tìm kiếm phạm vi song song góp phần vào vấn đề. Nếu kế hoạch nối tiếp trở nên khả dụng, tôi có thể dành thời gian để xem xét chi tiết hơn nữa, vì nó có khả năng thú vị.

Giải pháp thông thường cho loại bế tắc này là làm cho chỉ số bao trùm, mặc dù số lượng cột trong trường hợp này có thể khiến điều đó không thực tế (và bên cạnh đó, chúng tôi không được phép gây rối với những điều như vậy trên SharePoint, tôi được cho biết). Cuối cùng, đề xuất cho các kế hoạch chỉ nối tiếp khi sử dụng SharePoint là có lý do (mặc dù không nhất thiết phải là một kế hoạch tốt, khi nó đi thẳng vào nó). Nếu sự thay đổi trong ngưỡng chi phí cho sự song song khắc phục vấn đề tại thời điểm này, điều này là tốt. Về lâu dài, tôi có thể tìm cách tách khối lượng công việc, có thể sử dụng Resource Governor để các truy vấn nội bộ SharePoint có MAXDOP 1hành vi mong muốn và ứng dụng khác có thể sử dụng song song.

Câu hỏi về sự trao đổi xuất hiện trong dấu vết bế tắc dường như là một cá trích đỏ đối với tôi; chỉ đơn giản là hệ quả của các luồng độc lập sở hữu tài nguyên mà về mặt kỹ thuật phải xuất hiện trong cây. Tôi không thể thấy bất cứ điều gì cho thấy rằng các sàn giao dịch đang đóng góp trực tiếp vào vấn đề bế tắc.

Nếu đây là một bế tắc tra cứu cổ điển , danh sách tài nguyên sẽ bao gồm cả Chỉ mục cụm và Chỉ mục không cụm. Thông thường, CHỌN sẽ giữ khóa CHIA SẺ trên chỉ mục NC và đợi khóa CHIA SẺ trên CI, trong khi đó, INSERT sẽ nhận được khóa ĐỘC QUYỀN trên CI và chờ khóa ĐỘC QUYỀN trên NC. Danh sách tài nguyên trong xml deadlock sẽ liệt kê cả hai đối tượng này trong trường hợp này.

Vì biểu đồ khóa chết chỉ liên quan đến Chỉ số NC, chúng tôi có thể loại trừ tùy chọn đó.

Ngoài ra, nếu đây là một khóa chết do Nested Loop Tham gia với UNORDERED PREFECH , kế hoạch thực hiện sẽ cho chúng ta biết liệu thuật toán UNORDERED PREFECH có được sử dụng hay không, xem lại ở đây (xem cập nhật bên dưới).

Điều đó khiến chúng ta cho rằng đây là một sự bế tắc do Kế hoạch song song.

Biểu đồ khóa chết không được hiển thị đúng, nhưng nếu bạn nhìn vào Deadlock XML, bạn có thể thấy hai luồng từ câu lệnh SELECT (SPID 690) có liên quan đến khóa chết. Chủ đề người tiêu dùng đang giữ khóa CHIA SẺ trên TRANG 1219645 và chờ nhà sản xuất trên port801f8ed0 (e_waitPipeGetRow). Chủ đề của nhà sản xuất đang chờ khóa chia sẻ trên TRANG 1155940.

Câu lệnh INSERT đang giữ khóa IX trên TRANG 1155940 và chờ khóa IX trên TRANG 1219645, dẫn đến bế tắc.

Tôi tin rằng một bế tắc sẽ được đảo ngược khi sử dụng một kế hoạch nối tiếp cho câu lệnh CHỌN vì không có lúc nào nó sẽ yêu cầu khóa CHIA SẺ trên nhiều trang. Tôi cũng nghĩ rằng kế hoạch nối tiếp sẽ gần giống như kế hoạch song song (sans toán tử song song).

[CẬP NHẬT dựa trên bình luận của Paul]

Rõ ràng kế hoạch đang sử dụng thuật toán Nested Loop được tối ưu hóa

Điều đó giải thích tại sao các khóa SHARED được giữ cho đến khi kết thúc câu lệnh. REPEATABLE READ kết hợp với kế hoạch song song dễ bị bế tắc hơn so với kế hoạch nối tiếp bởi vì kế hoạch song song có thể thu được và giữ các khóa từ các phạm vi khác nhau của một chỉ mục trong khi kế hoạch nối tiếp có được các khóa theo cách tuần tự hơn.