ทำไมฉันจะไม่ใช้ตัวเลือก SQL Server“ ปรับให้เหมาะสมสำหรับปริมาณงานเฉพาะกิจ”?

ฉันได้อ่านบทความที่ยอดเยี่ยมเกี่ยวกับการแคชแผน SQL Server โดย Kimberly Tripp เช่นนี้: http://www.sqlskills.com/blogs/kimberly/plan-cache-and-optimizing-for-adhoc-workloads/

ทำไมถึงมีตัวเลือกในการ "เพิ่มประสิทธิภาพสำหรับปริมาณงานแบบเฉพาะกิจ"? สิ่งนี้ไม่ควรเกิดขึ้นหรือ ไม่ว่านักพัฒนาจะใช้ ad-hoc SQL หรือไม่ทำไมคุณไม่เปิดใช้งานตัวเลือกนี้ในทุกอินสแตนซ์ที่รองรับ (SQL 2008+) ซึ่งจะช่วยลดการขยายตัวของแคช?

ทีมพัฒนา SQL Server ทำงานบนหลักการของความประหลาดใจน้อยที่สุดดังนั้นโดยทั่วไปแล้ว SQL Server จะปิดการใช้งานคุณลักษณะใหม่เพื่อผลประโยชน์ในการรักษาพฤติกรรมเช่นเดียวกับรุ่นก่อนหน้า

ใช่การปรับให้เหมาะสมสำหรับเวิร์กโหลด adhoc นั้นยอดเยี่ยมในการลดการขยายแคชของแผน - แต่ควรทดสอบก่อนเสมอ!

[แก้ไข: Kalen Delaney บอกเกร็ดเล็กเกร็ดน้อยที่น่าสนใจว่าเธอถามเพื่อนวิศวกร Microsoft คนหนึ่งของเธอว่าจะมีสถานการณ์ที่ไม่เหมาะสมที่จะเปิดใช้งานสิ่งนี้หรือไม่ เขากลับมาอีกหลายวันต่อมาเพื่อพูด - ลองนึกถึงแอปพลิเคชันที่มีข้อความค้นหาต่าง ๆ มากมายและแบบสอบถามแต่ละรายการจะทำงานสองครั้งโดยรวม จากนั้นอาจไม่เหมาะสม พอจะบอกได้เลยว่ามีแอพไม่มากนัก!]

[แก้ไข: หากการค้นหาส่วนใหญ่ของคุณถูกดำเนินการมากกว่าหนึ่งครั้ง (ไม่ใช่สองครั้งอย่างแน่นอน); มันอาจจะไม่เหมาะสม กฎทั่วไปจะเปลี่ยนหากมีแบบสอบถาม adhoc แบบใช้ครั้งเดียวจำนวนมากบนฐานข้อมูล อย่างไรก็ตามยังมีแอพไม่มากเช่นนั้น]

ด้านล่างนี้เป็นรหัสเล็ก ๆ ที่จะช่วยให้คุณตัดสินใจได้ว่า "การเปิด / ปิดการเพิ่มประสิทธิภาพสำหรับปริมาณงานเฉพาะกิจจะเป็นประโยชน์หรือไม่ โดยปกติเราตรวจสอบสิ่งนี้เป็นส่วนหนึ่งของการตรวจสุขภาพของเราสำหรับเซิร์ฟเวอร์ภายในและลูกค้า

มันเป็นตัวเลือกที่ปลอดภัยที่สุดที่จะเปิดใช้งานและมีการอธิบายไว้อย่างดีโดยแบรดที่นี่และเกล็นแบล็กเบอร์นี่

--- 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

คิดถึงเซิร์ฟเวอร์ที่ใช้งานจริงซึ่งให้บริการการค้นหาต่าง ๆ เพียง 5 ครั้ง แต่ก็มีหลายพันรายการต่อวินาที คุณเป็นทีมพัฒนา Microsoft SQL Server คุณกำลังจะเล่นซอกับแผนการแคช คุณเปิดใช้งานพฤติกรรมนี้เป็นค่าเริ่มต้นหรือไม่เมื่อคุณรู้ว่าลูกค้ารายใหญ่ที่สุดและสำคัญที่สุดของคุณ (เช่นการติดตั้ง SAP ภายในของ Microsoft) ทำงานในวิทยาเขตเดียวกันและใช้โรงอาหารแบบเดียวกับที่คุณทำ

เมื่อคุณเปิดตัวเลือก " เพิ่มประสิทธิภาพสำหรับภาระงาน Ad Hoc " คุณจะทำให้คิวรีแบบเฉพาะกิจที่ทำงานในครั้งที่ 2 นั้นช้าเท่ากับครั้งที่ 1 เพราะคุณจะรวบรวมแผนปฏิบัติการและดึงข้อมูลเดียวกัน ( โดยไม่แคช) 2 ครั้งแรก
สิ่งนี้อาจไม่ใช่เรื่องใหญ่ แต่คุณจะสังเกตเห็นได้เมื่อทดสอบคิวรี
แล้วจะเกิดอะไรขึ้นถ้าไม่มีตัวเลือกนี้เปิดอยู่และแคชที่เต็มไปด้วยคิวรี Ad-Hoc แบบ 1-Off

อัลกอริทึมการจัดการแคช:

เนื่องจากคุณลักษณะการเพิ่มประสิทธิภาพนี้ถูกนำเสนออัลกอริทึมการจัดการแคชได้รับการปรับปรุงด้วย
บทความของ Kimberly Tripp ยังอ้างอิงโพสต์ของ Kalen Delaneyเกี่ยวกับการเปลี่ยนแปลงอัลกอริทึมนี้
เธออธิบายได้ดีที่สุด:

การเปลี่ยนแปลงจริงคำนวณขนาดแคชแผนซึ่ง SQL Server รู้จักว่ามีแรงกดดันหน่วยความจำและจะเริ่มลบแผนการออกจากแคช แผนการที่จะลบออกเป็นแผนราคาถูกที่ไม่ได้ใช้ซ้ำและนี่คือสิ่งที่ดี

ซึ่งหมายความว่าแผนการจับเวลาแบบหนึ่งที่น่ารำคาญเหล่านี้จะเป็นแผนแรกที่จะไปเมื่อคุณต้องการเพิ่มทรัพยากร

ดังนั้นตอนนี้กลายเป็นคำถาม:

    " ทำไมเราต้อง 'ปรับให้เหมาะสมสำหรับ Ad Hoc Workloads' เมื่อ SQL Server ดูแลการลบแผนที่ไม่ได้ใช้เมื่อจำเป็น? "

คำตอบของฉันคือถ้าคุณมีการสร้าง oodles แบบไดนามิก sql ที่สร้างขึ้นจำนวนมากของโฆษณาที่ไม่มีพารามิเตอร์ -hoc แบบสอบถามแล้วมันทำให้รู้สึกที่สมบูรณ์แบบในการเปิดคุณลักษณะนี้
คุณต้องการหลีกเลี่ยงการวางสายทรัพยากรระบบเช่นบังคับให้ลบแคชแผน / ข้อมูลหลังจากที่คุณใช้พื้นที่หน่วยความจำแคชสูงสุด

ฉันจะรู้ได้อย่างไรเมื่อฉันต้องเปิดใช้งาน

นี่คือข้อความค้นหาที่ฉันเขียนเพื่อแสดงให้คุณเห็นว่าคุณมีแคชแผน Ad-Hoc จำนวนเท่าไหร่และเนื้อที่ดิสก์เหลืออยู่เท่าไร (ผลลัพธ์จะเปลี่ยนไปตลอดทั้งวันดังนั้นควรทดสอบในช่วงที่โหลดหนัก):

--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

ผล:

ฉันจะไม่พูดว่า " เมื่อคุณมี X MB " หรือ " หาก X% ของ Ad Hoc ของคุณเป็นแบบใช้ครั้งเดียว " เพื่อเปิดใช้งาน
ไม่มีผลกับ Sprocs, Trigger, Views หรือ Parameterized / SQL ที่เตรียมไว้ - เพียงแค่แบบสอบถาม Ad-Hoc
คำแนะนำส่วนบุคคลของฉันคือการเปิดในสภาพแวดล้อม Prod ของคุณ แต่พิจารณาทิ้งไว้ในสภาพแวดล้อม Dev ของคุณ
ผมพูดแบบนี้เท่านั้นสำหรับ Dev เพราะถ้าคุณเพิ่มประสิทธิภาพแบบสอบถามที่ใช้เวลานาทีหรือมากกว่าที่จะทำงานแล้วคุณไม่ต้องการที่จะเรียกใช้งาน 3 ครั้งก่อนที่คุณอาจจะเห็นวิธีการที่รวดเร็วมันจะไปด้วยกับมันที่แคช - ทุกครั้งเดียวที่คุณแก้ไขเพื่อค้นหาการเพิ่มประสิทธิภาพที่ดีที่สุด
หากงานของคุณไม่เกี่ยวข้องกับการทำสิ่งนี้ตลอดทั้งวันให้ลองบ้าบิ่นและขอให้ DBA เปิดใช้งานได้ทุกที่

"ทำไมฉันไม่ควรใช้ .... " ในระหว่างการตรวจสอบประสิทธิภาพการดึงแผนออกจากแคชแผนใกล้เวลาจริงในขณะที่การสังเกตการใช้ทรัพยากรจะมีประโยชน์มาก "ปรับให้เหมาะสมสำหรับเวิร์กโหลด adhoc" อาจขัดขวางเนื่องจากแผน stub adhoc จะไม่ส่งคืนแผนเมื่อทำการแคช ในกรณีเช่นนี้หากไม่สามารถระบุการสอบถามและแผนเป็นอย่างอื่นการตั้งค่าอาจถูกเปิดและปิดอีกครั้งเพื่อประโยชน์ในการตรวจสอบ โปรดทราบว่าการเปลี่ยนแปลงในการตั้งค่าผลแบบสอบถามรวบรวมจากจุดที่ไปข้างหน้า นอกจากนี้เมื่อใดก็ตามที่เปลี่ยนคุณสมบัติ 'เซิร์ฟเวอร์' ให้ตรวจสอบอินสแตนซ์ที่ไม่ใช่ผลิตภัณฑ์ในเวอร์ชันเดียวกันเพื่อตรวจสอบว่าการเปลี่ยนแปลงจะล้างแคชแผนหรือไม่ ฉันเกลียดการประหลาดใจโดยส่วนตัว (ตัวอย่างเช่นการเปลี่ยน maxdop ที่ระดับเซิร์ฟเวอร์โดยทั่วไปจะล้างแคชแผน

"ต้นขั้วแผนเรียบเรียงไม่มีแผนการดำเนินการที่เกี่ยวข้องและการสอบถามหมายเลขอ้างอิงแผนจะไม่ส่งคืน Showplan XML" http://technet.microsoft.com/en-us/library/cc645587.aspx