Bế tắc về Xóa Tuyên bố

Tôi gặp bế tắc khi SQL Server Job chạy. Sự bế tắc xảy ra trên một câu lệnh XÓA đơn giản. Tôi có thể nghĩ rằng sẽ phải có một truy vấn CHỌN / CẬP NHẬT đang chạy để gây ra bế tắc? Nhưng có vẻ như nó đang XÓA / XÓA bế tắc ...

Những gì tôi đang tìm kiếm là lý do tại sao tôi nhận được một bế tắc XÓA / XÓA. Đó là (theo hiểu biết của tôi) truyền trong các tham số khác nhau.

Có ý kiến gì không? Cảm ơn.

deadlock-list
2014-05-20 07:30:09.66 spid25s      deadlock victim=process409048
2014-05-20 07:30:09.66 spid25s       process-list
2014-05-20 07:30:09.66 spid25s        process id=process409048 taskpriority=0 logused=0 waitresource=PAGE: 12:1:7127294 waittime=4352 ownerId=629860973 transactionname=DELETE lasttranstarted=2014-05-20T07:30:05.307 XDES=0x397219620 lockMode=U schedulerid=5 kpid=3792 status=suspended spid=150 sbid=0 ecid=3 priority=0 trancount=0 lastbatchstarted=2014-05-20T07:30:05.307 lastbatchcompleted=2014-05-20T07:30:05.307 clientapp=QSQL25 hostname=MORRIS hostpid=1528 isolationlevel=read committed (2) xactid=629860973 currentdb=12 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
2014-05-20 07:30:09.66 spid25s         executionStack
2014-05-20 07:30:09.66 spid25s          frame procname=adhoc line=1 stmtstart=68 sqlhandle=0x020000000b887a18f75d0aa07c25a9b8630fca696aa0e5d2
2014-05-20 07:30:09.66 spid25s     DELETE FROM dbo.UserDetailsData WHERE        (Username = @P1) AND (UserDate = @P2)     
2014-05-20 07:30:09.66 spid25s          frame procname=unknown line=1 sqlhandle=0x000000000000000000000000000000000000000000000000
2014-05-20 07:30:09.66 spid25s     unknown     
2014-05-20 07:30:09.66 spid25s         inputbuf
2014-05-20 07:30:09.66 spid25s        process id=process432e08 taskpriority=0 logused=0 waitresource=PAGE: 12:1:7127916 waittime=2648 ownerId=629859744 transactionname=DELETE lasttranstarted=2014-05-20T07:30:04.833 XDES=0x4c3426b50 lockMode=U schedulerid=6 kpid=5988 status=suspended spid=146 sbid=0 ecid=3 priority=0 trancount=0 lastbatchstarted=2014-05-20T07:30:04.833 lastbatchcompleted=2014-05-20T07:30:04.820 clientapp=QSQL25 hostname=MORRIS hostpid=1528 isolationlevel=read committed (2) xactid=629859744 currentdb=12 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
2014-05-20 07:30:09.66 spid25s         executionStack
2014-05-20 07:30:09.66 spid25s          frame procname=adhoc line=1 stmtstart=68 sqlhandle=0x020000000b887a18f75d0aa07c25a9b8630fca696aa0e5d2
2014-05-20 07:30:09.66 spid25s     DELETE FROM dbo.UserDetailsData WHERE        (Username = @P1) AND (UserDate = @P2)     
2014-05-20 07:30:09.66 spid25s          frame procname=unknown line=1 sqlhandle=0x000000000000000000000000000000000000000000000000
2014-05-20 07:30:09.66 spid25s     unknown     
2014-05-20 07:30:09.66 spid25s         inputbuf
2014-05-20 07:30:09.66 spid25s        process id=process39ea562c8 taskpriority=0 logused=0 waitresource=PAGE: 12:1:7127916 waittime=4352 ownerId=629860973 transactionname=DELETE lasttranstarted=2014-05-20T07:30:05.307 XDES=0x13e0e4b50 lockMode=U schedulerid=2 kpid=7124 status=suspended spid=150 sbid=0 ecid=1 priority=0 trancount=0 lastbatchstarted=2014-05-20T07:30:05.307 lastbatchcompleted=2014-05-20T07:30:05.307 clientapp=QSQL25 hostname=MORRIS hostpid=1528 isolationlevel=read committed (2) xactid=629860973 currentdb=12 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
2014-05-20 07:30:09.66 spid25s         executionStack
2014-05-20 07:30:09.66 spid25s          frame procname=adhoc line=1 stmtstart=68 sqlhandle=0x020000000b887a18f75d0aa07c25a9b8630fca696aa0e5d2

sql-server deadlock

— K09
nguồn

Không, bế tắc có thể xảy ra trong các tình huống khác ngoài CHỌN / CẬP NHẬT. Tất cả những gì bạn thực sự cần là hai quy trình mà mỗi quy trình cần một tài nguyên mà bên kia đang nắm giữ. (1) Các câu lệnh XÓA có phải là một phần của giao dịch lớn hơn không? (2) Bạn có thể đăng XML bế tắc ở đâu đó, thay vì văn bản nhật ký lỗi nhảm nhí không?

— Aaron Bertrand

Bạn có thể vui lòng gửi lược đồ bảng dbo.UserDetailsDatabao gồm tất cả các chỉ mục? Ngoài ra, bạn có biết nếu những câu lệnh đó được gọi với cùng tham số không? Cho rằng cả hai đều có nhật ký bằng 0 được sử dụng, tôi tự hỏi liệu tất cả những gì bạn cần làm là nối tiếp các cuộc gọi vì chúng đang giẫm đạp lên nhau.

— Jon Seigel

Làm cách nào để có được XML? Có lỗi từ nhật ký lỗi SQL Server. Báo cáo được gọi với các tham số khác nhau. Gần đây chúng tôi đã thêm một số chỉ mục được lọc lọc trên trường UserDate.

— K09

Bắt sự kiện đồ thị bế tắc trong Profiler. Sau đó, sau khi bạn bắt được nó, nhấp chuột phải vào hàng -> trích xuất dữ liệu sự kiện -> lưu nó dưới dạng .xdl ở đâu đó và đăng nội dung của nó (đó là xml) trên Pastebin (hoặc ở đâu đó tương tự).

— Mary

Xin chào, XML được đăng ở đây ... hy vọng điều này sẽ giúp! dl.dropboxusercontent.com/u/16953128/DeadlockTest.xdl

— K09

Những gì tôi đang tìm kiếm là lý do tại sao tôi nhận được một bế tắc XÓA / XÓA.

Nó xuất hiện bế tắc xảy ra bởi vì:

spid 54 ecid 0có được một khóa cập nhật ( U) khóa trênPAGE: 12:1:5147422
spid 166 ecid 3yêu cầu Ukhóa trang update ( ) trên cùng một trang và bị chặn
spid 54 ecid 2yêu cầu Ukhóa trang cập nhật ( ) trên cùng một trang ...

Các trang đang được tìm nạp trước cho truy vấn, với các khóa cập nhật có được bởi ecid 0. Đó là bước 1 ở trên. Trong bước 3, một luồng con của cùng một truy vấn song song ( ecid 2) yêu cầu cùng một khóa. Thông thường điều này sẽ không phải là một vấn đề. SQL Server biết ecid 0và ecid 2là các luồng của cùng một tiến trình cha. Thật không may, bước 2 cản trở điều này và kết quả là bế tắc.

Điều đó nói rằng, bạn không thực sự quan tâm nhiều về lý do tại sao bế tắc xảy ra, câu hỏi quan trọng là làm thế nào để bạn tránh nó. Câu trả lời là cung cấp một đường dẫn truy cập hiệu quả cho DELETE. Câu lệnh cần tìm các hàng WHERE Username = @P1 AND UserDate = @P2, vì vậy bạn nên có một chỉ mục được khóa trên các cột này.

Và tất nhiên bạn có một chỉ số như vậy. Câu hỏi thực sự là tại sao các vấn đề của bạn bắt đầu xảy ra sau khi bạn thêm các chỉ mục được lọc.

Câu trả lời cho điều đó là thông tin cột bổ sung là cần thiết để xác định vị trí các hàng chỉ mục được lọc để xóa (và để kiểm tra các vị từ của chúng). Nếu truy vấn sử dụng kế hoạch thực hiện hẹp / mỗi hàng , công cụ thực thi không thể tìm nạp các cột bổ sung trong toán tử Xóa chỉ mục cụm, như trong kế hoạch rộng / mỗi chỉ mục.

Bạn có thể tìm thêm chi tiết về điều đó, và một ví dụ hoạt động trong bài đăng trên blog này .

Trong trường hợp này, thông tin cột cần xuất phát từ một phần của kế hoạch ở bên phải Xóa Chỉ mục cụm, và do đó quét chỉ mục cụm song song được sử dụng và bạn nhận được truy vấn chậm với tiềm năng bế tắc cao.

Câu trả lời là thực hiện một trong những điều sau đây:

Xóa các chỉ mục đã lọc
Thêm các cột chỉ mục / bao gồm / vị ngữ được lọc vào chỉ mục tên / ngày hiện có
Buộc một kế hoạch cập nhật rộng rãi (không có cách nào được hỗ trợ để làm điều này)
Chạy truy vấn trong cách ly ảnh chụp nhanh (không phải RCSI)

Lựa chọn 2 sẽ là sở thích mạnh mẽ của tôi.

Tùy chọn 4 (cảm ơn Jack Douglas) có ưu điểm là loại bỏ các bế tắc và không gây ra bất kỳ "xung đột cập nhật" nào, do tính chất rời rạc của các thay đổi, nhưng nó yêu cầu cho phép cách ly ảnh chụp nhanh ở cấp cơ sở dữ liệu, thay đổi rõ ràng mức cô lập, và sẽ không khắc phục vấn đề cơ bản : bạn vẫn sẽ kết thúc việc quét bảng song song lãng phí, trong đó tìm kiếm chỉ mục đẹp là điều bạn thực sự muốn.

— Paul Trắng 9
nguồn