ทำไมสถานะ“ DbccFilesCompact” จึงถูก“ หยุด”

ฉันกำลังเรียกใช้ไฟล์ SHRINK ในไฟล์ข้อมูล 600G

ขณะนี้สถานะจะรายงานว่า "ถูกระงับ" และsys.dm_exec_requests.percent_completeสำหรับDbccFilesCompactคำสั่งรายงานว่ากำลังทำงาน (แต่ช้ามาก)

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

FYI - SQL Query สำหรับการตรวจสอบสถานะ

select T.text, R.Status, R.Command, DatabaseName = db_name(R.database_id)
       , R.cpu_time, R.total_elapsed_time, R.percent_complete
from   sys.dm_exec_requests R
       cross apply sys.dm_exec_sql_text(R.sql_handle) T
order by Command

ไม่คุณไม่สามารถตรวจสอบสาเหตุที่ทำงานช้า แต่ฉันสามารถให้คำแนะนำ:

1) ใน SQL 2005 การจัดการของดัชนีที่ไม่ได้ทำคลัสเตอร์เปลี่ยนจาก Storage Engine (ทีมของฉัน) เป็น Query Processor สิ่งนี้มีผลข้างเคียงมากมายซึ่งหนึ่งในนั้นก็คือความเร็วที่สามารถย้ายหน้าข้อมูลกองได้โดยการย่อขนาด เร็กคอร์ดดัชนีที่ไม่ใช่คลัสเตอร์ทั้งหมดมีลิงก์ย้อนกลับไปยังเร็กคอร์ดข้อมูลที่มีการทำดัชนี - ในกรณีของฮีปนี่คือลิงค์ฟิสิคัลไปยังหมายเลขเร็กคอร์ดในหน้าข้อมูลเฉพาะ เมื่อเพจข้อมูลฮีปถูกย้ายโดยย่อขนาดเร็กคอร์ดดัชนีที่ไม่ใช่คลัสเตอร์ทั้งหมดที่ลิงก์ย้อนกลับไปยังเร็กคอร์ดบนเพจนั้นต้องถูกอัพเดตด้วยตำแหน่งใหม่ของเพจ ในปี 2000 สิ่งนี้ถูกทำขึ้นอย่างมีประสิทธิภาพโดย Storage Engine เอง ในปี 2005 เป็นต้นไปสิ่งนี้จะต้องทำโดยเรียกตัวประมวลผลคิวรีเพื่ออัพเดตเรกคอร์ดดัชนีที่ไม่ได้เป็นคลัสเตอร์ บางครั้งนี่อาจช้ากว่า 100 เท่าในปี 2000

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

3) อาจมีกระบวนการอื่นที่ใช้ฐานข้อมูลที่ทำให้การย่อขนาดเพื่อบล็อกรอการล็อกที่ต้องการย้ายหน้า

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

5) ระบบย่อย I / O ของคุณอาจถูก underpowered ความยาวคิวดิสก์ที่สูงกว่าตัวเลขเดี่ยวต่ำหมายถึงระบบย่อย I / O ของคุณในคอขวด

สิ่งเหล่านี้หรือทั้งหมดอาจช่วยชะลอเวลาการหดตัว

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

หวังว่านี่จะช่วยได้!

คุณสามารถเรียกใช้สคริปต์นี้เพื่อตรวจสอบเปอร์เซ็นต์เสร็จสมบูรณ์!

SELECT 
    percent_complete, 
    start_time, 
    status, 
    command, 
    estimated_completion_time, 
    cpu_time, 
    total_elapsed_time
    --,*
FROM 
    sys.dm_exec_requests
WHERE
    command = 'DbccFilesCompact'

ฉันลดขนาดฐานข้อมูลใน SQL Server 2008 SP1 และวิธีหนึ่งที่ฉันสามารถบอกความคืบหน้าของคำสั่งย่อขนาดได้คือการดำเนินการ sp_lock spid และส่วนใหญ่ฉันจะเห็นว่ามันทำให้การล็อคไฟล์ 1 แล้วเมื่อมันทำ ล็อกไฟล์ id 2 และอื่น ๆ ด้วยวิธีนี้ฉันสามารถบอกได้เมื่อมันทำงานกับ id ไฟล์ล่าสุดและนี่คือข้อบ่งชี้ของฉันที่เกือบจะเสร็จสมบูรณ์

ขอบคุณ

อเล็กซ์อากีลาร์

ฉันค้นพบสิ่งที่เป็นปัญหา (ในกรณีของฉัน) และฉันเสนอวิธีแก้ปัญหาที่ฉันใช้ที่นี่

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

ดังนั้นฉันจึงตัดสินใจใช้ command line โดยใช้:

DBCC SHRINKDATABASE (myDataBase)

(แม่มดมีเอกสารอยู่ทุกหนทุกแห่ง) จากนั้นการย่อตัวใช้เวลาเพียงไม่กี่วินาที