Cách theo dõi chặn xảy ra trong chưa đầy một giây - Máy chủ SQL

Tôi đang cố gắng khắc phục sự cố chặn xảy ra trong chưa đầy một giây. Ứng dụng OLTP rất nhạy cảm và phải có thời gian phản hồi dưới 200ms cho một số giao dịch theo SLA đã thỏa thuận. Chúng tôi đã có một số vấn đề leo thang khóa với bản phát hành mã mới mà chúng tôi có thể giải quyết bằng cách giảm kích thước lô trong các bản cập nhật. Ngay cả với kích thước lô nhỏ, chúng tôi nghi ngờ rằng sp mới đang chặn các hàng tương tự mà các giao dịch OLTP đang cập nhật.

Tôi cần tìm phiên đang bị chặn và tài nguyên đang chờ. Theo hiểu biết của tôi, "ngưỡng quá trình bị chặn" có thể được đặt tối thiểu là 1 giây và do đó, điều này sẽ không nắm bắt được việc chặn.

Tôi đang thử nghiệm với các sự kiện Wait_info và Wait_completed x.

Có cách nào khác để chúng tôi có thể theo dõi điều này. Cảm ơn

Vì bạn đặc biệt quan tâm đến việc khóa hơn là chờ đợi chung, locks_lock_waitssự kiện mở rộng nghe có vẻ phù hợp hơn.

Với bộ lọc trên increment >= 200

CREATE EVENT SESSION [locks_lock_waits] ON SERVER 
ADD EVENT sqlserver.locks_lock_waits(
        ACTION(sqlserver.sql_text)
            WHERE  ( [sqlserver].[is_system] = 0
                     AND [increment] >= 200
                     AND [counter] <= 1000 ) 
    )
ADD TARGET package0.ring_buffer;

GO

ALTER EVENT SESSION [locks_lock_waits]  
ON SERVER  STATE = start;  

Ở trên tập hợp các câu lệnh chờ trên các khóa trong khoảng thời gian ngưỡng nhưng không cung cấp tài nguyên khóa cụ thể.

Tôi chưa bao giờ sử dụng sự kiện này và không có thông tin chi tiết về việc phiên này sẽ gây ra bao nhiêu chi phí trên máy chủ sản xuất của bạn.

Tôi tìm thấy video này về chủ đề. Điều đó thực sự khuyên bạn nên lọc counterđể giảm số lượng sự kiện được thu thập và tôi đã làm như vậy ở trên.

Nó cũng đề cập đến một lệnh cũ không có giấy tờ

dbcc lock(StallReportThreshold, 200) -- 200 is threshold in ms

Cái nào (nếu cờ theo dõi 3605 được bật) loại bỏ thông tin hạn chế, chẳng hạn như bên dưới vào nhật ký lỗi của SQL Server.

Quá trình 53 đã chờ 6844 ms cho khóa S trên kết quả RID: 2: 1: 120: 2: OKWAIT

Tôi chỉ đề cập đến điều này khi thông qua vì các sự kiện mở rộng sẽ được ưu tiên rõ ràng hơn vì nó được ghi lại và mạnh mẽ hơn nhiều.

Nếu bạn quan tâm đến việc khóa, có một số sự kiện mở rộng có sẵn:

lock_acquired
lock_released
lock_escalation

Hai sự kiện đầu tiên có một durationcột trong (micro giây) mà bạn có thể lọc theo ngưỡng của mình. Họ cũng có một resource_descriptionhành động sẽ cung cấp cho bạn một số chi tiết về các tài nguyên liên quan.

Sự lock_escalationkiện này cũng có một statementhành động mà bạn có thể thêm để thu thập câu lệnh T-SQL đã kích hoạt sự leo thang khóa. Nó cũng có escalation_cause. Đây là một phiên mẫu:

CREATE EVENT SESSION [locking] ON SERVER 
ADD EVENT sqlserver.lock_acquired( SET collect_resource_description = (1) ),
ADD EVENT sqlserver.lock_escalation( SET collect_statement = (1) ),
ADD EVENT sqlserver.lock_released( SET collect_resource_description = (1) )
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO

Tôi nghi ngờ có lẽ có một lý do khiến bạn không thể đặt ngưỡng báo cáo quy trình bị chặn thành dưới một giây: khóa là hoàn toàn bình thường trong RDBMS - công cụ cơ sở dữ liệu phải khóa tài nguyên để bảo vệ chúng. Mặc dù không có một định nghĩa chính thức nào về việc khi khóa trở thành chặn, khóa đánh dấu trên giây phụ, có vẻ như là điều bình thường đối với tôi.