Cấp bộ nhớ truy vấn và tràn tempdb

Tôi có một truy vấn chạy dài (bảng thực tế với 100 triệu hàng tham gia một số bảng mờ nhỏ sau đó được nhóm theo) đang tràn sang tempdb, mặc dù (sau khi điều chỉnh) CE rất gần với số lượng hàng thực tế, hãy xem kế hoạch :

Tìm kiếm một lời giải thích, tôi nhận thấy thông tin cấp bộ nhớ sau:

Môi trường: SQL Server 2012 SP1 Enterprise, RAM máy chủ 256 GB, bộ nhớ tối đa SQL Server 200 GB, kích thước vùng đệm 42 GB, kích thước tối đa không gian làm việc 156 GB (GrantedMemory = 156 * 25% ~ = 38 GB)

Câu hỏi

1. điều đó có nghĩa là cho dù CE tốt đến đâu, truy vấn không có cơ hội không tràn ra? vì ram tối đa truy vấn được giới hạn ở mức 38 GB
2. trình tối ưu hóa truy vấn không xem xét tối đa ram truy vấn khi xây dựng kế hoạch? (buộc tổng hợp Hash Match sẽ loại bỏ bước sắp xếp và cải thiện đáng kể hiệu năng truy vấn, thật không may, truy vấn thực tế đến từ Cognos và chúng tôi không kiểm soát được nó)
3. sẽ tăng giới hạn 25% lên gần 100% có phải là một lựa chọn hợp lý ở đây không? (giả sử rằng quyền truy cập máy chủ nói trên có thể được kiểm soát để giới hạn số lượng yêu cầu truy vấn đồng thời)

Gói truy vấn ẩn danh tại Paste The Plan

Khi buộc tổng hợp khớp băm (thay vì tổng hợp sắp xếp + luồng), truy vấn sẽ hoàn thành nhanh hơn 3 - 4 lần. Thật không may, truy vấn thực tế đến từ Cognos và chúng tôi không có cách nào để thay đổi nó.

Không có sự cố tràn băm trong kế hoạch tổng hợp băm. Trình tối ưu hóa truy vấn sẽ không chọn tổng hợp khớp băm vì nếu tôi xem chi phí vận hành cho tổng hợp băm so với tổng hợp luồng, chi phí CPU của nhóm băm cao gấp 2 - 3 lần so với tổng hợp luồng.

Trong cả tổng hợp luồng và hàm băm, các hàng đầu ra ước tính hoàn toàn giống với đầu vào (~ 100 triệu hàng).

Truy vấn sử dụng một chỉ mục cột NC duy nhất và tất cả các số liệu thống kê cột được cập nhật thường xuyên.

1. điều đó có nghĩa là cho dù CE tốt đến đâu, truy vấn không có cơ hội không tràn ra? vì ram tối đa truy vấn được giới hạn ở mức 38 GB

Cấp bộ nhớ tổng thể cho truy vấn của bạn xuất hiện giới hạn ở mức 37 GB với cấu hình máy chủ và phần cứng hiện tại của bạn.

Nếu Sắp xếp không thể được thực hiện trong Phân số bộ nhớ (0.860743 trong gói đó) của cấp bộ nhớ truy vấn, nó sẽ tràn sang tempdb . Cũng lưu ý rằng Sắp xếp song song này phân chia phần của bộ nhớ truy vấn cấp bằng nhau trên 12 luồng và phân bổ này có thể được cân bằng lại khi chạy.

2. trình tối ưu hóa truy vấn không xem xét tối đa ram truy vấn khi xây dựng kế hoạch? (buộc tổng hợp Hash Match sẽ loại bỏ bước sắp xếp và cải thiện đáng kể hiệu năng truy vấn, thật không may, truy vấn thực tế đến từ Cognos và chúng tôi không kiểm soát được nó)

Có, nó có, nhưng chỉ là một đầu vào cho khung chi phí chung. Trình tối ưu hóa chọn gói có vẻ rẻ nhất theo mô hình của nó. Nếu các con số sai, lựa chọn kế hoạch không có khả năng là tối ưu.

Trong trường hợp của bạn, số lượng hàng thực tế được tạo bởi Tập hợp luồng ít hơn đáng kể so với ước tính:

Trình tối ưu hóa ủng hộ Hash Aggregate khi có ít hơn, các nhóm lớn hơn được mong đợi (vì mỗi nhóm chiếm một vị trí trong bảng băm). Thông tin sai lệch về mật độ dẫn đến sự lựa chọn không chính xác của Sắp xếp + Luồng tổng hợp.

Kế hoạch tốt nhất có thể sẽ là tham gia băm thay vì tham gia các vòng lặp lồng nhau và tổng hợp băm. Điều này sẽ có thể mở rộng xử lý chế độ hàng loạt đến bước tổng hợp quan trọng.

SQL Server 2012 khá hạn chế trong việc chuyển đổi giữa chế độ hàng và chế độ hàng loạt. Công cụ thực thi không bao giờ quay lại chế độ hàng loạt khi quá trình xử lý chế độ hàng đã bắt đầu (vì vậy hàng-lô-hàng là ok, nhưng lô hàng-lô thì không).

3. sẽ tăng giới hạn 25% lên gần 100% có phải là một lựa chọn hợp lý ở đây không? (giả sử rằng quyền truy cập máy chủ nói trên có thể được kiểm soát để giới hạn số lượng yêu cầu truy vấn đồng thời)

Nếu bạn muốn tăng dung lượng bộ nhớ khả dụng cho truy vấn này, bạn chắc chắn có thể làm như vậy bằng cách thay đổi thiết lập Governor Governor. Tăng giới hạn theo độ để xem bạn có thể xác định vị trí thỏa hiệp tốt hay không. Tôi sẽ cảnh giác khi đi quá gần 100%.

Nếu truy vấn phù hợp với hướng dẫn kế hoạch, hãy thử một HASH GROUPgợi ý.

Về lâu dài, việc nâng cấp lên SQL Server 2016 sẽ trả cổ tức vì nhiều nhà khai thác có thể thực thi trong chế độ hàng loạt (bao gồm Sắp xếp), có thể tăng cấp bộ nhớ động và ... nói chung về hàng ngàn cải tiến khác trong xử lý chế độ cột / lô.

Tôi có thể trả lời một phần câu hỏi của bạn.

1) Tôi không chắc chắn rằng tôi hiểu chính xác câu hỏi của bạn. Không đúng khi máy chủ SQL sẽ chỉ tràn sang tempdb vì ước tính số lượng thẻ là sai. Đôi khi SQL Server hy vọng rằng một kế hoạch đủ tốt sẽ tràn sang tempdb.

2) Trình tối ưu hóa truy vấn sẽ đưa bộ nhớ vào máy chủ vào tài khoản khi xây dựng kế hoạch. Một bài tập hữu ích có thể là thay đổi lượng bộ nhớ khả dụng cho truy vấn của bạn để xem kế hoạch truy vấn thay đổi như thế nào. Bạn có thể làm điều đó bằng cách thay đổi cài đặt bộ nhớ trên máy chủ, sử dụng bộ điều chỉnh tài nguyên hoặc lệnh không có giấy tờ DBCC OPTIMIZER WHAT_IF () . WHAT_IF rất hữu ích nếu bạn muốn xem kế hoạch truy vấn trông như thế nào với nhiều bộ nhớ hơn 200 GB.

Như bạn đã chỉ ra, trình tối ưu hóa truy vấn không sử dụng tổng hợp khớp băm vì nó nghĩ rằng chi phí CPU của toán tử đó sẽ cao hơn nhiều so với sắp xếp. Một trong những tiêu chí làm cho tổng hợp khớp băm hấp dẫn với trình tối ưu hóa là khi SQL Server ước tính sẽ không có nhiều hàng khác nhau được trả về. Đối với truy vấn của bạn, SQL Server nghĩ rằng nó sẽ không loại bỏ bất kỳ hàng nào với GROUP BY.

Chi phí ước tính cho các kế hoạch gần đến mức nào và chúng thay đổi như thế nào khi bạn thay đổi bộ nhớ có sẵn cho truy vấn?

3) Tôi không biết, nhưng đó chắc chắn là điều mà bạn nên kiểm tra cẩn thận. Các tùy chọn an toàn hơn sẽ là tăng ram tối đa của SQL Server (200 có vẻ hơi thấp nhưng có thể có các ứng dụng khác được cài đặt trên máy chủ hoặc điều này nằm ngoài tầm kiểm soát của bạn) hoặc để cải thiện hiệu suất tempdb. Tôi có thể nghĩ ra một vài ý tưởng khác để cải thiện hiệu suất nhưng tất cả chúng đều là những bức ảnh dài.

Hãy thử chạy một truy vấn đơn giản hơn, chỉ thực hiện NHÓM THEO trên bảng thực tế. Có cách nào để có được ước tính tốt hơn cho số lượng giá trị khác biệt không? Có thể tạo số liệu thống kê nhiều cột giúp?

Nếu bạn không thể thay đổi truy vấn, bạn có thể thử thay thế bảng được tham chiếu bằng chế độ xem chọn dữ liệu bạn cần nhưng theo cách thay đổi kế hoạch. Điều này có thể giúp ích trong một số trường hợp nhưng tôi không thể nghĩ ra cách nào để áp dụng kỹ thuật ở đây.

Có vẻ như bạn có khá nhiều quyền kiểm soát máy chủ này vì vậy bạn có thể thử tạo một hướng dẫn kế hoạch . Tôi chưa bao giờ làm điều này và chưa bao giờ nghe ai nói bất cứ điều gì tích cực về hướng dẫn kế hoạch.