Tất cả các deadlocks gây ra bởi truy vấn không hợp lệ

Question

"Giao dịch (Process ID 63) đã bị khóa trên tài nguyên bộ đệm giao tiếp với một tiến trình khác và đã được chọn làm nạn nhân bế tắc. Chạy lại giao dịch.". Lý do thất bại có thể xảy ra: Sự cố với truy vấn, thuộc tính "ResultSet" không được đặt chính xác, các thông số không được đặt chính xác hoặc kết nối không được thiết lập chính xác. "

Bối cảnh này có thể gây ra bởi nội dung được lưu trữ proc sử dụng như thư SQL không? nó luôn luôn gây ra một cái gì đó của tôi giống như hai ứng dụng truy cập cùng một bảng cùng một lúc?

Answer 1

Hai bảng truy cập cùng một bảng cùng một lúc xảy ra mọi lúc trong một ứng dụng. Nói chung điều đó sẽ không gây ra bế tắc. Một bế tắc thường xảy ra khi bạn nói quá trình 'A' cố gắng cập nhật Bảng 1 và sau đó là Bảng 2 và sau đó là Bảng 3, và bạn có quá trình 'B' cố gắng cập nhật Bảng 3, rồi Bảng 2, và sau đó là Bảng 1. Quy trình ' A 'sẽ có một nguồn tài nguyên bị khóa mà quá trình' B 'cần và quá trình' B 'có một quy trình tài nguyên' A 'cần. SQL Server phát hiện điều này dưới dạng bế tắc và cuộn một trong các quy trình trở lại, dưới dạng giao dịch không thành công.

Điểm mấu chốt là bạn có hai quy trình cố gắng cập nhật cùng một bảng cùng một lúc, nhưng không theo cùng một thứ tự. Điều này thường sẽ dẫn đến deadlocks.

Một cách dễ dàng để xử lý điều này trong ứng dụng của bạn là xử lý giao dịch không thành công và chỉ cần thực hiện lại giao dịch. Nó sẽ hầu như luôn luôn thực hiện thành công. Một giải pháp tốt hơn là đảm bảo rằng các quy trình của bạn đang cập nhật các bảng theo cùng một thứ tự, càng nhiều càng tốt.

Answer 2

Thiếu chỉ mục là một nguyên nhân phổ biến khác gây ra sự tắc nghẽn. nó sẽ không bị chặn bởi bất kỳ bản cập nhật/chèn nào trên chính bảng.

Để tìm hiểu chắc chắn, hãy sử dụng trình lược tả SQL để theo dõi các sự kiện "Biểu đồ khóa chết" sẽ cho bạn thấy chi tiết của bế tắc.

Answer 3

Dựa trên this, tôi không nghĩ rằng chính SQL Mail sẽ trực tiếp là thủ phạm. Tôi nói "trực tiếp" vì tôi không biết bạn đang làm gì với nó. Tuy nhiên, tôi giả sử SQL Mail có thể chậm so với phần còn lại của các lệnh SQL của bạn, vì vậy nếu bạn đang làm rất nhiều với điều đó, nó gián tiếp có thể tạo ra một nút cổ chai dẫn đến bế tắc nếu bạn đang nắm giữ lên bảng trong khi gửi thư SQL.

Thật khó để đề xuất một chiến lược cụ thể mà không có quá nhiều chi tiết cụ thể về những gì bạn đang làm. Ngắn gọn của nó là bạn nên xem xét liệu có một cách để phá vỡ sự phụ thuộc của bạn trên nắm giữ lên bàn trong khi bạn đang làm điều này như sử dụng NOLOCK, bằng cách sử dụng một bảng tạm thời hoặc không tạm thời "giữ" bảng hoặc chỉ refactoring SP đang thực hiện cuộc gọi.