จากสิ่งที่ฉันสามารถบอกได้ถึงอัตราส่วนของ Hit Cache ที่ต่ำกว่า 95% เป็นปัญหา ในกล่องของฉันค่าโฮเวอร์จาก 85 ถึง 95%
ฉันจะแก้ไขปัญหานี้ได้อย่างไร เซิร์ฟเวอร์ดูเหมือนจะมี RAM มากมายจึงไม่น่าจะมีปัญหา มีอะไรอีกบ้างที่เป็นไปได้?
คำตอบ:
ให้ฉันสรุป (และปัดเศษ!) จุดข้อมูลสำคัญในสเปรดชีตของคุณ:
Total Use Count 1
--------------------------------------- -----------------------
Total Plans Total MBs Avg Use Count Total Plans Total MBs
----------- --------- ------------- ----------- ---------
Adhoc 55,987 3,054 3 38,314 2,036
Proc 709 1,502 1,549 135 527
ดังนั้นแถวแรกจะแสดงสิ่งที่ไม่ดีใช้เวลาประมาณ 2/3 ของแคชแผนของคุณ (สิ่งที่ส่วนใหญ่เคยใช้เพียงครั้งเดียวโดยมีข้อยกเว้นเล็กน้อยเล็กน้อย) คุณต้องพยายามและกำจัดสิ่งเหล่านี้ให้ได้มากที่สุด แถวที่สองแสดงให้เห็นถึงสิ่งที่ดี นี่คือสิ่งที่คุณต้องการในแคชแผนของคุณ (แผนที่มีจำนวนการใช้ซ้ำสูง) ส่วนที่เหลือของข้อมูลส่วนใหญ่ไม่เกี่ยวข้องกับ IMHO อีกประเด็นหนึ่ง: คุณบอกว่าการเข้าถึงนั้นผ่านขั้นตอนการจัดเก็บ แต่ถ้าโพรซีเดอร์เหล่านั้นใช้ไดนามิก SQL คำสั่งเหล่านั้นจะถูกแคชเป็นAdHocแผนไม่ใช่Procแผน
ในปี 2008 หรือมากกว่านั้นฉันจะบอกว่าเปิดoptimize for ad hoc workloadsและไปยังปัญหาต่อไปซึ่งจะต้องใช้จำนวนเมกะไบต์แผนแบบใช้ครั้งเดียวของคุณในขณะนี้ที่ใช้งานไม่ได้เลย น่าเสียดายที่ในปี 2005 ตัวเลือกของคุณค่อนข้าง จำกัด นอกเหนือจากการปรับกระบวนการที่เก็บไว้ให้ใหม่เพื่อใช้ระดับคำสั่งOPTION (RECOMPILE)และ / หรือน้อยกว่า / ไม่มีไดนามิก SQL หรือเปิดการกำหนดพารามิเตอร์แบบบังคับในระดับฐานข้อมูลซึ่งพยายามนำแผนมาใช้ซ้ำ ข้อความค้นหาที่คล้ายกันโดยใช้ตัวอักษรเป็นพารามิเตอร์เพื่อจุดประสงค์ในการจับคู่แผน ฉันลังเลที่จะพูดถึงคำแนะนำแผนเพราะพวกเขาไม่ใช่คนขี้ขลาดและในขณะที่ฉันพูดถึงในภายหลังในคำตอบนี้ - ฉันไม่แน่ใจว่ามันคุ้มค่าที่จะไปตามทางนั้นเว้นแต่คุณจะรู้ว่าแคชแผนของคุณเป็นแหล่งที่มาของการทำงานของคุณ ปัญหา.
ฉันถาม@@VERSIONเพราะก่อน SP2 อัลกอริทึมสำหรับปริมาณหน่วยความจำที่สามารถจัดสรรให้กับแคชแผนค่อนข้างหลวม - ห่าน ในฐานะของ SP2 พวกเขาเข้มงวดขึ้นเล็กน้อย (การเปลี่ยนแปลงมีการบันทึกและอธิบายไว้ในโพสต์นี้และโพสต์นี้ ) ในกรณีของคุณแคชแผนค่อนข้างเต็มดังนั้นจึงไม่น่าแปลกใจที่คุณพลาดแคช 26 GB = ขีด จำกัด สูงสุดที่ 5.8 GB; ฉันเห็น ~ 4.5 GB ในสเปรดชีต แต่อาจมีความแตกต่างในการคำนวณหรือการกำหนดค่าที่นี่ซึ่งฉันไม่รู้
บทความ MSDN นี้พูดถึงการoptimize for ad hoc workloadsตั้งค่าเซิร์ฟเวอร์ที่เพิ่มในปี 2008 และกล่าวถึงการตั้งค่าสถานะการสืบค้นกลับ 8032 ซึ่งจะช่วยให้คุณสามารถจัดสรรหน่วยความจำเพิ่มเติมให้กับแคชของคุณ (สมมุติว่าไม่มีการตั้งค่านี้ในระดับเซิร์ฟเวอร์ซึ่งตอนนี้ ลูกค้าของเราหรืออย่างน้อย 99% ที่ไม่ได้อยู่ในปี 2005) ฉันไม่เคยทดสอบการตั้งค่าสถานะการติดตามนี้ในปี 2005 SP3 หรือ SP4 และโดยแท้แล้วก็ไม่แน่ใจเหมือนกันว่าจะเปิดตัวเมื่อใด ฉันก็ไม่รู้เหมือนกันว่ามันจะแก้ปัญหาของคุณหรือเพียงแค่เปลี่ยนเพราะฉันคิดว่าแม้ว่าคุณจะมี RAM ที่จัดสรรให้กับแคชมากขึ้นคุณจะยังคงกรอกข้อมูลอยู่และมีแคชที่ขาดหายไปเนื่องจากลักษณะของ ขั้นตอนการจัดเก็บของคุณ
หรือแน่นอนหากมีปัญหาในการแก้ไขที่เกี่ยวข้องโดยตรงกับแคชแผนเลย เพียงเพราะอัตราส่วนการเข้าชมแคชของคุณไม่สูงอย่างที่คุณคาดหวังไม่ได้หมายความว่ามันก่อให้เกิดปัญหาของคุณและแน่นอนการสนทนาก็คือแม้จะอยู่ที่อัตราส่วนการเข้าชมแคช 100% - ซึ่งไม่เหมือนจริง ของแผนของคุณเป็นแบบใช้ครั้งเดียวและเฉพาะกิจ - ผู้ใช้ของคุณอาจยังคงทุกข์ทรมานจากปัญหาประสิทธิภาพที่เกิดจากสิ่งอื่นโดยสิ้นเชิง
คำแนะนำของฉันคือมองหาปืนสูบบุหรี่ที่ดีกว่าอัตราการยิงแคชของแผน รับข้อมูลเฉพาะเพิ่มเติมเกี่ยวกับการร้องเรียนประสิทธิภาพของผู้ใช้ แบบสอบถามทั้งหมดช้าหรือไม่ คำค้นหาบางอย่าง? บางครั้งของวัน / สัปดาห์ / รอบธุรกิจ การรายงานการสืบค้นเพียงอย่างเดียวจะช้าหรือไม่ อ่านอย่างจริงจังถึงแนวทางปฏิบัติที่ดีที่สุดของ SQL Server ซึ่งเป็นแนวทางปฏิบัติที่ดีที่สุดของ SQL Serverโดยเฉพาะในส่วนของการรอและรอคิวซึ่งสามารถช่วยคุณกำหนดแนวทางเชิงตรรกะในการระบุวินิจฉัยและแก้ไขปัญหาด้านประสิทธิภาพ การทำให้ตัวเลขบางส่วนบนแดชบอร์ดดูดีขึ้น - ตัวเลขที่คุณไม่ทราบด้วยซ้ำว่าช่วยให้เกิดปัญหาโดยตรง - อาจเป็นที่น่าพอใจมาก แต่ถ้ามันไม่สามารถแก้ปัญหาประสิทธิภาพการทำงานของผู้ใช้ได้ ทุกแห่ง
สิ่งเหล่านี้อาจมีประโยชน์ในการอ่านการรวบรวม / การคอมไพล์ซ้ำและการแคชแผนอีกครั้ง สิ่งเหล่านี้มุ่งเน้นที่ 2008 (โดยเฉพาะอย่างยิ่งเกี่ยวกับการตั้งค่า Ad Hoc ปริมาณงาน) แต่ข้อมูลส่วนใหญ่ยังคงมีประโยชน์สำหรับปี 2005 และ / หรือเพื่อให้เข้าใจถึงประโยชน์ของการอัพเกรดได้ดีขึ้น (hint, hint)