Chỉ dẫn từ chi phí khai thác cao khó hiểu trong Kế hoạch truy vấn?


7

Tôi có một quy trình ETL hàng tháng quá phức tạp để giải thích ở đây, nhưng về cơ bản chúng tôi nhận được một lượng lớn dữ liệu khách hàng, tải số lượng lớn vào các bảng khác nhau, sau đó chạy một loạt các quy trình xây dựng.

Khối lượng tổng dữ liệu lớn, chúng tôi thêm 25-30m bản ghi hàng tháng vào bảng lớn nhất, có tổng số khoảng 700m bản ghi. Có các bảng hỗ trợ từ 2m-300m mỗi bản ghi. Tổng dữ liệu cho bộ này là khoảng 3,5TB.

Trong tháng này, một số quy trình đang mất nhiều thời gian hơn bình thường. Một ví dụ là một Proc hoàn thành thông thường trong 30 phút mất khoảng 40 giờ trước khi tôi giết nó (nó vẫn chưa hoàn thành).

Không phải tất cả các quy trình đều bị ảnh hưởng và một số chạy thậm chí còn nhanh hơn bình thường.

Rõ ràng nguyên nhân sâu xa nằm ngoài phạm vi của một điều tôi có thể hỏi ở đây, nhưng có một điều khiến tôi phiền muộn:

Chúng tôi có các kế hoạch truy vấn thực tế hiển thị trong hàng triệu% cho các nhà khai thác riêng lẻ.

Giống như quét chỉ mục được nhóm 791,358,704%, một phép nối hợp nhất 75,566,494%, v.v. Điều này xảy ra trong nhiều gói truy vấn và đây là các gói được lấy từ đó sys.dm_exec_query_plan.

Là những kế hoạch truy vấn này chỉ ra một số vấn đề lớn hơn?

Tôi biết một cách chắc chắn, vấn đề không nằm ngoài số liệu thống kê ngày - chúng tôi đã chạy toàn màn hình trên tất cả các bảng chính, và bảng lớn nhất và DB tôi được xây dựng lại bằng tay với kích thước trước để loại bỏ phân mảnh.

Câu trả lời:


5

JNK,

Bạn có ý nghĩa như thế này?

http://sankarreddy.com/wp-content/uploads/2011/03/CropperCapture2.jpg

Đây là một kế hoạch thực hiện ước tính được tạo ra dựa trên số liệu thống kê của các công cụ máy khách và lưu ý rằng nó KHÔNG phải là vấn đề về động cơ. Nếu bạn muốn MSFT khắc phục vấn đề này thì hãy bỏ phiếu cho mục kết nối này.

https://connect.microsoft.com/QueryServer/feedback/details/436184/huge-operator-cost-in-estimated-execut-plan

Vì bạn đã đề cập đến SQL Server 2008, tôi sẽ khuyến khích bạn xem thông tin WAIT STATS khi công việc đang được chạy. Nhìn vào lý do tại sao việc thực thi KHÔNG di chuyển dọc và tìm ra nút cổ chai.

http://bloss.technet.com/b/sqlos/archive/2008/07/18/debugging-slow-response-times-in-sql-server-2008.aspx

Ngoài ra, hãy xem thông tin sys.virtualfilestats và xem liệu có độ trễ IO đáng kể cũng như việc sử dụng bộ nhớ.

HTH

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.