DBCC Shrinkfile ลักษณะการทำงานที่แปลก

ฉันพยายามเรียกใช้ dbcc shrinkfile ในหน่วยความจำ 1GB เทียบกับฐานข้อมูลที่ 95% ของข้อมูลถูกเก็บถาวรและลบ ฉันเลื่อนไฟล์ 235GB โดยที่ 9GB เป็นข้อมูล / ดัชนี ฉันต้องการลดขนาดลงเหลือ 50GB ฉันรู้ว่าไฟล์ฐานข้อมูลที่ลดขนาดไม่ดีก็ทำให้เกิดการแตกหัก ฯลฯ เป็นส่วนหนึ่งของการล้างข้อมูล / หดตัวเรายังมีสคริปต์ idnex สร้างใหม่

เมื่อฉันรันสคริปต์ dbcc shrinkfile กับฐานข้อมูลบนเวิร์กสเตชันของฉันเอง (quad core, RAM 12GB, ไดรฟ์ SATA 2 เท่า) การลดขนาดใช้เวลาประมาณ 8-10 นาที

เมื่อรันโค้ดที่เหมือนกันกับสำเนาที่เหมือนกันของการล้างข้อมูลที่ทำการโพสต์ฐานข้อมูลใน envrionment การทดสอบของเรา (80+ คอร์, 128GB RAM, SSD SAN) ใช้เวลา 70 นาที หากต้องการทราบว่ามีกิจกรรมเล็ก ๆ บนเซิร์ฟเวอร์นี้ในเวลาที่ไฟล์ย่อขนาดทำงานอยู่ มีการเรียกใช้ 4 ครั้งด้วยผลลัพธ์ที่เหมือนกัน

จากนั้นฉันก็ใช้วิธีอื่นในการย้าย 9GB ที่เหลือไปยังกลุ่มไฟล์และฟิสิคัลไฟล์อื่น การรัน dbcc shrinkfile บนไฟล์ 230GB ที่ว่างเปล่าเพื่อลดขนาดลงเหลือ 50GB บนเวิร์กสเตชันของฉันเองใช้เวลา <1 นาที

ด้วยวิธีการเดียวกันนี้บนสภาพแวดล้อมการทดสอบใช้เวลามากกว่า 70 นาที

ฉันถ่ายภาพสต็อกก่อนหน้าและหลังตามสคริปต์ของ Brent Ozar ในช่วง 70 นาทีในการทดสอบสภาพแวดล้อมและ waittypes กลับแสดงให้เห็นว่าไม่มีความกังวลใด ๆ แถวบนสุด 3 แถวด้านล่าง:

ตัวอย่างเวลาที่สองระยะเวลาตัวอย่างในหน่วยวินาที wait_type เวลารอ (วินาที) จำนวนการรอมิลลิวินาทีเฉลี่ยต่อการรอคอย
2013-05-28 11: 24: 22.893 3600 WRITELOG 160.8 143066 1.1
2013-05-28 11: 24: 22.893 3600 CXPACKET 20.9 13915 1.5
2013-05-28 11: 24: 22.893 3600 PAGELATCH_EX 11.1 443038 0.0

บันทึกเหตุการณ์ Windows แสดงว่าไม่มีอะไรผิดปกติ ฉันกำลังจะเกาที่จุดนี้ทำไมมันใช้เวลานานมากกับฮาร์ดแวร์นินจาเมื่อเทียบกับเวิร์กสเตชันแบบสแตนด์อโลนของฉัน

Shrinkfile บน datafile เป็นการดำเนินการแบบเธรดเดียวการใช้บัฟเฟอร์หน่วยความจำขนาดเล็กอีกครั้ง

ดังนั้นฮาร์ดแวร์ของนินจาจึงไม่ได้รับความได้เปรียบจากหน่วยความจำเสริมและ 80 คอร์

พีซีในพื้นที่ของคุณมีข้อดีของเวลาแฝง I / O ภายในเครื่อง (โลคัลดิสก์คือไม่ต้องเดินทางหลายครั้งไปที่ SAN)