Làm thế nào tôi có thể nói TẠI SAO một chèn trên một bảng nhất định là chậm?

Tôi biết rằng một INSERT trên bảng SQL có thể bị chậm vì bất kỳ lý do nào:

• Sự tồn tại của TRIGGER trên bảng
• Rất nhiều ràng buộc bắt buộc phải được kiểm tra (thường là khóa ngoại)
• Chia trang trong chỉ mục được nhóm khi một hàng được chèn vào giữa bảng
• Cập nhật tất cả các chỉ mục không phân cụm
• Chặn từ hoạt động khác trên bàn
• Thời gian phản hồi viết IO kém
• ... bất cứ điều gì tôi bỏ lỡ?

Làm thế nào tôi có thể biết ai chịu trách nhiệm trong trường hợp cụ thể của tôi? Làm cách nào tôi có thể đo lường tác động của việc chia trang so với cập nhật chỉ mục không được nhóm so với mọi thứ khác?

Tôi có một Proc được lưu trữ chèn khoảng 10.000 hàng cùng một lúc (từ bảng tạm thời), mất khoảng 90 giây cho mỗi 10k hàng. Điều đó chậm đến mức không thể chấp nhận được, vì nó khiến các spids khác hết thời gian.

Tôi đã xem xét kế hoạch thực hiện và tôi thấy nhiệm vụ INDEX CLUSTERED INDEX và tất cả các TÌM KIẾM INDEX từ các tra cứu FK, nhưng nó vẫn không cho tôi biết tại sao phải mất nhiều thời gian như vậy. Không có kích hoạt, nhưng bảng có một số FKeys (dường như được lập chỉ mục đúng).

Đây là cơ sở dữ liệu SQL 2000.

Một số điều bạn có thể nhìn vào ...

Giảm kích thước lô từ 10000 xuống một cái gì đó nhỏ hơn, như 2000 hoặc 1000 (bạn không nói kích thước hàng của bạn lớn như thế nào).

Hãy thử bật Chỉ số IO để xem chỉ số IO mà các tra cứu FK đang sử dụng.

Chờ đợi gây ra là gì khi chèn nó xảy ra (master.dbo.sys Processes)?

Hãy bắt đầu ở đây và xem chúng ta đi đâu.

Brad,

Bạn nên kiểm tra số liệu thống kê chờ cho truy vấn của bạn. Với SQL2000, bạn có thể sử dụng cú pháp DBCC SQLPERF ("Waitstats") để có được các chi tiết đó.

Tôi có thể nói những gì tôi đang tìm kiếm khi phân tích hiệu suất của một truy vấn. Có lẽ nó giúp.

• phân tích kế hoạch thực hiện truy vấn và kiểm tra quét chỉ mục, quét bảng, sử dụng các hàm convert_implicit cho các kiểu dữ liệu sql, song song.
• chạy truy vấn với SET STATISTICS IO ON và SET STATISTICS TIME ON để xem thời gian thực hiện và đọc / ghi io cho mỗi lần chèn.
• kiểm tra thời gian chờ từ sys Processes cho phiên spid của bạn.
• chạy profiler và chọn mẫu chuẩn. chọn sau: Thống kê hiệu suất (nếu lặp lại thì kế hoạch của bạn được biên dịch nhiều lần - không tốt), RPC: đã hoàn thành, SQL: batchcompleted và SQL: batchstarting. Thêm vào đó cột rowcounts để xem chính xác số lượng hàng trong hàng loạt. Lọc kết quả để chỉ xem truy vấn của bạn.
• ở lần thu thập cuối cùng Bộ đếm tuổi thọ trang từ windows perfmon và nếu nó dưới 300 (5 phút) thì SQL có bộ nhớ thấp. Đồng thời thu thập các bộ đếm đĩa: chiều dài hàng đợi đĩa , Thời gian đĩa (ổ đĩa dữ liệu của bạn), Thời gian đĩa (ổ đĩa tệp nhật ký của bạn) để xem có áp lực lên đĩa không.

Hãy thử sử dụng:

SET STATISTICS IO ON

và

SET STATISTICS PROFILE ON

THỐNG KÊ IO

Có thể hữu ích trong việc cho bạn biết bảng nào đang thực hiện nhiều lần quét bảng nhất, đọc logic & đọc vật lý (tôi sử dụng ba bảng này để tập trung vào phần nào của kế hoạch truy vấn cần điều chỉnh nhất)

HỒ SƠ THỐNG KÊ

Chủ yếu sẽ trả về kế hoạch truy vấn theo định dạng bảng, sau đó bạn có thể xem các cột IO và CPU để biết chi phí nào nhiều nhất trong truy vấn (đó có phải là quét bảng trên bảng tạm thời của bạn so với sắp xếp để chèn vào khóa cụm, v.v ...)