Tôi có một báo cáo SSRS tải chậm, có lẽ từ lỗi khóa. Đây là những gì tôi biết.Báo cáo SSRS mất nhiều thời gian hơn truy vấn; cố gắng tham số sniffing & nolock sửa chữa
Nếu tôi đặt truy vấn đưa báo cáo vào cửa sổ truy vấn Quản lý Studio, sẽ mất khoảng 50 mili giây để chạy.
Khi chạy các tiêu chuẩn báo cáo tôi đã thử nghiệm từ giao diện trình duyệt, các giá trị thời gian từ ReportServer..ExecutionLog (WHERE Tình trạng = 'rsSuccess' VÀ ReportID = [thereport]) dao động như sau:
TimeDataRetrieval: 95000-120000
TimeProcessing: 35000-50000
TimeRendering: 75-125
Bởi vì tôi không biết một cách tốt hơn để làm điều đó, tôi theo dõi sys.dm_exec_requests như tôi chạy báo cáo một vài lần và truy vấn này có vẻ là gác máy:
CREATE PROCEDURE [dbo].[CheckSessionLock]
@SessionID as varchar(32) AS
DECLARE @Selected nvarchar(32)
SELECT @Selected=SessionID
FROM [ReportServerTempDB].dbo.SessionLock
WITH (ROWLOCK) WHERE SessionID = @SessionID
dường như lệnh này mất khoảng thời gian tương tự như TimeDataRetrieval + TimeProcessin g giá trị ở trên, vì vậy tôi tin rằng đó là thủ phạm. Tôi cũng bắt gặp nó làm một tạo ra tương tự của CleanOrphanedSnapshots, vì vậy tôi tưởng tượng đây là một phần hoạt động SSRS bình thường. Cho đến nay tôi đã không có bất kỳ may mắn tìm các cài đặt cấu hình có liên quan trong trình tạo báo cáo hoặc chính mã đó.
Các giải pháp được đề xuất mà tôi đã tìm thấy trực tuyến phải thực hiện với "tham số đánh hơi" và WITH (nolock). Các cựu dường như chỉ trong bối cảnh gọi một thủ tục được lưu trữ, mà điều này không làm. Tôi tạo ra một SP để xem liệu việc xử lý các thông số preempting sẽ thay đổi kết quả và nó có vẻ giống nhau hay không. Tôi đã thêm các gợi ý WITH (nolock) cũng như thiết lập sự cô lập để đọc uncommitted không có may mắn.
Tôi chắc chắn rằng tôi thiếu thứ gì đó đơn giản. Đây là hy vọng ai đó biết nó là gì. Cảm ơn bạn đã giúp đỡ.
Parameter sniffing - Fast query runs slow in SSRS NOLOCK cách tiếp cận - SSRS is locking table
Điều này chỉ xảy ra với báo cáo này hoặc tất cả các báo cáo của bạn? – GayanSanjeewa
Ah ha! Cảm ơn, GayanSanjeewa. Điều đó giúp tôi thấy những gì tôi đã mất tích. Không có báo cáo nào khác có cùng vấn đề và trên thực tế, một báo cáo khác có truy vấn chính giống nhau trong đó. Điều đó làm tôi nhận ra rằng tôi đã bỏ qua hai subreports trong báo cáo vấn đề. Nếu tôi đang đọc quyền này, mỗi người đang chạy cho mỗi bản ghi trong báo cáo chính quay trở lại (và bản thân họ không hiệu quả). Tôi đoán tôi sẽ phải thiết kế lại báo cáo với truy vấn lõi tốt hơn hoặc xem liệu tôi có thể tinh chỉnh truy vấn phụ để hoạt động hiệu quả hay không. Cảm ơn một lần nữa! – tetch
CẬP NHẬT: Có Tôi đã có hai chế độ xem abhorrent mà tôi đã tối ưu hóa (hoặc ít nhất là được cải thiện) và đã nhận được thời gian báo cáo xuống từ 2-3 phút xuống còn 20-25 giây. Các CheckSessionLock vẫn xảy ra, vì vậy tôi đoán đó là cách SSRS hoạt động. – tetch