SQL Server: nên làm gì khi một tiến trình đang chặn tiến trình khác?

7

Tôi là một DBA tình cờ và vẫn đang học.

Khi tôi thấy từ DMV: s hoặc Activity Monitor rằng một số quy trình đang chặn một quy trình khác, cần phải làm gì?

Tôi có nên đơn giản giết chết các quá trình đó hay có cách nào để "giải phóng" hoặc có thể ưu tiên ngăn chặn sự ngăn chặn này?

sql-server locking

— jrara
nguồn

5

GIẾT CHẾT

Đôi khi, siêu bạo lực là câu trả lời

Dù sao, một khối chỉ là một khóa diễn ra quá lâu. "Quá dài" là tất nhiên. nếu bạn thấy việc chặn thông qua các quy trình hệ thống hoặc DMV thì hầu như luôn luôn là "quá dài" vì các khối nên thoáng qua và rất ngắn

Nếu bạn có chặn có thể đo lường được, thì bạn cần điều tra lý do tại sao ví dụ: giao dịch chạy dài

— gbn
nguồn

2

Câu trả lời rất cao.

— Nick Chammas

Cảm ơn, khi chặn bị giết, giao dịch có được khôi phục (như chưa từng xảy ra) và dữ liệu (ví dụ: câu lệnh INSERT bị chặn) sẽ không được ghi vào cơ sở dữ liệu?

— jrara

@jrara: có và có

— gbn

7

Mặc dù câu hỏi này đã được trả lời và câu trả lời được chấp nhận, tôi sẽ cố gắng đưa ra một trường hợp cho cách tiếp cận ngược lại ...

ĐỪNG BAO GIỜ BLINDLY GIẾT MỘT SPID

Trừ khi bạn biết SPID đã làm những gì, bạn không hiểu gì về quy mô của việc khôi phục mà bạn sắp bắt đầu.

Loại chuỗi chặn tồi tệ nhất là những chuỗi bất ngờ khiến hệ thống 24/7 của bạn phải quỳ xuống. 99% thời gian, truy vấn ở đầu chuỗi chặn đó sẽ là một truy vấn chọn cũ đơn giản trở nên tồi tệ, xếp hàng bất kỳ và tất cả hoạt động ghi đằng sau nó. Trong những trường hợp này, một KILL sẽ tiết kiệm trong ngày.

1% thời gian còn lại, truy vấn giả mạo đó sẽ là bước cuối cùng trong một giao dịch dài hạn sẽ mất nhiều thời gian để quay trở lại như lúc này để đến giai đoạn hiện tại. Dành một chút thời gian để hiểu làm thế nào bạn có được ở đây sẽ 99% thời gian là không cần thiết. 1% thời gian, bạn có thể tiết kiệm phút / giờ / ngày thời gian chết.

— Mark Storey-Smith
nguồn

1

+1. Đó là một điểm tốt để xác định quá trình để giết do vấn đề rollback.

— StanleyJohns

Một txn chạy dài thường không phải là một cái lớn: nó có thể được gây ra bởi một sự kiện ra lệnh của máy khách. Và bạn vẫn phải tiêu diệt SPID và nó vẫn cần phải quay lại trong mọi trường hợp.

— gbn

Bạn vẫn cần phải GIẾT nó trừ khi bạn có thể giải phóng khối, nói bằng một cam kết. Nếu bạn không thể, bạn không có nhiều lựa chọn: trừ khi bạn muốn dừng SQL Server, xóa MDF / LDF, khởi động lại SQL Server, khôi phục cơ sở dữ liệu.

— gbn

1

Tôi không đồng ý @gbn. Nếu quá trình ở đầu chuỗi chặn gần hoàn thành, tại sao lại giết nó và buộc quay lại? Quan điểm của tôi là thay vì chỉ giết nó, đáng để dành một chút thời gian để đánh giá liệu nó sắp hoàn thành và do đó giải phóng các khóa chặn của nó. Có thể giết là lựa chọn tốt nhất nhưng nó không phải là phản ứng mặc định.

— Mark Storey-Smith

4

Chặn, trong và của chính nó, không phải là xấu .

Vấn đề xảy ra khi bạn gặp vấn đề về hiệu suất từ các giao dịch dài hạn đang chặn các giao dịch khác.

Trong trường hợp này, điều tôi sẽ làm là cố gắng xác định bất kỳ truy vấn / giao dịch dài hạn nào và cố gắng khắc phục những vấn đề đó.

Nếu bạn đang gặp vấn đề về hiệu suất, hãy cố gắng khắc phục nguyên nhân gốc chứ không phải là triệu chứng.

Đã nói rằng, nếu bạn gặp vấn đề trong sản xuất và bạn thực sự cần phải ngăn chặn nó, hãy sử dụng thói quen KILL. (như gbn đã đề cập).

— Richard
nguồn

1

Khóa là bình thường. Nó xảy ra tất cả các thời gian với xung đột. Đó là sự bế tắc liên tục là một vấn đề, vì công cụ cơ sở dữ liệu chọn một quy trình nạn nhân để giết và phục hồi giao dịch. Thống kê chứng minh rằng điều này chắc chắn sẽ xảy ra, nhưng nếu nó xảy ra liên tục thì bạn cần đi sâu vào nguyên nhân và viết lại các truy vấn và logic mã.

— Thomas Stringer
nguồn