ความไม่เหมาะสมของการใช้ STATISTICS_NORECOMPUTE


9

เมื่อไม่นานมานี้ฉันได้มีส่วนร่วมในการบำรุงรักษาชุดฐานข้อมูลที่มีปัญหาดัชนีที่น่าสนใจ หนึ่งในสิ่งที่ทำให้ฉันแย่ที่สุดคือความแตกต่างของดัชนีระหว่างการพัฒนาการทดสอบแบบจำลองและเครื่องจักรการผลิต เนื่องจากความแตกต่างทำให้การปรับแต่งแบบสอบถามค่อนข้างยากที่จะทำการซิงค์เป็นหนึ่งในโครงการแรกของฉัน

ในขณะที่ฉันได้เปรียบเทียบสภาพแวดล้อมการทดสอบและแบบจำลองฉันได้สังเกตเห็นว่าดัชนีส่วนใหญ่ในสภาพแวดล้อมแบบจำลองได้STATISTICS_NORECOMPUTEตั้งค่าไว้ONในขณะที่ไม่ได้ทำการทดสอบ ในสภาพแวดล้อมทั้งหมดมีงานยามค่ำคืนที่อัพเดตสถิติของฐานข้อมูลทั้งหมด

ฉันไม่เคยจัดการSTATISTICS_NORECOMPUTEมาก่อนดังนั้นนี่คือคำถามของฉัน มีแนวทางปฏิบัติที่ดีที่สุดเมื่อจัดการกับการตั้งค่านี้หรือไม่? หากฉันกำลังอัปเดตสถิติในตอนท้ายของวันดีที่สุดที่จะเปิดSTATISTICS_NORECOMPUTEในทุกสภาพแวดล้อมของดัชนีทั้งหมดหรือไม่ หรือมีเหตุผลที่ดีที่จะไม่?

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


คุณจะต้องเห็นใบสมัครนี้จะเชื่อมัน บางตารางมีดัชนีหลายสิบบางไม่มีไม่มีหลายมีหลายซ้ำ มันเป็นเรื่องจริง แนวทางทั่วไปที่จะไปด้วย? ฉันสามารถอ่านหนังสือได้ที่ไหนบ้าง?
Kenneth Fisher

1
กรณีที่ดีอย่างหนึ่งคือการใช้ STATISTICS_NORECOMPUTE = ON และ FILLFACTOR = 100 สำหรับตารางการค้นหาแบบอ่านอย่างเดียวที่เปลี่ยนแปลงโดย DBA เท่านั้นที่ใช้สคริปต์ที่สร้าง INDEX REBUILD กับ FULLSCAN หลังจากการเปลี่ยนแปลง จากนั้นตารางในรูปร่างที่ดีที่สุดพร้อมสถิติที่ดีที่สุดและไม่มีการเปลี่ยนแปลงอื่น ๆ ไม่มีเหตุผลที่จะต้องพิจารณาการคำนวณสถิติใหม่หรือออกจากพื้นที่เพื่อลดการแยกหน้าในการเปลี่ยนแปลงในอนาคต
ต่อต้านรหัสผ่านอ่อนแอ

คำตอบ:


4

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

อย่างไรก็ตามคำแนะนำทั่วไปเพื่อเปิดสถิติการอัปเดตอัตโนมัติ ( STATISTICS_NORECOMPUTE = OFFซึ่งเป็นค่าเริ่มต้น) สำหรับเหตุผลด้านความปลอดภัยเพราะหากปิดและไม่มีการอัปเดตสถิติด้วยตนเองผลลัพธ์อาจเป็นแผนปฏิบัติการที่น่ากลัวจริงๆซึ่งไม่เคยเปลี่ยนแปลง หลังจากสร้างครั้งแรก (และไม่ได้รับการรับรองความถูกต้องด้วยเหตุผลอื่นในภายหลัง)

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

ลองคิดดูอีกครั้งฉันจะบอกว่ากลยุทธ์ปัจจุบันเหมาะสมแล้ว ดีกว่าปล่อยให้สถิติการอัปเดตอัตโนมัติเปิดสำหรับทุกสิ่งหรือไม่ ดูเหมือนว่าบางคนคิดเช่นนั้นจนถึงจุดที่คุ้มกับความสะดวกในการบริหารจัดการที่มีงานตัวแทนของ SQL ที่เกี่ยวข้อง

หากแนวคิดนี้มีสถิติใหม่โดยไม่ปิดกั้นข้อความค้นหา (เช่นนี้ ) คุณสามารถลองเปิดการอัปเดตอัตโนมัติอีกครั้งสำหรับทุกสิ่งแล้วเปิดAUTO_UPDATE_STATISTICS_ASYNCอีกด้วย จากนั้นอาจเปลี่ยนตารางเวลางานให้ทำงานสัปดาห์ละครั้งแทนที่จะเป็นรายวันเนื่องจากคุณยังคงต้องการสถิติที่อัปเดตWITH FULLSCANเป็นระยะ

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


อ๊ะ ... ฉันคิดว่าฉันเลือกที่จะไม่ส่งความคิดเห็นนี้
swasheck
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.