Tại sao tôi KHÔNG sử dụng tùy chọn SQL Server Tối ưu hóa cho khối lượng công việc ad hoc hoc?


49

Tôi đã đọc một số bài viết tuyệt vời về bộ nhớ đệm kế hoạch SQL Server của Kimberly Tripp, chẳng hạn như bài này: http://www.sqlskills.com/bloss/kimberly/plan-cache-and-optimizing-for-adhoc-workloads/

Tại sao thậm chí còn có một tùy chọn để "tối ưu hóa cho khối lượng công việc ad hoc"? Không phải lúc nào cũng nên bật? Cho dù các nhà phát triển có sử dụng SQL ad-hoc hay không, tại sao bạn không bật tùy chọn này trên mọi phiên bản hỗ trợ nó (SQL 2008+), do đó làm giảm sự phình to bộ đệm?

Câu trả lời:


45

Nhóm phát triển SQL Server hoạt động theo nguyên tắc ít gây bất ngờ nhất - vì vậy, SQL Server thường có các tính năng mới bị vô hiệu hóa vì lợi ích của việc duy trì hành vi như các phiên bản trước.

Có, tối ưu hóa cho khối lượng công việc adhoc là rất tốt trong việc giảm sự phình to bộ nhớ cache của kế hoạch - nhưng luôn luôn kiểm tra nó trước!

[Chỉnh sửa: Kalen Delaney kể một giai thoại thú vị rằng cô đã hỏi một trong những người bạn kỹ sư Microsoft của mình rằng liệu sẽ có trường hợp nào không phù hợp để kích hoạt điều này. Anh ta quay lại vài ngày sau đó để nói - hãy tưởng tượng một ứng dụng có RẤT NHIỀU truy vấn khác nhau và mỗi truy vấn chạy chính xác hai lần. Sau đó, nó có thể không phù hợp. Đủ để nói rằng không có nhiều ứng dụng như vậy!]

[Chỉnh sửa: Nếu phần lớn các truy vấn của bạn được thực hiện nhiều lần (không chính xác hai lần); nó có thể không phù hợp Nguyên tắc chung sẽ là biến nó nếu có nhiều truy vấn adhoc sử dụng một lần trên cơ sở dữ liệu; tuy nhiên, vẫn không có nhiều ứng dụng như vậy.]


9
+1 tính năng mới rất, rất hiếm khi được bật theo mặc định. Tôi thực sự không thể nghĩ ra bất kỳ lý do chính đáng nào để không bật tính năng cụ thể này - trong trường hợp xấu nhất, tất cả các truy vấn của bạn đều sử dụng một lần và dù sao cũng sẽ không được hưởng lợi từ bộ nhớ đệm.
Aaron Bertrand

1
Đây là câu trả lời "an toàn" dựa trên lẽ thường và không giải quyết được câu hỏi. Người hỏi muốn biết cụ thể trường hợp sử dụng khi KHÔNG bật tính năng này thì tốt hơn.
MikeTeeVee

2
MikeTeeVee - nó có thể là một câu trả lời an toàn, nhưng đây là một trong những tính năng mà tôi thực sự không thể nghĩ ra lý do không kích hoạt nó. Vì nó rất tuyệt vời, tôi chỉ muốn giải thích tại sao nó bị tắt theo mặc định!
Peter Schofield

21

Dưới đây là một mã nhỏ sẽ giúp bạn quyết định xem "chuyển đổi tối ưu hóa cho khối lượng công việc ad hoc ON / OFF" có mang lại lợi ích hay không. Chúng tôi thường kiểm tra điều này như là một phần của kiểm tra sức khỏe của chúng tôi đối với các máy chủ nội bộ và máy khách.

Đây là tùy chọn an toàn nhất để kích hoạt và được Brad mô tả tốt ở đây và bởi Glenn Berry tại đây .

--- for 2008 and up .. Optimize ad-hoc for workload 
IF EXISTS (
        -- this is for 2008 and up
        SELECT 1
        FROM sys.configurations
        WHERE NAME = 'optimize for ad hoc workloads'
        )
BEGIN
    DECLARE @AdHocSizeInMB DECIMAL(14, 2)
        ,@TotalSizeInMB DECIMAL(14, 2)
        ,@ObjType NVARCHAR(34)

    SELECT @AdHocSizeInMB = SUM(CAST((
                    CASE 
                        WHEN usecounts = 1
                            AND LOWER(objtype) = 'adhoc'
                            THEN size_in_bytes
                        ELSE 0
                        END
                    ) AS DECIMAL(14, 2))) / 1048576
        ,@TotalSizeInMB = SUM(CAST(size_in_bytes AS DECIMAL(14, 2))) / 1048576
    FROM sys.dm_exec_cached_plans

    SELECT 'SQL Server Configuration' AS GROUP_TYPE
        ,' Total cache plan size (MB): ' + cast(@TotalSizeInMB AS VARCHAR(max)) + '. Current memory occupied by adhoc plans only used once (MB):' + cast(@AdHocSizeInMB AS VARCHAR(max)) + '.  Percentage of total cache plan occupied by adhoc plans only used once :' + cast(CAST((@AdHocSizeInMB / @TotalSizeInMB) * 100 AS DECIMAL(14, 2)) AS VARCHAR(max)) + '%' + ' ' AS COMMENTS
        ,' ' + CASE 
            WHEN @AdHocSizeInMB > 200
                OR ((@AdHocSizeInMB / @TotalSizeInMB) * 100) > 25 -- 200MB or > 25%
                THEN 'Switch on Optimize for ad hoc workloads as it will make a significant difference. Ref: http://sqlserverperformance.idera.com/memory/optimize-ad-hoc-workloads-option-sql-server-2008/. http://www.sqlskills.com/blogs/kimberly/post/procedure-cache-and-optimizing-for-adhoc-workloads.aspx'
            ELSE 'Setting Optimize for ad hoc workloads will make little difference !!'
            END + ' ' AS RECOMMENDATIONS
END

7

Hãy nghĩ về một máy chủ sản xuất chỉ phục vụ 5 truy vấn khác nhau, nhưng vài nghìn truy vấn mỗi giây. Bạn là nhóm phát triển Microsoft SQL Server. Bạn sẽ mân mê với bộ nhớ đệm kế hoạch. Bạn có bật hành vi này theo mặc định không, khi bạn biết rằng một số khách hàng lớn nhất và quan trọng nhất của bạn (ví dụ: triển khai SAP nội bộ của Microsoft) hoạt động trong cùng một khuôn viên và sử dụng cùng một quán ăn bạn làm?


Bình luận không dành cho thảo luận mở rộng; cuộc trò chuyện này đã được chuyển sang trò chuyện .
Paul White

7

Khi bạn bật tùy chọn " Tối ưu hóa cho khối lượng công việc học tập quảng cáo ", bạn sẽ khiến các truy vấn đặc biệt chạy lần thứ 2 chậm như lần 1, vì bạn sẽ Biên dịch Kế hoạch thực hiện và lấy cùng một Dữ liệu ( không có bộ nhớ cache) 2 lần đầu tiên.
Đây có thể không phải là một vấn đề lớn, nhưng bạn sẽ nhận thấy nó khi kiểm tra các truy vấn.
Vì vậy, điều gì xảy ra bây giờ, không có tùy chọn này được bật và bộ đệm chứa đầy các truy vấn Ad-Hoc 1-Off?

Thuật toán quản lý bộ đệm:

Khi tính năng Tối ưu hóa này được giới thiệu, thuật toán quản lý bộ đệm cũng được cập nhật.
Bài báo của Kimberly Tripp cũng tham khảo bài đăng của Kalen Delaney về sự thay đổi thuật toán này.
Cô giải thích nó tốt nhất:

Sự thay đổi thực sự tính toán kích thước bộ đệm của kế hoạch mà tại đó SQL Server nhận ra rằng có áp lực bộ nhớ và nó sẽ bắt đầu loại bỏ các gói khỏi bộ đệm. Các kế hoạch được loại bỏ là các kế hoạch giá rẻ chưa được sử dụng lại, và đây là một điều TỐT.

Điều này có nghĩa là những kế hoạch một thời gian phiền phức này sẽ là kế hoạch đầu tiên khi bạn cần giải phóng tài nguyên.

Vì vậy, bây giờ câu hỏi trở thành:

    " Tại sao chúng tôi CẦN 'Tối ưu hóa cho khối lượng công việc của Ad Hoc' khi SQL Server xử lý loại bỏ các kế hoạch không sử dụng khi cần thiết? "

Câu trả lời của tôi là, nếu bạn thường xuyên có một loạt quảng cáo không được tạo tham số động -hoc truy vấn, sau đó nó có ý nghĩa hoàn hảo để bật tính năng này.
Bạn muốn tránh gây căng thẳng cho tài nguyên hệ thống, để nó buộc loại bỏ dữ liệu được lưu trong bộ nhớ cache sau khi bạn sử dụng hết dung lượng bộ nhớ cache tối đa.

Làm thế nào để tôi biết khi nào tôi cần bật cái này?

Đây là một truy vấn tôi đã viết để cho bạn biết có bao nhiêu Gói Ad-Hoc mà bạn hiện đã lưu trong bộ nhớ cache và dung lượng đĩa trống mà chúng đang ăn (kết quả sẽ thay đổi trong suốt cả ngày - vì vậy hãy kiểm tra nó trong thời gian tải nặng):

--Great query for making the argument to use "Optimize for Ad Hoc Workloads":
SELECT S.CacheType, S.Avg_Use, S.Avg_Multi_Use,
       S.Total_Plan_3orMore_Use, S.Total_Plan_2_Use, S.Total_Plan_1_Use, S.Total_Plan,
       CAST( (S.Total_Plan_1_Use * 1.0 / S.Total_Plan) as Decimal(18,2) )[Pct_Plan_1_Use],
       S.Total_MB_1_Use,   S.Total_MB,
       CAST( (S.Total_MB_1_Use   * 1.0 / S.Total_MB  ) as Decimal(18,2) )[Pct_MB_1_Use]
  FROM
  (
    SELECT CP.objtype[CacheType],
           COUNT(*)[Total_Plan],
           SUM(CASE WHEN CP.usecounts > 2 THEN 1 ELSE 0 END)[Total_Plan_3orMore_Use],
           SUM(CASE WHEN CP.usecounts = 2 THEN 1 ELSE 0 END)[Total_Plan_2_Use],
           SUM(CASE WHEN CP.usecounts = 1 THEN 1 ELSE 0 END)[Total_Plan_1_Use],
           CAST((SUM(CP.size_in_bytes * 1.0) / 1024 / 1024) as Decimal(12,2) )[Total_MB],
           CAST((SUM(CASE WHEN CP.usecounts = 1 THEN (CP.size_in_bytes * 1.0) ELSE 0 END)
                      / 1024 / 1024) as Decimal(18,2) )[Total_MB_1_Use],
           CAST(AVG(CP.usecounts * 1.0) as Decimal(12,2))[Avg_Use],
           CAST(AVG(CASE WHEN CP.usecounts > 1 THEN (CP.usecounts * 1.0)
                         ELSE NULL END) as Decimal(12,2))[Avg_Multi_Use]
      FROM sys.dm_exec_cached_plans as CP
     GROUP BY CP.objtype
  ) AS S
 ORDER BY S.CacheType

Các kết quả: nhập mô tả hình ảnh ở đây

Tôi sẽ không nói, " Khi bạn có X MB " hoặc " Nếu X% Quảng cáo Học của bạn là Sử dụng một lần " để bật tính năng này.
Nó không ảnh hưởng đến Sprocs, Triggers, Lượt xem hoặc SQL được tham số hóa / Chuẩn bị - chỉ các truy vấn Ad-Hoc.
Đề nghị cá nhân của tôi là chỉ bật trong Môi trường Prod của bạn, nhưng xem xét tắt nó trong Môi trường Dev của bạn.
Tôi nói điều này chỉ dành cho Dev, bởi vì nếu bạn tối ưu hóa một truy vấn mất một phút hoặc hơn để chạy, thì bạn không muốn chạy nó 3 lần trước khi bạn có thể thấy nó sẽ chạy nhanh như thế nào với nó được lưu trong bộ nhớ cache - mỗi một lần bạn chỉnh sửa nó để tìm ra thiết kế tối ưu hóa tốt nhất.
Nếu công việc của bạn không liên quan đến việc này cả ngày, thì hãy tham gia và yêu cầu DBA của bạn bật nó ở mọi nơi.


0

"Tại sao tôi KHÔNG nên sử dụng ...." Trong quá trình điều tra hiệu suất, việc rút các kế hoạch ra khỏi bộ đệm kế hoạch gần thời gian thực, trong khi quan sát việc sử dụng tài nguyên có thể rất hữu ích. "Tối ưu hóa cho khối lượng công việc adhoc" có thể phá vỡ điều đó, vì các kế hoạch sơ khai của adhoc sẽ không trả về một kế hoạch khi truy vấn bộ đệm. Trong trường hợp như vậy, nếu không thể xác định được truy vấn và kế hoạch, cài đặt có thể được tắt và bật lại để điều tra. Lưu ý rằng thay đổi trong cài đặt hiệu ứng truy vấn được biên dịch từ thời điểm đó trở đi. Ngoài ra, bất cứ khi nào thay đổi thuộc tính 'máy chủ', hãy kiểm tra một phiên bản không liên quan ở cùng một phiên bản để xác minh xem liệu thay đổi có xóa bộ nhớ cache của gói hay không. Cá nhân tôi ghét bị ngạc nhiên bởi điều đó. (Ví dụ: thay đổi maxdop ở cấp máy chủ thường xóa bộ nhớ cache của gói,

"Sơ đồ kế hoạch đã biên dịch không có kế hoạch thực hiện được liên kết với nó và truy vấn để xử lý kế hoạch sẽ không trả về Kế hoạch hiển thị XML." http://technet.microsoft.com/en-us/l Library / cc645587.aspx

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.