Hai truy vấn gây ra bế tắc là SELECT bên dưới (process id="process3980de4558" ):
select @existing = team_it_cube_attr_05 from tbl_Ref_Attr_Prod_Team where prod_id = @rec_key
Và UPDATE truy vấn bên dưới (process id="process386ed48188" ):
UPDATE D
SET D.team_rss_attr_01 = LEFT(S.mkt_prodchar_13,25)...
<resource-list> phần ghi chú SELECT truy vấn sở hữu một khóa (X) độc quyền trên một trang và đang cố gắng lấy một khóa chia sẻ ý định (IS) trên một trang khác trong khi trang đó đang đọc dữ liệu. UPDATE truy vấn đã sở hữu khóa IS và đã tryign để có được khóa X trên một trang để thực hiện cập nhật.
Đưa ra phép nối với bảng này:
...from tbl_Ref_Attr_Prod_Team where prod_id = @rec_key...
...INNER JOIN tbl_Ref_Attr_Prod_Team D ON D.prod_key=P.prod_key...
SELECT truy vấn đã sở hữu một khóa độc quyền. Điều này có thể có nghĩa là nó là một phần của giao dịch lớn hơn đã thực hiện UPDATE trong một truy vấn trước. Các khóa từ các truy vấn trước sẽ được duy trì để bảo toàn tính toàn vẹn của dữ liệu trong quá trình giao dịch (tùy thuộc vào mức cách ly giao dịch
).
UPDATE truy vấn cần đọc bảng tbl_Ref_Attr_Prod_team . Nó có được các khóa được chia sẻ mục đích trên các trang và hàng trong khi đọc dữ liệu. Khi UPDATE truy vấn tìm các hàng phù hợp, nó sẽ cố gắng chuyển đổi các khóa IS thành khóa X. Khóa IS không tương thích với khóa X. Bởi vì SELECT truy vấn đã có khóa IS trên một hoặc nhiều trang đó, các truy vấn sẽ bế tắc với nhau.
Một nguyên nhân có thể là thiếu chỉ mục trên tbl_Ref_Attr_Prod_team.prod_key . Không có chỉ mục trên cột này, UPDATE truy vấn sẽ quét tất cả các hàng trong bảng tbl_Ref_Attr_Prod_team .
Ngay cả khi một chỉ mục tồn tại trên prod_key , nếu có một số lượng nhỏ hàng trong bảng, SQL Server có thể quyết định rằng hiệu suất sẽ tốt hơn nếu truy vấn quét toàn bộ bảng thay vì tìm kiếm chỉ mục. Ghi lại kế hoạch truy vấn khi xảy ra bế tắc sẽ xác minh lý thuyết này.
Chúng ta thường xuyên gặp phải các deadlock bảng nhỏ khi tạo cơ sở dữ liệu mới. Ban đầu, các bảng là rất nhỏ, và việc quét bảng gây ra tất cả các loại bế tắc. Sau đó, khi các bảng lớn hơn, chi phí tính toán của việc quét bảng sẽ vượt quá chi phí tìm kiếm chỉ mục và tình trạng bế tắc không còn xảy ra nữa. Trong môi trường thử nghiệm mà số lượng hàng luôn nhỏ, chúng tôi đã sử dụng FORESEEK và WITH INDEX gợi ý để buộc tìm kiếm chỉ mục thay vì quét. Chúng tôi rất mong có thể buộc các kế hoạch truy vấn thông qua tính năng lưu trữ truy vấn của SQL Server 2016.
