มีประโยชน์ใด ๆ ในการจัดเรียงข้อมูลดัชนี SQL ในสภาพแวดล้อม SAN หรือไม่?

เซิร์ฟเวอร์ SQL ของเราใช้งาน SAN มันมีฐานข้อมูล OLTP หลายสิบบางตัวมีหลายตารางที่มีมากกว่า 1m บันทึก

เรารันสคริปต์บำรุงรักษาดัชนีของ Ola Hallengrenทุกสัปดาห์และทำงานเป็นเวลาหลายชั่วโมงในแต่ละครั้ง ขึ้นอยู่กับเกณฑ์การกระจายตัวของสคริปต์จะจัดระเบียบใหม่หรือดัชนีดัชนีใหม่ เราสังเกตว่าในระหว่างการทำดัชนีใหม่ไฟล์บันทึกจะมีขนาดใหญ่ซึ่งนำไปสู่การสิ้นเปลืองแบนด์วิธที่มากเกินไปในระหว่างการจัดส่งบันทึก

จากนั้นบทความจาก Brent Ozar ซึ่งเขาบอกว่าจะหยุดกังวลเกี่ยวกับดัชนี SQL :

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

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

คำตัดสินสุดท้ายคืออะไร? มันคุ้มค่าหรือไม่ที่จะจัดเรียงดัชนี SQL บน SAN โดยพิจารณาภาระที่เกี่ยวข้องกับการรันงานบำรุงรักษารายสัปดาห์

กลยุทธ์การจัดเรียงข้อมูลช่วยในการปรับปรุงการสแกนความเร็วจาก / ไปยังดิสก์

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

สมมติว่าฐานข้อมูลของคุณถูกเก็บไว้ใน SAN มีข้อมูลไม่เพียงพอ ตัวอย่างเช่น:

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

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

• มีSLA ประสิทธิภาพในการเล่นในช่วงระยะเวลาการกู้คืน / เกิดความล้มเหลวหรือไม่?

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

หากการบำรุงรักษาดัชนีเป็นภาระให้ลองลดค่าใช้จ่ายลงอย่างหนักและ / หรือลดค่าใช้จ่ายตลอดสัปดาห์

คุณยังสามารถเปิดSortInTempdbตัวเลือกเพื่อลดปริมาณการบันทึกที่เกิดขึ้นในฐานข้อมูลผู้ใช้

ตามหลักการแล้วคุณควรจัดโครงสร้างใหม่ / จัดทำดัชนีใหม่เฉพาะดัชนีที่ต้องการความสนใจไม่เช่นนั้นคุณกำลังสูญเสียทรัพยากรและอาจทำให้เกิดปัญหาอื่น ๆ

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

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

วิธีการสายตาสั้นที่นี่จะมีประสิทธิภาพเมื่อดึงข้อมูลภายในและฐานข้อมูล OLTP ปรับปรุงหากดัชนีมีการแยกส่วนหรือสร้างใหม่ คำตอบคือใช่! อย่างไรก็ตามมันเป็นสิ่งสำคัญที่จะต้องทราบว่าการกระจายตัวของดิสก์ยังเป็นปัจจัย

โดยรวม "ต้นทุน" ต่ำที่สุด ทำการบำรุงรักษาฐานข้อมูลของคุณ ประการที่สองต้นทุนต่ำสุดถอดฐานข้อมูลเคลื่อนย้ายไปที่อื่นอีกรูปแบบดิสก์ของคุณและปฏิบัติตามวิธีปฏิบัติที่ดีที่สุดสำหรับดิสก์ Partition จัดhttp://msdn.microsoft.com/en-us/library/dd758814.aspx สุดท้าย แต่ไม่ท้ายสุดให้ใช้ตัวจัดเรียงข้อมูลขั้นสูงของบุคคลที่สามเช่น Diskkeeper

โปรดจำไว้ว่านี่เป็นเพียงการแนะนำสำหรับการจัดเก็บประเภท NTFS (เช่น Windows OS) และนี่ไม่ใช่การรับรองสำหรับผลิตภัณฑ์ใด ๆ หรือฉันไม่เกี่ยวข้องกับ Condusiv Technologies หรือ บริษัท ในเครือ