ตัดทอนตาราง 200GB แต่พื้นที่ดิสก์ไม่ออก

23

ฉันเหลือเพียง 2GB ดังนั้นฉันต้องลบตารางประวัตินี้ ตารางนี้ในขณะนี้ว่างเปล่า แต่พื้นที่ดิสก์ฐานข้อมูลไม่ออก และไฟล์ฐานข้อมูล 320GB

sql-server sql-server-2012 truncate

— Lucas Rodrigues Sena
แหล่งที่มา

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

— Lucas Rodrigues เสนา

25

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

สิ่งที่คุณต้องการจะมองหาถ้าคุณมีDBCC SHRINKFILEการเรียกคืนพื้นที่บนไดรฟ์จะหดตัวไฟล์โดยเฉพาะอย่างยิ่งกับ เป็นมูลค่า noting ปฏิบัติที่ดีที่สุดไม่กี่ตามเอกสารที่:

ปฏิบัติที่ดีที่สุด

พิจารณาข้อมูลต่อไปนี้เมื่อคุณวางแผนที่จะย่อขนาดไฟล์:

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

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

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

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

ยังทราบ:

DBCC SHRINKFILE การดำเนินการสามารถหยุดที่จุดใด ๆ ในกระบวนการและงานที่เสร็จสมบูรณ์ใด ๆ จะถูกเก็บไว้

มีบางสิ่งที่ควรพิจารณาเมื่อทำสิ่งนี้และฉันขอแนะนำให้คุณดูโพสต์บล็อกของ Paul Randalเกี่ยวกับสิ่งที่เกิดขึ้นเมื่อคุณดำเนินการนี้

ขั้นตอนแรกคือการตรวจสอบจำนวนเนื้อที่และพื้นที่ว่างที่คุณสามารถแทนที่ได้จริงรวมถึงพื้นที่ที่ใช้ในไฟล์:

use AdventureWorks2012;
go

;with db_file_cte as
(
    select
        name,
        type_desc,
        physical_name,
        size_mb = 
            convert(decimal(11, 2), size * 8.0 / 1024),
        space_used_mb = 
            convert(decimal(11, 2), fileproperty(name, 'spaceused') * 8.0 / 1024)
    from sys.database_files
)
select
    name,
    type_desc,
    physical_name,
    size_mb,
    space_used_mb,
    space_used_percent = 
        case size_mb
            when 0 then 0
            else convert(decimal(5, 2), space_used_mb / size_mb * 100)
        end
from db_file_cte;

— Thomas Stringer
แหล่งที่มา

6

นี่เป็นพฤติกรรมปกติเมื่อคุณตัดทอนตารางและเกี่ยวข้องกับการลบขอบเขตมากกว่า 128 รายการตามหนังสือออนไลน์

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

โปรแกรมฐานข้อมูลหลีกเลี่ยงการล็อคการจัดสรรที่จำเป็นสำหรับการปล่อยวัตถุขนาดใหญ่โดยแยกกระบวนการออกเป็นสองเฟส: ตรรกะและฟิสิคัล

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

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

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

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

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

ใช้แบบสอบถามด้านล่างเพื่อตรวจสอบว่ามีพื้นที่ว่างในฐานข้อมูลเท่าใด

SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
FROM sys.database_files;

— Shanky
แหล่งที่มา

6

นอกเหนือจากคำตอบของ Tom และ Shanky หากฐานข้อมูลของคุณมีข้อมูล LOB / BLOB แล้ว DBCC SHRINKFILE อาจไม่ทำงาน หากเป็นกรณีนี้คุณมีสองตัวเลือกขึ้นอยู่กับว่าคุณสามารถออฟไลน์ฐานข้อมูลหรือไม่ หากคุณสามารถใช้ฐานข้อมูลออฟไลน์ได้คุณจะต้องคัดลอกข้อมูลออกและคัดลอกกลับเข้ามาเพื่อลบพื้นที่ว่าง คุณสามารถทำได้โดยหนึ่งในสิ่งต่อไปนี้:

ใช้คำสั่งSELECT INTOเพื่อโอนทั้งตารางไปยังตารางใหม่ วางตารางเดิมเรียกDBCC SHRINKFILE เปลี่ยนชื่อตารางใหม่เป็นชื่อตารางดั้งเดิม
ใช้ bcp เพื่อคัดลอกตารางในโหมดเนทิฟวางตารางเรียกใช้DBCC SHRINKFILEสร้างตารางจากนั้น bcp ข้อมูลลงในตาราง
ใช้การส่งออก / นำเข้าเพื่อย้ายข้อมูลทั้งหมดไปยังฐานข้อมูลใหม่ลดลงฐานข้อมูลที่มีอยู่เปลี่ยนชื่อฐานข้อมูลใหม่เป็นชื่อฐานข้อมูลต้นฉบับ

ถ้าคุณไม่สามารถออฟไลน์ฐานข้อมูลได้คุณสามารถใช้คำสั่งSHRINKFILE DBCCกับตัวเลือกEMPTYFILE

รายละเอียดสำหรับการคัดลอกออฟไลน์: http://support.microsoft.com/kb/324432/en-us

ข้อมูลปัจจุบันสำหรับตัวเลือก EMPTYFILE http://msdn.microsoft.com/en-us/library/ms189493(v=sql.105).aspx

— stacylaray
แหล่งที่มา