Tôi đang cố gắng chạy một tệp thu nhỏ dbcc với số lượng 1GB dựa trên cơ sở dữ liệu trong đó 95% dữ liệu đã được lưu trữ và xóa. Tôi đang thất bại với một tệp 235GB trong đó 9GB là dữ liệu / chỉ mục. Tôi muốn thu nhỏ cái này xuống còn 50GB. Tôi biết rằng thu hẹp các tệp cơ sở dữ liệu là xấu, nó gây ra sự phân mảnh, v.v ... Là một phần của quá trình lọc / thu hẹp dữ liệu, chúng tôi cũng có một tập lệnh idnex được xây dựng lại.
Khi tôi chạy tập lệnh thu nhỏ dbcc dựa trên cơ sở dữ liệu trên máy trạm của riêng tôi (lõi tứ, RAM 12 GB, ổ đĩa 2 x SATA), quá trình thu nhỏ mất khoảng 8-10 phút.
Khi chạy mã giống hệt với một bản sao giống hệt của quá trình lọc dữ liệu bài cơ sở dữ liệu, trong phần thử nghiệm của chúng tôi, (hơn 80 lõi, RAM 128 GB, SSD SAN), phải mất 70 phút. Để lưu ý, có rất ít hoạt động trên máy chủ này tại thời điểm tệp thu nhỏ đang chạy. Nó đã được chạy 4 lần với kết quả giống hệt nhau.
Sau đó, tôi đã thực hiện một cách tiếp cận khác, về việc chuyển 9GB còn lại sang một tập tin và tập tin vật lý khác. Chạy dbcc cofile trên tệp 230GB trống để thu nhỏ xuống còn 50GB, trên máy trạm của riêng tôi mất <1 phút.
Với cách tiếp cận tương tự, trên môi trường thử nghiệm, một lần nữa phải mất hơn 70 phút.
Tôi đã chụp ảnh các nhân viên phục vụ trước và sau theo kịch bản của Brent Ozar trong suốt 70 phút chạy trên môi trường thử nghiệm, và các nhân viên phục vụ trở lại cho thấy không có gì để được hiểu. Top 3 hàng dưới đây:
Thời gian mẫu thứ hai Thời lượng mẫu trong giây Chờ đợi_type Thời gian chờ (giây) Số lần chờ Trung bình ms mỗi lần chờ 2013-05-28 11: 24: 22.893 3600 VIẾT 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
Nhật ký sự kiện Windows cho thấy không có gì bất thường. Tôi đang hướng đến việc cào vào thời điểm này, tại sao nó lại mất quá nhiều thời gian cho phần cứng ninja, so với máy trạm độc lập của tôi.
sys.dm_os_latch_stats
@@versiontrên cả hai