2012-01-30 32 views
5

Tôi có một bảng CurrentStatus trong cơ sở dữ liệu của tôi (cơ sở dữ liệu thuê bao trong một bản sao merge) Cột là StatusID {Primary Key + Clustered Index}, StatusName, StatusDate, UserID,CreatedDate, ModifiedDate, ModifiedBy, AllowDelete,AllowUpdateSimple truy vấn cập nhật được dùng quá lâu

CurrentStatus bảng như 26000 hàng

cập nhật và xóa trên bảng này là đột nhiên mất quá nhiều thời gian nói 1 phút 30 giây đến 5 phút.

Truy vấn bên dưới sẽ mất hơn một phút để thực thi.

update StatusMaster set StatusName='OK' where StatusID = 22 

Có trước đây 5 chỉ số trên bảng (thậm chí sau đó truy vấn sử dụng để thực hiện nhanh chóng.) Bây giờ là cập nhật/xóa các truy vấn không được thực hiện, tôi đã xóa tất cả các chỉ số và chỉ giữ lại hai chỉ số 1) Chỉ mục được nhóm trên StatusID 2) Chỉ mục sao chép trên cột rowguid là một chỉ mục nonclustered duy nhất được tạo ra bởi bản sao tự động.

Tôi sẽ sao lưu và khôi phục cơ sở dữ liệu, các truy vấn trên cùng một bảng chạy tốt.

Một điều nữa là tôi có truy vấn phức tạp chạy mỗi 2 phút từ khoảng 20 máy trên máy chủ.

Điều gì khiến cho các truy vấn này tốn quá nhiều thời gian để thực thi?

Click here for Execution plan

+0

là bản sao đang chạy khi bạn thực hiện các thử nghiệm này? Nếu DB là người đăng ký, bạn thực sự không nên xóa \ đang cập nhật dữ liệu của nó, phải không? – Diego

+0

Vui lòng không đăng trong TẤT CẢ CAPS. Đó là thô lỗ, và có vẻ như bạn đang "la hét". –

+1

@Diego có sao chép đang chạy + sao chép hợp nhất của nó để chèn cập nhật có thể hoạt động trên bất kỳ người đăng ký và nhà xuất bản – Thakur

Trả lời

6

tôi khuyên bạn nên cập nhật thống kê của bạn thông qua lệnh UPDATE STATISTICS, ví dụ:

UPDATE STATISTICS StatusMaster 
+0

đã giúp giảm thời gian thực hiện nhưng vẫn mất 20 giây lẻ – Thakur

+0

đôi khi mất 1 giây và đôi khi trên 15 giây, mức tiêu thụ bộ nhớ trên máy chủ là 2,5 gb trong số 4 gb và sử dụng bộ vi xử lý là 45% – Thakur

+0

Có thể cột 'StatusID' có số lượng cardinality thấp để nó thực hiện quét bảng. Kế hoạch thực hiện của bạn nói gì? – RedFilter

2

Sau rất nhiều chèn, xóa, cập nhật, vv, bạn có thể nhận được bảng phân mảnh và bạn chỉ mục có thể không được tối ưu hóa. Tôi khuyên bạn nên lập chỉ mục lại và cập nhật số liệu thống kê.

Khi bạn thực hiện sao lưu và khôi phục, tôi tin rằng bạn đang thực hiện điều tương tự như việc lập chỉ mục lại và cập nhật thống kê sẽ thực hiện.

Bạn có lẽ nên lên lịch bảo trì như thế này định kỳ để duy trì hiệu suất.

+0

tôi đã xây dựng lại các chỉ mục và cập nhật số liệu thống kê, nhưng vẫn gặp phải vấn đề – Thakur

0

Lần cuối cùng khi một số truy vấn đơn giản mất thời gian bất thường [trong công ty nhỏ của chúng tôi], điều này là do tham nhũng mảng RAID trong máy chủ SQL [may mắn không sản xuất].

+0

làm thế nào tôi có thể tìm thấy mảng RAID của tôi bị hỏng? – Thakur

+0

Hỏi người, người quản lý máy tính đó, nơi có máy chủ SQL. Bạn cần kiểm tra các bản ghi sự kiện của cửa sổ và nếu có, các nhật ký trạng thái bộ điều khiển RAID. Tôi không nói rằng đây là trường hợp của bạn - Tôi không có kinh nghiệm với nhân rộng và không thể nói, những gì có hiệu lực này có thể gây ra; Tôi chỉ gợi ý rằng đôi khi sự chậm trễ kỳ lạ là do vấn đề phần cứng. – Arvo

+0

Khi bảng này được nhân rộng, và tôi nhận được lỗi trên 4 đến 5 máy chủ tôi không nghĩ rằng nó sẽ là một vấn đề RAID – Thakur

Các vấn đề liên quan