เมื่อใดควรใช้ sort_in_tempdb เมื่อสร้างดัชนีใหม่

เรากำลังถกเถียงกันว่าจะใช้ตัวเลือก SORT_IN_TEMPDB สำหรับตาราง DW ของเราหรือไม่ ความเข้าใจของฉันคือว่ามีการเขียนเพิ่มเติมเมื่อใช้ตัวเลือกนี้แม้ว่าพวกเขาจะเรียงตามลำดับมากขึ้น เรามี SAN (ซึ่งช้ามากในบางครั้ง) ดังนั้นในกรณีของเราเราต้องการ จำกัด จำนวนการเขียนให้มากที่สุด ฉันเชื่อว่า tempdb อยู่ใน LUN แยกต่างหาก (ชุดของดิสก์)

เรามีพื้นที่ดิสก์มากมายในไฟล์ข้อมูลและไฟล์ tempdb ของเรา ในกรณีนี้เราจะได้ประโยชน์จากการใช้ SORT_IN_TEMPDB ไหม

สิ่งหนึ่งที่ทำให้ฉันรู้สึกแย่คือความเห็นต่อคำตอบนี้

เมื่อสร้างดัชนีใหม่คุณจะต้องมีพื้นที่ว่างสองเท่าของดัชนี + 20% สำหรับการเรียงลำดับ โดยทั่วไปแล้วการสร้างดัชนีทุกครั้งในฐานข้อมูลของคุณคุณต้องการเพียง 120% ของดัชนีที่ใหญ่ที่สุดในฐานข้อมูลของคุณ หากคุณใช้ SORT_IN_TEMPDB คุณจะได้รับเพียง 20% คุณยังคงต้องการ aditional 100% ในไฟล์ข้อมูลของคุณ ยิ่งไปกว่านั้นการใช้ sort in tempdb จะเพิ่มการโหลด IO ของคุณอย่างมากเนื่องจากแทนที่จะเขียนดัชนีหนึ่งครั้งไปยัง datafile ตอนนี้คุณเขียนมันหนึ่งครั้งไปยัง tempdb แล้วเขียนลงในไฟล์ข้อมูล ดังนั้นจึงไม่เหมาะเสมอไป

แน่นอนว่าเราไม่ต้องการเพิ่มโหลด IO ของเราด้วย SAN ที่ช้า / อาจผิดพลาด

อะไรจะเป็นวิธีที่ดีที่สุดในการทดสอบสิ่งนี้? โดยเพียงแค่สร้างตารางขึ้นใหม่โดยมีและไม่มีตัวเลือกและบันทึกเวลา?

แก้ไข : เรามีไฟล์ 8 tempdb แต่ละไฟล์ 15GB เรามีการตั้งค่าสถานะ TF 1117/1118 และเปิดใช้งาน IFI แล้ว ขณะนี้เรากำลังผสมการสร้างใหม่ด้วยตัวเลือก sort_in_tempdb และไม่รวม

ขอบคุณ!

องค์กร SQL Server 2012

SORT_IN_TEMPDBหมายความว่าเซิร์ฟเวอร์ SQL จะใช้tempdbในการจัดสรรพื้นที่ชั่วคราวเมื่อเทียบกับการจัดสรรพื้นที่ในฐานข้อมูลผู้ใช้ที่มีการสร้างดัชนีใหม่ ซึ่งหมายความว่าคุณจะต้องมีพื้นที่ว่างน้อยลงในฐานข้อมูลผู้ใช้ของคุณในระหว่างการดำเนินการสร้างดัชนีและพื้นที่ว่างเพิ่มเติมใน tempdb

มันจะช่วยให้คุณได้เปรียบที่ดีขึ้นเมื่อ tempdb อยู่ในชุดของดิสก์ (LUNs) อื่นจากฐานข้อมูลผู้ใช้

จากตัวเลือก SORT_IN_TEMPDB - BOL :

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

ให้แน่ใจว่าคุณอ่านความต้องการของพื้นที่ดิสก์เมื่อ SORT_IN_TEMPDB เป็น ON

ช้า / อาจกำหนดค่า SAN ผิด

คุณรู้จุดปวด ทำไมคุณไม่ทำงานกับผู้ดูแลระบบ SAN ของคุณเพื่อแก้ไขมัน? ความผิดพลาดและ SAN หรือช้าจะทำให้เกิดการเรียงลำดับของปัญหาเช่นช้า

ประเด็นสำคัญที่ควรทราบ:

• ใช้MAXDOP = 1 เมื่อสร้างดัชนีออนไลน์ใหม่มิฉะนั้นจะทำให้เกิดการแตกแฟรกเมนต์เพิ่มขึ้น
• จัดทำดัชนีใหม่อย่างชาญฉลาด / สร้างดัชนีของคุณใหม่ตามระดับการแตกแฟรกเมนต์
• อ่านประสบการณ์ของ SQLFool ด้วยการสร้างดัชนี 60 GB
• ตรวจสอบให้แน่ใจว่าคุณ tempdb ได้กำหนดค่าอย่างถูกต้อง - TF 1117 (เติบโตทุกไฟล์ใน FILEGROUP อย่างเท่าเทียมกัน) และ 1118 (extents เต็มเท่านั้น)และมีdatafiles tempdb มากขึ้น

อะไรจะเป็นวิธีที่ดีที่สุดในการทดสอบสิ่งนี้?

ใช่คุณมีการทดสอบได้โดยการวิเคราะห์ WAITSTATSSORT_IN_TEMPDBเมื่อคุณสร้างดัชนีที่มีและไม่มี วัดเวลาทำงานเช่นกันและเมื่อดำเนินการใน PROD ตรวจสอบให้แน่ใจว่าคุณทำในระหว่างการบำรุงรักษาหรือกิจกรรมเซิร์ฟเวอร์น้อยลง นอกจากนี้ยังตรวจสอบข้อมูลการอ่าน / เขียนของคุณและเข้าสู่ระบบแอบแฝง

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