ย่อขนาดฐานข้อมูลให้ต่ำกว่าขนาดเริ่มต้น

ฉันมีฐานข้อมูล dev SQL Server 2005 ที่เป็นสำเนา 30GB เราได้ลบข้อมูลบางส่วนที่ไม่ต้องการใน dev ซึ่งนำพื้นที่ไฟล์ข้อมูลที่ใช้ไปถึง 20GB ดังนั้นเราจึงไม่ได้ใช้ประมาณ 33%

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

• ขนาดเริ่มต้นของไฟล์SMS2_Dataคือ 30GB

  DBCC SHRINKFILE (N'SMS2_Data' , 0, TRUNCATEONLY)

  ติดตามโดย

  DBCC SHRINKFILE (N'SMS2_Data' , 19500)

ไม่มีความสุข ฉันได้ลองทำสำเนาสำรองสร้างฐานข้อมูลใหม่ที่มีขนาดเริ่มต้นต่ำแล้วกู้คืนไม่มีความสุขเมื่อขนาดเริ่มต้นถูกเขียนทับ ได้ลองแล้ว:

ALTER DATABASE SMS2HazSub MODIFY FILE (NAME = 'SMS2_Data', SIZE = 20000) 

ข้อผิดพลาดนี้บอกว่า:

ไฟล์ MODIFY ล้มเหลว ขนาดที่ระบุน้อยกว่าขนาดปัจจุบัน

ฉันลอง 20,800 และจากนั้นก็ขึ้นไปเรื่อย ๆ จนถึง 29000 (29GB) และมันจะไม่ยอมให้ฉันเปลี่ยน

เสร็จสิ้นการย่อแล้วเปลี่ยนโหมดการกู้คืนจากFULLไปSIMPLEและกลับมาอีกครั้ง ไม่มีความสุข

ฉันคิดว่ามันเกี่ยวข้องกับบางTEXTสาขา เรามีประมาณ 6 ในระบบ ดังนั้นในการทดสอบฉันปล่อยมันทั้งหมดแล้วย่อขนาดของไฟล์และยังคงไม่เปลี่ยนแปลง

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

ฉันพยายามย้ายข้อมูลไปยังไฟล์อื่นและคัดลอกทั้งหมดยกเว้น 5% ของข้อมูล นี่คือสิ่งที่ทำให้ฉันลองและวางคอลัมน์ข้อความทั้งหมด

เซิร์ฟเวอร์อยู่ในโหมดความเข้ากันได้ 90 แต่เป็น SP2 ตอนนี้ฉันได้ทำ 3 ครั้งต่อไปนี้: ทำดัชนีตารางทั้งหมดฐานข้อมูลสำรองไฟล์ย่อขนาดลดขนาดฐานข้อมูล ยังไม่มีความสุข

EXECUTE sp_spaceused ผลตอบแทน:

database_name   database_size   unallocated space
SMS2Tests       31453.94 MB     13903.16 MB

reserved     data         index_size   unused
16545568 KB  10602264 KB  4254360 KB   1688944 KB

บางคนพูดถึงแล้วคุณสามารถสร้างฐานข้อมูลใหม่และ "คัดลอก" สิ่งต่าง ๆ จากฐานข้อมูลเก่า นี่จะเป็นตัวเลือกที่ดีที่สุดสำหรับคุณ อย่างไรก็ตามฉันสังเกตเห็นว่าคุณต้องการทำมันเป็นประจำ ดังนั้นตัวเลือกที่ดีที่สุดของคุณคือRedgate ข้อมูลเปรียบเทียบและRedgate เปรียบเทียบ ทั้งสองเป็นส่วนหนึ่งของแพ็คเกจRedgate SqlToolbelt

ดังนั้นสิ่งที่คุณทำ:

1. สร้าง DB ว่างด้วยขนาดเริ่มต้นเล็ก ๆ
2. ใช้ Redgate Compare เพื่อคัดลอกโครงสร้าง db ฟังก์ชั่นอื่น ๆ จากฐานข้อมูลเก่า
3. ใช้ Redgate Data Compare เพื่อคัดลอกข้อมูลจากฐานข้อมูลเก่าไปยังใหม่
4. คุณทำงานกับฐานข้อมูล dev และเมื่อใดก็ตามที่คุณทำเพียง Data Compare และอัพเดต Dev DB เป็นประจำหรือถ้าคุณทำการเปลี่ยนแปลงใด ๆ กับ db คุณสามารถปรับใช้การเปลี่ยนแปลงเหล่านั้นได้โดยใช้ Redgate Compare จากนั้นทำการ Redgate Data Compare

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

ความเป็นไปได้เล็กน้อยที่นี่

ก่อนอื่นคุณใช้ SQL 2005 SP3 หรือใหม่กว่า บางคนได้รายงานปัญหา SHRINKFILE ในรุ่นก่อนหน้า (ดูhttp://www.sqlservercentral.com/Forums/Topic981292-146-6.aspx#bm985164 )

ประการที่สองคุณสามารถตรวจสอบว่าฐานข้อมูลถูกตั้งค่าเป็นความเข้ากันได้ของโหมด 90 ไม่ใช่โหมด 80 หรือไม่ เห็นได้ชัดว่านี่เป็นปัญหาของ SQL 2000 แต่มีการยกข้อ จำกัด ใน SQL 2005 ถ้าฐานข้อมูลของคุณยังคงตั้งค่าความเข้ากันได้ของโหมด 80 อาจเป็นปัญหา

ประการที่สามอาจเป็นปัญหากับข้อมูล LOB (ข้อความ, ntext, varchar (สูงสุด)) ดูบทความที่ดีเยี่ยมของ Paul Randall ที่นี่

ฉันสมมติว่าคุณเข้าใจว่าการหดตัวจริงทำอะไรและจะส่งผลเสียต่อประสิทธิภาพการทำงานของคุณ:

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

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

หากคุณดู SPID ที่ลดขนาดของคุณในการตรวจสอบกิจกรรมดูเหมือนว่าจะทำอะไรหรือไม่? (ตัวนับ IO และ CPU เปลี่ยนแปลง) หรือมันถูกบล็อค? สิ่งเดียวที่ฉันคิดได้ก็คือถ้ามีกิจกรรมอื่น ๆ ในฐานข้อมูลการปิดกั้นการหดตัว ตรวจสอบให้แน่ใจว่าไม่มี spids ที่ใช้งานอยู่อื่น ๆ กำลังใช้ฐานข้อมูลในเวลานั้น

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

หากคุณต้องการทำสิ่งนี้จริงๆ:

• ตั้งเป็นโหมดการกู้คืนที่เรียบง่าย
• ระวัง: DBCC SHRINKDATABASE (MyDatabase, TRUNCATEONLY);

SHRINKDATABASE จะลดขนาดฐานข้อมูล (อย่างดีที่สุด) ไปยัง MinSize ของมันเพื่อที่จะไม่ช่วยคุณ

เมื่อคุณลองคุณย่อขนาดไฟล์ผ่าน SSMS UI โดยใช้ค่าเริ่มต้นจะใช้ 'DBCC SHRINKFILE (N'MyDB', 0, TRUNCATEONLY) ' คำสั่งนั้นจะย่อขนาดไฟล์ (อย่างดีที่สุด) ให้เท่ากับขอบเขตที่จัดสรรล่าสุด

หากคุณต้องการย่อขนาดไฟล์ด้านล่าง MinSize เพียงแค่เปลี่ยนพารามิเตอร์DBCC SHRINKFILEจาก 0 เป็นขนาดที่คุณต้องการพยายามลดขนาดไฟล์เป็น MB หมายเลขที่ไม่เป็นศูนย์จะบอกให้ SHRINKFILE ย่อขนาดไฟล์ให้เป็นขนาดนั้นถ้าเป็นไปได้ ดังนั้นDBCC SHRINKFILE('MyDB', 300, TRUNCATEONLY)จะย่อขนาดไฟล์เป็น 300MB หากฐานข้อมูลมีพื้นที่ว่าง

คุณสามารถดู MinSize ได้โดยทำสิ่งนี้:

DBCC TRACEON(3604)
go
DBCC PAGE('MyDB', 1, 0, 3) with tableresults
go

MinSize เป็น MB คำนวณด้วยวิธีนี้: (MinSize * 8) / 1024

ถ้าคุณมีกล่าวว่า 20003 (mb) ของ datat จริงในฐานข้อมูลแล้ว "SIZE = 20000" จะเล็กเกินไป ลองกับ 21000 หรือ 25000 ดูว่ามันใช้ได้ไหม (และจำไว้ว่า 1 GB = 1024 MB)

ลอง

DBCC SHRINKDATABASE (N'SMS2_Data' , 0)

ฉันใช้สิ่งนี้กับฐานข้อมูล SQL 2005 ที่ฉันมีที่นี่และพื้นที่ที่จัดสรรสำหรับไฟล์ข้อมูลเพิ่มขึ้นจาก 10.2 GB เป็น 3 GB

Fyi นี่เป็นกระบวนการที่ใช้เวลานานและใช้เวลานานกว่า 19 นาทีสำหรับฐานข้อมูลของฉัน

ฉันสมมติว่าคุณมีไฟล์ฐานข้อมูลเดียวที่มีชื่อโลจิคัล SMS2_Data คุณมีไฟล์บันทึกธุรกรรมอย่างน้อยหนึ่งไฟล์ในฐานข้อมูล

คุณมีความท้าทายที่ไม่สามารถแก้ไขได้ในสำเนาปัจจุบันของฐานข้อมูล ข้อมูลสำคัญที่คุณระบุคือ 'ขนาดดั้งเดิมของไฟล์ฐานข้อมูลคือ 30 GB' น่าเสียดายที่ไฟล์นี้ไม่สามารถย่อขนาดเล็กกว่าขนาดดั้งเดิมได้

ในขณะที่คุณมีประสบการณ์แล้ว SHRINKDB และ SHRINKFILE ไม่ได้ให้สิ่งที่คุณต้องการ คำสั่งเหล่านี้เป็นไปตามกฎไม่สามารถเล็กลงกว่ากฎขนาดดั้งเดิม ดังนั้นคุณสามารถย่อขนาดฐานข้อมูลให้มีขนาดดั้งเดิมและไม่เล็กลงได้

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

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

ดังนั้นทางออกที่ดีที่สุดคือการคัดลอกข้อมูลไปยังฐานข้อมูลอื่น คุณมีตัวเลือกไม่กี่อย่างที่นี่และบางทีคุณอาจรู้อยู่แล้ว ขั้นตอนแรกคือการสร้างฐานข้อมูลใหม่ที่มีขนาดที่เล็กกว่าขนาดข้อมูล จากนั้นคุณสามารถขยายขนาดฐานข้อมูลเป็นขนาดที่ต้องการ

คุณอาจพิจารณา SSIS เป็นวิธีการถ่ายโอนข้อมูลจากฐานข้อมูลหนึ่งไปยังอีก คุณจะพบงานฐานข้อมูลการคัดลอกที่จะช่วยคุณออก คุณสามารถใช้ขั้นตอนต่อไปนี้:

1. สร้างฐานข้อมูลใหม่ที่มีขนาดเล็กกว่าฐานข้อมูลต้นทาง
2. ตั้งค่าแพ็คเกจ SSIS ด้วยงานฐานข้อมูลการถ่ายโอน ตั้งค่าภารกิจให้ใช้การถ่ายโอนออนไลน์
3. เรียกใช้แพคเกจ SSIS
4. แพคเกจ SSIS อาจเปลี่ยนขนาดฐานข้อมูลให้ตรงกับขนาดฐานข้อมูลต้นทาง ย่อขนาดฐานข้อมูลนี้เนื่องจากมีขนาดไฟล์ต้นฉบับที่เล็กลง

ดูข้อมูลเพิ่มเติมเกี่ยวกับ SSIS งานฐานข้อมูลการถ่ายโอน

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

ลองโทรหาDBCC DBREINDEX (table_name, '', 100)ทุกตารางในฐานข้อมูลของคุณ - มันจะสร้างดัชนีทั้งหมดที่มีปัจจัยเติมเต็ม 100% ดังนั้นข้อมูลจะถูกวางไว้อย่างกะทัดรัดที่สุด จากนั้นลองย่อขนาดฐานข้อมูลอีกครั้ง

ฉันพบว่าการลดขนาดฐานข้อมูล SQL Server อาจเป็นปัญหาได้ รู้สึกเหมือนได้ทำเพลงและเต้นรำเป็นประจำ

นี่เป็นกระบวนการที่ฉันมักจะทำ:

Backup Shrink database ฐานข้อมูล Backup Shrink และไฟล์ฐานข้อมูลแยกต่างหาก ทำซ้ำการสำรองข้อมูลจนกว่าจะลดขนาดลงในที่สุด

ฉันต้องทำขั้นตอนนี้สามครั้งเพื่อให้มันทำงานได้ในที่สุด เรามีฐานข้อมูลขนาดใหญ่กว่า 68 GB โดยมีพื้นที่ที่ไม่ได้ใช้งาน 98% ผ่านกิจวัตรเพลงและการเต้นรำนี้หลายครั้ง แต่ในที่สุดมันก็หดลงเหลือต่ำกว่า 1GB

ฉันจะพยายามลดขนาดเริ่มต้นของไฟล์ mdf เป็น 29,000 MB ก่อนจากนั้นเหลือ 28,000 การตรวจจับการโจมตีที่ใกล้ที่สุด

ไม่มีเหตุผลที่คาดว่าจะลดขนาดไฟล์ฐานข้อมูลได้ 30% ด้วยการลบข้อมูล 30%

คุณสามารถประมาณพื้นที่ที่ไม่ได้ใช้ในฐานข้อมูลของคุณได้

execute sp_spaceused

ในบริบทของฐานข้อมูลของคุณ (ใช้ yourdatabaename;)
คุณสามารถโพสต์ผลลัพธ์ของการดำเนินการได้หรือไม่?

อัปเดต:
ฉันโพสต์คำถามที่เกี่ยวข้องใน:

• การบีบอัดการจัดเรียงข้อมูลการเรียกคืนพื้นที่การหดตัวฐานข้อมูลและการลดขนาดไฟล์