Làm thế nào để ngăn chặn các bế tắc phân vùng cột trên CHỌN

Tôi có ba bảng Chỉ mục cột phân cụm (CCI) trong SQL Server 2016. Tất cả các CCI này đều nằm trong cùng một sơ đồ phân vùng, dựa trên ID đối tượng thuê. Gần đây, và không nhất quán, tôi đang gặp bế tắc về các câu lệnh chọn đơn giản từ các phép nối đến các bảng này. Ví dụ truy vấn mà bế tắc:

SELECT  TOP 33 r.tenantid
FROM    Table_r r
        INNER JOIN Table_cm cm ON r.MyKey=cm.MyKey 
        INNER JOIN Table_pe pe ON r.MyKey=pe.MyKey 
WHERE   r.TenantId = 69
        AND pe.TenantId = 69
        AND cm.TenantId = 69

Thông báo lỗi:

Giao dịch (ID quy trình 56) đã bị bế tắc trên các tài nguyên đối tượng có thể chờ chung với một quy trình khác và đã được chọn làm nạn nhân của bế tắc. Chạy lại giao dịch.

Manh mối:

• Nếu truy vấn sử dụng một chỉ mục khác ngoài CCI, nó không bế tắc.
• Nếu tôi loại bỏ hai trong số ba bộ lọc tenantid thì nó không bị bế tắc.
• Nếu tôi CHỌN top 32 hoặc thấp hơn thì nó không bế tắc.
• Nếu tôi thêm TÙY CHỌN (MAXDOP 1) thì nó không bế tắc.
• Tôi có thể repro điều này trong bản sao sản xuất bị xáo trộn của mình, thứ cấp CHỈ ĐỌC HIỂU và chính sản xuất.
• Tôi không thể repro hành vi này trong DEV hoặc INT.
• Nó vẫn bế tắc nếu tôi thêm VỚI (NOLOCK) cho cả 3 bảng tham gia
• Các truy vấn bế tắc chính nó. Nó sẽ bế tắc khi không có quá trình hoạt động khác.
• Các kế hoạch truy vấn không có song song không bế tắc

Bế tắc xml đây

Phiên bản sản xuất của chúng tôi:

Microsoft SQL Server 2016 (SP2-CU5) (KB4485776) - 13.0.5264.1 (X64) ngày 10 tháng 1 năm 2019 18:51:38 Bản quyền (c) Microsoft Corporation Enterprise Edition (64-bit) trên Windows Server 2012 R2 Standard 6.3 (Build 9600 :) (Hypervisor)

Làm cách nào để ngăn chặn bế tắc đối với truy vấn này?

Vì bạn đang sử dụng SQL Server 2016, nên đề cập rằng có ít nhất một sửa lỗi công khai cho các khóa chết song song liên quan đến các chỉ mục của cột:

CỐ ĐỊNH: Bế tắc xảy ra khi bạn chạy truy vấn song song trên một chỉ mục cửa hàng cột trong SQL Server 2016 và 2017

(cảm ơn Denis Rubashkin đã cung cấp liên kết ban đầu)

Điều này đã được phát hành như một phần của SP1 CU7. Nếu bạn không theo CU đó, bạn nên cho nó một shot. Khắc phục sự cố này cũng sẽ được bao gồm trong SP2 (bất kỳ CUs nào).

Nói chung, hai cách tiếp cận để khắc phục các bế tắc song song truy vấn nội bộ:

• song song tránh (bằng cách điều chỉnh các truy vấn để nó không đi song song, sử dụng một MAXDOPgợi ý, vv) - điều này được bao phủ trong câu trả lời khác bởi Thomas Costers
• áp dụng gói dịch vụ / cập nhật tích lũy mới nhất cho SQL Server

Bạn đã kiểm tra blog sau đây về Bế tắc chủ đề song song truy vấn nội bộ

Tài SyncPointnguyên cho biết việc sử dụng một sự kiện trao đổi nếu tôi không nhầm.
Nhìn vào những người tham gia bế tắc của bạn, bạn có thể thấy rằng tất cả họ đều đến từ cùng một spid (55) và đợt (0), nhưng đang sử dụng các luồng khác nhau. Điều này cho thấy rằng tất cả chúng đều là một phần của cùng một truy vấn song song và được xác nhận bởi thực tế là bạn không nhận được bất kỳ bế tắc nào mỗi khi bạn chạy truy vấn MAXDOP 1. Trong trường hợp Bế tắc luồng song song truy vấn nội bộ, các luồng của một truy vấn sẽ kết thúc bế tắc chờ đợi các đối tượng đồng bộ hóa, SyncPoints trong trường hợp của bạn.

Lần trước khi tôi chứng kiến ​​loại hành vi này, tôi có thể tối ưu hóa hơn nữa truy vấn và do đó ngăn truy vấn sử dụng kế hoạch thực hiện song song. Tôi nghi ngờ bạn đã làm điều tương tự bằng cách giới hạn kết quả của bạn được đặt thành 32 bản ghi hoặc bằng cách sử dụng một chỉ mục khác.
Một tùy chọn khác sẽ là thêm MAXDOP 1vào truy vấn của bạn, mặc dù không phải là một fan hâm mộ lớn của tùy chọn này.

Nhưng trước khi loay hoay với hai tùy chọn đó, trước tiên hãy kiểm tra xem bạn có đang sử dụng SP / CU mới nhất không.