Hiển thị Kế hoạch thực hiện ước tính sẽ tạo ra CXPACKET, PAGELATCH_SH và LATCH_EX [ACCESS_METHODS_DATASET_PARENT] chờ

Tôi đang chạy Microsoft SQL Server 2016 SP2-CU6 (13.0.5292.0) trên máy ảo 4 vCPU max degree of parallelismđược đặt thành 2và cost threshold for parallelismđược đặt thành 50.

Vào buổi sáng, khi cố gắng hiển thị Kế hoạch thực hiện ước tính cho truy vấn CHỌN 100 , tôi gặp phải sự chờ đợi lớn và thao tác để hiển thị kế hoạch ước tính mất vài phút, thường là trong khoảng 5 - 7 phút. Một lần nữa, đây không phải là thực thi thực tế của truy vấn, đây chỉ là quá trình để hiển thị Kế hoạch thực hiện ước tính .

sp_WhoIsActivesẽ hiển thị hoặc PAGEIOLATCH_SHchờ hoặc LATCH_EX [ACCESS_METHODS_DATASET_PARENT]chờ và khi tôi chạy tập lệnh WaitingT task.sql của Paul Randal trong quá trình hoạt động, nó hiển thị CXPACKETchờ với các luồng công nhân hiển thị PAGEIOLATCH_SHchờ:

* trường mô tả tài nguyên = exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen

Các luồng công nhân dường như sẽ đưa toàn bộ statsbảng vào bộ nhớ (vì các số trang đó cũng như các số trang tiếp theo được hiển thị từ điểm truy vấn của Paul Randal trở lại khóa cụm cho statsbảng). Khi kế hoạch quay trở lại, về cơ bản là ngay lập tức trong phần còn lại của ngày, ngay cả sau khi tôi thấy hầu hết sự statstiêu hao bảng từ bộ đệm chỉ còn lại các bản ghi khác (mà tôi cho rằng đã bị kéo do tìm kiếm các hoạt động từ các truy vấn tương tự).

Tôi sẽ mong đợi hành vi ban đầu này nếu truy vấn thực sự được thực thi với một kế hoạch sử dụng các toán tử SCAN, nhưng tại sao nó lại thực hiện điều này khi đánh giá các kế hoạch thực hiện chỉ đến một toán tử XEMK như trong kế hoạch được liên kết ở trên? Tôi có thể làm gì (ngoài việc chạy tuyên bố này trước giờ hành chính để dữ liệu của tôi được lưu trong bộ nhớ cache phù hợp) để giúp cải thiện hiệu suất ở đây? Tôi cho rằng một cặp chỉ số bao trùm sẽ có lợi, nhưng liệu chúng có thực sự đảm bảo bất kỳ thay đổi nào trong hành vi không? Tôi phải làm việc trong một số giới hạn cửa sổ lưu trữ và bảo trì ở đây và chính truy vấn được tạo từ giải pháp của nhà cung cấp, vì vậy mọi đề xuất khác (ngoài việc lập chỉ mục tốt hơn) sẽ được hoan nghênh tại thời điểm này.

Nó xuất hiện yêu cầu của bạn cho một kế hoạch thực hiện kích hoạt cập nhật thống kê. Vì bạn đề cập đến điều này xảy ra vào buổi sáng, tôi tưởng tượng có một quá trình qua đêm có nhiều sửa đổi đối với các bảng liên quan?

Do đó, SQL Server sử dụng các số liệu thống kê để tạo kế hoạch, đã đạt ngưỡng sửa đổi và thực hiện cập nhật số liệu thống kê tự động như một phần của hoạt động.

Trong XML cho kế hoạch ước tính mà bạn đã chia sẻ, tôi thấy những ngày cập nhật gần nhau này cho các số liệu thống kê từ sáng nay:

LastUpdate="2019-05-06T09:12:49.92"
LastUpdate="2019-05-06T09:12:58.3"
LastUpdate="2019-05-06T09:13:20.33"
LastUpdate="2019-05-06T09:13:09.67"
LastUpdate="2019-05-06T09:12:59.05"
LastUpdate="2019-05-06T09:12:39.56"

Nếu đây là những bảng rất lớn, bận rộn (dường như có thể dựa trên tỷ lệ phần trăm lấy mẫu), thì không quá ngạc nhiên khi các bản cập nhật thống kê đang chiếm rất nhiều mã lực.

Khi tôi thấy thời gian kế hoạch ước tính dài trong SSMS, đó là một trong những điều sau đây theo thứ tự khả năng:

1. Trình tối ưu hóa truy vấn quyết định rằng nó cần để tạo hoặc cập nhật số liệu thống kê.
2. Kích thước của gói ước tính là rất lớn (giả sử,> 10 MB) và đơn giản là SSMS phải mất một thời gian dài để hiển thị nó.
3. Bản thân quá trình biên dịch truy vấn thực sự mất nhiều thời gian do sử dụng CPU để tìm kiếm một kế hoạch đủ tốt.
4. Các máy chủ đang trong tình trạng cực kỳ khó khăn. Ví dụ, tôi có thể phải đợi một cổng có sẵn.
5. Các lỗi khác nhau dẫn đến thời gian biên dịch chạy rất dài.

Đối với tình huống của bạn, câu trả lời gần như chắc chắn là SQL Server đang cập nhật hoặc tạo số liệu thống kê. Có một vài manh mối: kích thước của kế hoạch truy vấn nhỏ, kế hoạch truy vấn tương đối đơn giản với chi phí thấp và CPU biên dịch thấp hơn đáng kể so với thời gian biên dịch:

Người đóng góp mới Josh Darnell cũng chỉ ra một manh mối tốt với thời gian cập nhật cuối cùng cho các số liệu thống kê trong XML.

SQL Server 2019 giới thiệu một loại chờ mới, WAIT_ON_SYNC_STATISTICS_REFRESH , khi các truy vấn đang chờ trên các cập nhật thống kê. Việc chẩn đoán vấn đề này trên phiên bản đó dễ dàng hơn nhiều. Cho đến lúc đó bạn sẽ chỉ phải dựa vào các kỹ thuật gián tiếp.

Giải pháp thay thế bao gồm cập nhật số liệu thống kê trong thời gian bảo trì hoặc bật Tự động cập nhật thống kê không đồng bộ cho cơ sở dữ liệu. Hãy hiểu sự phân nhánh đầy đủ của tùy chọn đó trước khi thay đổi nó. Các kế hoạch truy vấn sẽ được tạo trước khi thống kê được cập nhật thay vì sau khi cập nhật thống kê. Đối với một số khối lượng công việc có thể là một chiến thắng lớn. Đối với những người khác, nó có thể làm hại nhiều hơn tốt.