คุณมีเหตุผลที่ดีที่ควรคำนึงถึงเนื่องจากการลดขนาดฐานข้อมูลใน SQL Server มักจะ "ดูด" Paul Randal หัวหน้าแผนกเครื่องมือจัดเก็บข้อมูลใน SQL 2005 ระบุไว้ว่า ShrinkDB เขียนได้แย่มาก มันจะหาพื้นที่ว่างโดยการเก็บข้อมูลไว้ที่จุดสิ้นสุดสุดและวางไว้ในจุดเริ่มต้นและทำต่อไปเรื่อย ๆ จนกว่าจะมีพื้นที่ว่างที่ส่วนท้ายของไฟล์ DB ณ จุดนี้มันสามารถปล่อยพื้นที่จาก SQL Server และคืนสู่ระบบปฏิบัติการ คุณกลับไฟล์ฐานข้อมูลของคุณได้อย่างมีประสิทธิภาพดังนั้นคุณจะเห็นการแตกแฟรกเมนต์ขนาดใหญ่ตามปกติ คุณสามารถอ่านเกี่ยวกับมุมมองของเขาในโพสต์บล็อกนี้หรือวิดีโอMCM Internals
เช่นเดียวกับทุกสิ่งคุณต้องทดสอบสิ่งเหล่านี้ในสภาพแวดล้อมของคุณก่อน วิธีที่ดีกว่าในการทำเช่นนี้คือการย้ายข้อมูลไปยังกลุ่มไฟล์อื่น คุณสามารถสร้างดัชนีออนไลน์ใหม่ด้วยดัชนีคลัสเตอร์จากนั้นทำดัชนีใหม่ในกลุ่มไฟล์ใหม่ จากนั้นคุณสามารถดรอปอันเก่าแล้วปล่อยที่ว่างและแทบจะไม่มีการแตกแฟรกเมนต์ หมายเหตุสิ่งนี้จะใช้พื้นที่เพิ่มประมาณ 120% ในขณะที่ทำงานผ่าน ปัญหาของเรื่องนี้คือคุณต้องมีพื้นที่ว่างเพิ่มเติมซึ่งดูเหมือนว่าคุณอาจไม่มี นี่คือคุณสมบัติขององค์กร
หากพื้นที่ว่างอยู่ในระดับพรีเมี่ยมส่วนใหญ่คุณอาจจะต้องกัดกระสุนและค่อยๆลดขนาดฐานข้อมูลทีละน้อยเพื่อหลีกเลี่ยงกระบวนการทำงานที่ยาวนาน โปรดทราบว่าข้อมูลของคุณจะถูกแยกส่วนอย่างหนักและคุณจะต้องการทำดัชนีทุกอย่างอีกครั้ง โปรดทราบว่าหลังจากทำดัชนีใหม่ทุกสิ่งแล้วคุณจะเพิ่มพื้นที่ว่างในพื้นที่ที่ใช้ไปแล้วและกลับไปที่พื้นที่ว่างเพิ่มเติม ดูคำแนะนำเบรนต์ของที่นี่
เท่าที่พื้นที่ว่างที่ดีสำหรับคุณนั้นเป็นเรื่องของจำนวนเงินที่คุณสามารถจ่ายได้สำหรับกิจกรรมการแยกส่วนและการเติบโตของไฟล์ ด้วยการเปิดใช้งาน IFI การเติบโตของไฟล์เกือบจะทันที แต่คุณยังคงได้รับการกระจายตัว กฎง่ายๆคือการจัดสรรล่วงหน้าให้มากที่สุดเท่าที่คุณคิดว่าคุณต้องการหรือตรวจสอบการเติบโตและปรับเปลี่ยนเป็นระยะถ้าคุณต้องการ สิ่งนี้ทำให้การกระจายตัวทางกายภาพลดลง
การเติบโตของไฟล์บันทึกก็มีความสำคัญมากกว่าเช่นกัน ไฟล์บันทึกเพิ่มเติมสามารถทำให้เกิดการแตกแฟรกเมนต์ VLF สิ่งนี้ทำให้การกู้คืนของคุณช้าลงมากและอาจส่งผลกระทบต่อจุดตรวจ / ตัดปลาย ต่อไปนี้คือความเสี่ยงด้านประสิทธิภาพที่คุณต้องใช้เมื่อมีการแยกส่วนไฟล์บันทึก ทำDBCC LOGINFO();บนแต่ละฐานข้อมูล พยายามที่จะเก็บหมายเลขประมาณ 50ish ต่อ Kim Tripp แต่ถ้าคุณเห็นหลายร้อยคุณมีปัญหาการกระจายตัวซึ่งหมายความว่าไฟล์บันทึกของคุณต้องเติบโตเพื่อรองรับการดำเนินงาน วิธีที่ดีในการดูว่าไฟล์บันทึกของคุณควรเป็นอย่างไรต่อ Paul Randal คือปล่อยให้มันเติบโตเป็นเวลาหนึ่งสัปดาห์และทำดัชนีใหม่ นั่นอาจเป็นจุดที่ดีบางทีคุณอาจใช้พื้นที่ว่างเพิ่มขึ้นเล็กน้อยในกรณีนี้ ตรวจสอบให้แน่ใจว่าบันทึกของคุณไม่ได้แยกส่วนด้วย DBCC LOGINFO (); อีกครั้งและถ้าเป็นเช่นนั้นก็หมายความว่าพวกเขาเติบโตขึ้นมาก ย่อขนาดและขยายไฟล์บันทึกอีกครั้งโดยใช้วิธีนี้