Máy SQL Server 2005 giống hệt (?); truy vấn mất 2 giây trên một, 15 phút khác

Môi trường:

Chúng tôi có hai máy Windows Server 2003 R2 32 bit chạy SQL Server 2005. Cấu hình phần cứng là các máy chủ giống hệt nhau với CPU Xeon 5160, RAM 4GB và RAID0 13GB. Cờ AWE và / 3GB không được bật.

Các máy chủ được thiết lập cạnh nhau bằng cách sử dụng danh sách kiểm tra cài đặt được xác định trước và TẤT CẢ phần mềm được cài đặt giống nhau trên cả hai máy.

Mỗi cài đặt cài đặt máy chủ SQL và mức vá lỗi mà chúng tôi biết để kiểm tra là giống hệt nhau. Một điểm khác biệt là TEMPDB là 400 MB trên máy nhanh và 1,2 GB trên máy chậm. Tuy nhiên, trong cả hai trường hợp, chúng tôi không thấy bất kỳ phân bổ TEMPDB nào đang diễn ra.

Vấn đề:

Có một thủ tục được lưu trữ chạy trong 2 giây trên một, nhưng 15 phút khác. Trong 15 phút bổ sung, có rất ít hoặc không có hoạt động của đĩa, không có thay đổi sử dụng bộ nhớ, nhưng một lõi CPU được ghim 100% toàn bộ thời gian.

Hành vi này vẫn tồn tại ngay cả khi cơ sở dữ liệu được sao lưu từ cái này và được khôi phục lại cái kia.

Vì nó là một thủ tục được lưu trữ, trình giám sát hoạt động và trình lược tả không hiển thị cho chúng tôi bất kỳ chi tiết nào về nơi trong quy trình được lưu trữ, hoạt động CPU cao này đang diễn ra.

Câu hỏi:

Những gì khác chúng ta nên xem xét?

Theo sát:

Sự chậm chạp xảy ra trong các câu lệnh FETCH NEXT cho định nghĩa con trỏ sau:

DECLARE C CURSOR FOR
    SELECT X, Y
    FROM dbo.A
    WHERE X NOT IN (SELECT X FROM dbo.B)
    AND Z <=0
...
<snip>
...
FETCH NEXT FROM C INTO @X, @Y
FETCH NEXT FROM C INTO @X, @Y
...

Mỗi câu lệnh FETCH - trên một bảng chỉ chứa khoảng 1000 hàng - yêu cầu khoảng 7,25 phút. (Không, tôi không biết tại sao nó làm hai liên tiếp, cần phải hỏi các nhà phát triển, nhưng nó chạy đúng trên cả hai máy chủ).

Tôi hơi nghi ngờ về điều đó "KHÔNG VÀO (CHỌN ...)", vì có vẻ như Số lần đọc ảo thực sự rất cao.

Sử dụng phương pháp khắc phục sự cố hiệu năng như Chờ đợi và Hàng đợi xác định lý do tiêu thụ CPU cao, sau đó có thể khuyến nghị hành động thích hợp sau khi nút cổ chai được xác định.

SQL Server đang chọn một gói khác trên hộp khác.

Khôi phục thường sẽ loại bỏ các vấn đề dựa trên số liệu thống kê, vì vậy tôi sẽ xem xét sự khác biệt của máy chủ.

Một số kiểm tra thô trước. Đừng giả sử: kiểm tra

• Kiểm tra xem các cài đặt Máy chủ SQL có giống nhau trong sys.configuration không, ví dụ: Độ tối đa hoặc độ song song
• Chạy DBCC USEROPTIONS để xem liệu có bất kỳ cài đặt ANSI nào khác nhau trong thời gian chạy không (cài đặt ANS có thể ảnh hưởng đến gói đã chọn)
• Kiểm tra nhật ký Windows và SQL Server để xem có vấn đề gì không

Sau đó nhảy vào cuối sâu, theo câu trả lời của Remus.

Nếu tất cả những thứ khác đều bằng nhau, có thể (theo câu trả lời của @ gbn) rằng một kế hoạch thực hiện khác nhau đang được tạo trên mỗi máy chủ. Là một bài tập học thuật, sẽ rất thú vị khi xem cả hai kế hoạch, vì vậy hãy lấy chúng từ bộ đệm kế hoạch trên mỗi máy chủ và thêm chúng vào câu hỏi của bạn nếu có thể. Sau đó chúng ta có thể xác định sự khác biệt trong các kế hoạch gây ra sự thay đổi lớn trong hiệu suất.

Để khắc phục nhanh, hãy xem gợi ý SỬ DỤNG KẾ HOẠCH . Điều này cho phép đính kèm kế hoạch tốt từ máy chủ nhanh, vào quy trình được lưu trữ trên máy chủ chậm.

Chỉnh sửa: Theo dõi cập nhật lại: con trỏ

Một biến thể khác trong truy vấn của bạn để thử mà tôi không thấy được đề cập trong các câu trả lời khác:

DECLARE C CURSOR FOR
    SELECT X, Y
    FROM dbo.A
    WHERE NOT EXISTS (SELECT 1 FROM dbo.B WHERE dbo.B.X = dbo.A.X)
    AND Z <=0
...
<snip>
...
FETCH NEXT FROM C INTO @X, @Y
FETCH NEXT FROM C INTO @X, @Y

Hài hước cho tôi, và thử thay thế:

DECLARE C CURSOR FOR
SELECT X, Y
FROM dbo.A
WHERE X NOT IN (SELECT X FROM dbo.B)
AND Z <=0

Với cái này:

DECLARE C CURSOR FOR
SELECT 
    X, 
    Y
FROM dbo.A

    LEFT OUTER JOIN dbo.B
        ON dbo.A.X = dbo.b.X

WHERE dbo.B.X IS NULL
AND Z <=0

Tôi không nghĩ rằng điều này sẽ biểu hiện như là một vấn đề về hiệu suất trong phần TIẾP THEO TIẾP THEO của mã của bạn, nhưng tôi chưa tiêm caffeine. Hãy cho tôi đề nghị thử, và cho tôi biết.

Hi vọng điêu nay co ich,

Matt

Kiểm tra chỉ mục của bạn và cập nhật tất cả các số liệu thống kê của bạn. Tôi đã có một vấn đề rất giả lập và hóa ra các số liệu thống kê trên một máy là rất lớn.

Tôi đã trải qua hành vi tương tự hai lần và tôi sẽ cho bạn biết những gì đã khắc phục nó mỗi lần:

1.) Tôi đã thêm gợi ý VỚI RECOMPILE vào thủ tục được lưu trữ vì kế hoạch lưu trữ rất tệ.

2.) Tôi đã thay đổi thủ tục được lưu trữ để sử dụng các bảng tạm thời thay vì các biến bảng.

Tôi hy vọng một trong những sự giúp đỡ đó. Chúc may mắn.