Hiệu suất chậm của Dịch vụ báo cáo, rất nhanh trong QueryAnalyser

Question

Chúng tôi đang sử dụng SQL Server 2005 với Dịch vụ báo cáo.

Chúng tôi có một số báo cáo, mỗi báo cáo có chứa một truy vấn SQL tương đối đơn giản - bởi "tương đối", tôi có nghĩa là chúng tôi có một vài tham gia, nhưng không có gì tệ hơn. Chúng tôi không gọi bất kỳ thủ tục được lưu trữ trong các truy vấn của chúng tôi - đây không phải là trường hợp đánh hơi thông số.

Khi thực hiện một trong các báo cáo này (hãy gọi báo cáo A) thông qua Dịch vụ báo cáo, phải mất rất nhiều thời gian để hoàn thành - theo thứ tự hàng chục phút hoặc thậm chí hàng giờ. Khi thực hiện truy vấn SQL tương ứng trong Query Analyzer, nó sẽ hoàn thành sau vài giây.

Số hàng được trả về từ cơ sở dữ liệu có thể bằng 1 - chưa, báo cáo không bao giờ hoàn thành.

Các báo cáo khác đang hoạt động tốt.

Tìm trong bảng ExecutionLog trên Dịch vụ báo cáo, tôi có thể thấy hầu hết thời gian là trong TimeDataRetrieval (và chúng ta đang nói hàng triệu giây ở đây ...) - những lần báo cáo thực sự hoàn thành. Nếu báo cáo được hủy bỏ theo cách thủ công, thì TimeDataRetrieveal là 0 và TimeProcessing là vô lý cao thay thế.

Tôi đã xem nhật ký của Reporting Services, nhưng mọi thứ đều bình thường.

Bây giờ, trước khi bạn bắt đầu đề xuất "khóa" - tốt, các truy vấn của chúng tôi đã bật gợi ý nolock.

Vì nó là viết tắt, tôi đã đạt đến giới hạn của trí tưởng tượng của tôi cố gắng tìm ra lỗi. Bất kỳ suy nghĩ, những hiểu biết sẽ được vui lòng đánh giá cao.

/Christoffer

Answer 1

Tôi đã kết thúc tước truy vấn, về cơ bản một tuyên bố cùng một lúc, cho đến khi tôi tìm thấy thủ phạm. Một trong các phép nối trong truy vấn đã tham gia vào một bảng đang phát triển (hàng triệu hàng), sử dụng gợi ý "with (nolock index (x))".

Xóa gợi ý chỉ mục trong Trình phân tích truy vấn đã cho tôi kết quả tương tự như trong Dịch vụ báo cáo - một truy vấn chậm rất. Đây không phải là điều đáng ngạc nhiên - nhưng thực sự nó dường như là truy vấn khi chạy qua RS không sử dụng gợi ý.

Sau đó tôi đã thử chạy lại báo cáo trong RS, sử dụng câu lệnh SET FORCEPLAN ON. Và ... nó đã hoạt động - thời gian thực hiện bây giờ là một vài giây, như nó phải thế.Như tôi đã hiểu, tùy chọn FORCEPLAN buộc SQL Server xử lý các phép nối trong thứ tự được chỉ ra, AND để xem xét bất kỳ gợi ý nào.

Có ai có bất kỳ thông tin chi tiết nào về lý do truy vấn thông qua RS sẽ bỏ qua gợi ý, khi Trình phân tích truy vấn rõ ràng tính đến nó không?

Answer 2

Khi chạy báo cáo, hãy thử bắt kế hoạch thực hiện bằng cách sử dụng SQL Profiler. Hãy xem xét nếu bạn không có bất kỳ toán tử CONVER_IMPLICIT nào ví dụ và quét bảng/chỉ mục nói chung.

http://msdn.microsoft.com/en-us/library/ms190233.aspx

Quá trình chuyển đổi ngăn chặn các chỉ số từ được sử dụng và có thể xảy ra nếu bạn vượt qua các thông số đó có loại khác nhau hơn so với các cột bạn so sánh chúng với.

Bạn có thể thử thêm OPTION (RECOMPILE) vào truy vấn báo cáo, có thể báo cáo của bạn là nạn nhân của parameter sniffing.

Kiểm tra xem truy vấn của bạn có sử dụng các chức năng do người dùng định nghĩa vô hướng hay không. Họ có thể là những kẻ giết người thực sự. Nếu bạn có chúng, bạn có thể chuyển đổi chúng thành table valued functions.

Answer 3

Cập nhật nhanh: Có vẻ như bất kỳ truy vấn nào mất hơn 30 giây để thực thi, sẽ tự động gây ra thời gian chờ trong Dịch vụ báo cáo. Trong khi SET FORCEPLAN ON giải quyết các vấn đề cho một số báo cáo, vẫn có các báo cáo sự cố sẽ hết thời gian chờ. Các truy vấn này vẫn hoạt động tốt trong Query Analyzer, mặc dù thời gian thực hiện lớn hơn 30 giây. Sau khi loại bỏ tất cả các vấn đề khác có thể xảy ra với các thiết lập time-out - tại máy chủ SQL, trong Reporting Services, rsserver.config, trong IIS - tôi thấy rằng vẫn còn một khoảng thời gian mà tôi không thể sửa đổi.

Nghi ngờ của tôi là nó phải làm với thời gian chờ mặc định của ADO.NET và Microsoft đã không cho phép sửa đổi giá trị này.

Cuối cùng, tôi đã xem xét kỹ hơn truy vấn, sắp xếp lại nó theo khả năng tốt nhất của tôi và quản lý để bỏ vài giây từ thời gian thực hiện. Bây giờ, cuối cùng, các báo cáo đang chạy như họ cần.

Thời gian chờ không thể sửa đổi này khiến tôi lo lắng, tuy nhiên - điều gì sẽ xảy ra nếu máy chủ SQL có tải cao hơn bình thường khi truy vấn được thực thi?

Answer 4

Tôi đã gặp phải tình huống tương tự.

Trong phòng quản lý kết quả đến sau hai mươi giây nhưng khi tôi chạy báo cáo trong phòng thu trực quan, nó đã khóa hệ thống.

Trong SQL Profiler tôi đã bắt nguồn từ các truy vấn và nhận ra rằng nó biến đổi truy vấn của tôi là:

exec sp_executesql N' 
       .................... 
       ....................' 
, @dateparameter1 = '2010-06-01 00:00:00' 
, @datepamareter2 = '2010-06-02 00:00:00' 
, @stringparameter=null 

Tôi đã kiểm tra kế hoạch thực hiện và nhận ra rằng tôi là một nạn nhân của tham số sniffing.

tôi đã tổ chức lại truy vấn của tôi vì nó đã nói here, và nó hoạt động tốt bây giờ ..

Answer 5

Nó xảy ra với tôi cũng vậy, đó là tham số sniffing. Tôi đã sử dụng cùng một chế độ xem báo cáo để sử dụng làm bộ lọc, chỉ cần sử dụng các trường mà tôi muốn.

Điều tôi đã làm là tạo chế độ xem cho bộ lọc và nó đã được giải quyết.