Vì vậy, trong SQL Server 2016, các bản cập nhật thống kê sử dụng chế độ mẫu hiện chạy song song ở mức độ tương thích 130 và đây là cách nó hoạt động theo mặc định, cho tất cả các bản cập nhật thống kê tự động và thủ công. Điều này được giải thích ngắn gọn ở đây:
- Bổ sung Trình tối ưu hoá Truy vấn trong SQL Server 2016
(Tài liệu cũng đã được cập nhật, cả chủ đề Mức độ tương thích và chủ đề THỐNG KÊ CẬP NHẬT.)
Tuy nhiên, sẽ không hay ho gì khi có thể chỉ định bao nhiêu CPU thực sự có thể được sử dụng cho các hoạt động này (ngoài việc chỉ cho phép giới hạn 16)? Tôi nghĩ rằng có thể giới hạn điều này ở 4 hoặc 8 sẽ là một điều hiển nhiên và hợp lý để ủng hộ. Đặc biệt là đối với những khách hàng đang chạy hệ thống có 16 lõi trở xuống hoặc nhiều phiên bản trên một hộp, những người không thể dựa vào các tính năng của Enterprise như Resource Governor (điều mà hầu hết các Khách hàng của Enterprise đều không thấy phiền khi sử dụng IMHO).
Lý do kinh doanh cho điều này sẽ giống như lý do được sử dụng để thêm hỗ trợ MAXDOP REBUILD, DBCC CHECKDB và nhóm hoạt động bảo trì của nó, v.v. Bạn muốn ngăn loại hoạt động này tiếp quản tất cả các lõi mà không cần làm điều gì đó quyết liệt như tắt cập nhật tự động hoặc sử dụng MAXDOP toàn phiên bản - vì không phải ai cũng có đủ điều kiện về cửa sổ bảo trì.
Và trong trường hợp này, MAXDOP toàn phiên bản sẽ không giúp ích được gì , vì SQL Server 2016 RTM có lỗi MAXDOP bị bỏ qua để cập nhật số liệu thống kê được lấy mẫu. Sắp có một bản sửa lỗi, nhưng tôi nghĩ bạn nên biết; nếu điều này gây ra cho bạn sự cố, một tùy chọn là sử dụng mức tương thích thấp hơn.
Nhưng tôi sẽ nhắc lại một điều mà tôi thường nói:Mức độ tương thích ngày càng quá đông đúc. Nếu tôi muốn số liệu thống kê được lấy mẫu song song trên cơ sở dữ liệu của mình nhưng tôi có đủ hồi quy ước tính bản số để yêu cầu CE cũ, tôi phải chọn cái này hoặc cái kia.
Và một điều khác:Resource Governor quá mức cần thiết cho trường hợp sử dụng này và việc giới hạn mức sử dụng cốt lõi từ các bản cập nhật thống kê không thực sự là một tính năng của Enterprise (giống như REBUILD và CHECKDB đã đề cập ở trên). Vui lòng không nói với tôi rằng RG là một giải pháp thay thế có thể chấp nhận được, bởi vì nó chỉ có thể đối với những người dùng có phân loại khối lượng công việc * và * phiên bản doanh nghiệp luôn bị hạn chế bởi MAXDOP mọi lúc . Tôi sẽ có thể giới hạn điều này bằng thao tác cụ thể (hoặc, giả sử, chỉ đối với các bảng lớn nhất / vấn đề của tôi), chứ không phải bằng cách hạn chế toàn bộ phiên đăng nhập.
Tôi ước họ sẽ làm như thế nào
Lý tưởng nhất là chúng ta có thể đặt điều này ở cấp cơ sở dữ liệu, sử dụng tùy chọn CẤU HÌNH CƠ SỞ DỮ LIỆU mới và ở cấp câu lệnh, sử dụng cú pháp TÙY CHỌN (MAXDOP n) quen thuộc. Mức tuyên bố sẽ giành chiến thắng và mọi cập nhật thống kê chế độ mẫu (bao gồm cả tự động) mà không có gợi ý MAXDOP rõ ràng sẽ trở lại cài đặt mức cơ sở dữ liệu. Điều này sẽ cho phép tôi đặt MAXDOP là 4, ví dụ, cho tất cả các bản cập nhật thống kê tự động xảy ra vào những thời điểm không thể đoán trước, nhưng 8 hoặc 16 cho các thao tác thủ công trong các cửa sổ bảo trì đã biết. Như một ví dụ.
Nếu bạn muốn bỏ phiếu cho điều này, vui lòng xem mục Kết nối sau đây và thêm một lý do kinh doanh cho điều này (a la Michael Campbell):
- Kết nối # 628971:Thêm thông số MAXDOP để cập nhật số liệu thống kê
Tất nhiên, mục đó đã có từ năm 2010, vì vậy không có bất kỳ đề cập nào về đại lộ CẤU HÌNH CƠ SỞ DỮ LIỆU, đó là lý do tại sao tôi cũng để lại nhận xét.
Trong thời gian chờ đợi, nếu bạn muốn tắt chế độ song song cho chế độ mẫu, có một cờ theo dõi để quay lại hành vi cũ hơn một cách hiệu quả (bạn cũng có thể thực hiện việc này bằng cách hoàn nguyên về mức tương thích nhỏ hơn 130, nhưng tôi không khuyên bạn nên làm điều này vì nó ảnh hưởng đến rất nhiều thứ khác). Tôi sẽ cập nhật không gian này khi tôi được phép tiết lộ cờ theo dõi một cách công khai, nhưng hiện tại, Microsoft đang giữ chặt nó trong lồng ngực của họ.
