Hiệu suất truy vấn suy giảm theo thời gian và sử dụng

Tôi đã chiến đấu với một vấn đề trong vài tuần nay khi hiệu năng của các truy vấn SQL Server của tôi giảm xuống sau vài ngày sử dụng. Ngoài ra, cứ sau vài ngày, một truy vấn sẽ không trả về từ SQLExecute()cuộc gọi ODBC của ứng dụng của tôi .

Xây dựng lại các chỉ mục theo cách thủ công (trong SQL Server Management Studio) "sửa" cả hai vấn đề.

Đây là một số thông tin thêm;

DB có kích thước ~ 13 Gig
Sử dụng ODBC ver 3.5.1 trong ứng dụng
Các ứng dụng là C ++ với giao diện ODBC cho SQL DB
Trường hợp thử nghiệm nằm trên một DB tĩnh - không có chèn, do đó không thể phân mảnh!
Các truy vấn nhỏ ban đầu ít hơn 1 giây và giảm xuống còn hơn 50 giây
Đã thấy sự cố trên tất cả (3) máy đang chạy

Tôi đang có một thời gian khó hiểu tại sao cùng một truy vấn hoạt động tốt trong một thời gian, nhưng sau đó bắt đầu làm chậm waaay ??

bất kì ý kiến nào đều được đánh giá cao.

performance sql-server-2005 index

— người dùng1825436
nguồn

Tôi đã đưa ra một câu trả lời với một vài hướng để đi xuống nhưng thêm một vài chi tiết vào câu hỏi sẽ giúp ích: 1.) Có bao nhiêu hàng trong (các) bảng liên quan đến các truy vấn chậm? 2.) Có bao nhiêu chèn vào bảng (s)? 3.) Máy chủ này có bao nhiêu bộ nhớ và nó có dành riêng cho SQL không? 4.) Đĩa của bạn trông như thế nào? Chuyên dụng? Những loại thông số kỹ thuật? 5.) Điều gì xảy ra nếu bạn tự chạy cùng một truy vấn đó trong SQL Server Management Studio khi nó chậm?

— Mike Walsh

Cảm ơn những gợi ý tuyệt vời dưới đây. Dưới đây là một số thông tin nhiều hơn nữa.

— dùng1825436

1) 15 triệu hàng 2) 11k chèn mỗi ngày 3) 24GB trên máy chủ, Không dành riêng cho SQL - chỉ có 2GB được đặt cho bộ nhớ tối đa. 4) Tôi không có sẵn thông tin này. 5) Tôi đã thử điều đó - nó chạy tốt trong SQL Mgr trong khi ứng dụng chậm. Ngoài ra, bắt đầu một ứng dụng thử nghiệm với cùng một truy vấn sẽ chạy chậm. Tái bút - Tôi không phải là một DBA, vì vậy xin miễn cho sự thiếu hiểu biết của tôi ...

— user1825436

Vì vậy, dựa trên câu trả lời của bạn cho số 5 - chạy tốt trong SSMS ngay cả khi ứng dụng chạy chậm trong ứng dụng cho tôi biết đó có thể là sự kết hợp của câu trả lời tôi đã đăng trong vấn đề "Kế hoạch truy vấn" và "Quá nhiều kế hoạch adhoc". Đây có phải là nhiều truy vấn này xảy ra trên hoặc chỉ một vài?

— Mike Walsh

Cập nhật I - Chúng tôi đã sửa đổi các truy vấn trong câu hỏi chỉ để đánh hơi tham số lá. Các biến cục bộ đã được khai báo cho từng tham số trong truy vấn (không có gì thay đổi nữa). Kể từ thời điểm đó, mọi thứ đã hoạt động khá tốt trong 1 tuần. Quá sớm để tuyên bố chiến thắng, nhưng tôi nghĩ đây là một cơ hội tốt. Tôi sẽ cập nhật lại sau khi có thêm thời gian và thông tin có sẵn.

— dùng1825436

Câu trả lời:

Các truy vấn có thể bắt đầu chậm lại theo thời gian vì một vài lý do và bạn xây dựng lại các chỉ mục có thể khắc phục vấn đề theo một số cách. Tôi sẽ chia sẻ một số lý do phổ biến hơn trong kinh nghiệm của mình nhưng cũng có thể có những nguyên nhân khác. Tôi đoán là bạn đang mắc phải một trong những vấn đề này .. Tôi cũng đã hỏi một số câu hỏi dưới dạng nhận xét cho câu hỏi của bạn để xem liệu chúng tôi có thể biết thêm chi tiết không. Nhưng một vài suy nghĩ:

Thống kê Bắt máy chủ SQL cũ duy trì thống kê cột và chỉ mục. Những điều này về cơ bản cho Trình tối ưu hóa truy vấn cách dữ liệu của bạn được phân phối. Thông tin này rất quan trọng đối với trình tối ưu hóa trong việc chọn phương thức truy cập dữ liệu phù hợp (Seek vs Scan) và sau đó chọn phương thức nối đang được sử dụng. Nếu bạn đã bật thống kê cập nhật tự động (cài đặt mặc định trong SQL .. Ở cấp độ cơ sở dữ liệu), chúng sẽ được tính toán lại, nhưng chỉ khi dữ liệu "đủ" thay đổi. Vì vậy, nếu bạn có một số chèn vào bảng của mình nhưng không bao giờ cập nhật thống kê theo cách thủ công và các chèn / cập nhật không đủ để kích hoạt cập nhật thống kê tự động, bạn có thể phải chịu các kế hoạch kém cho phân phối dữ liệu của mình ... Việc xây dựng lại chỉ mục của bạn cũng tính toán lại thống kê chỉ mục của bạn Tôi sẽ tạo một công việc để cập nhật thủ công các số liệu thống kê một cách thường xuyên, dù sao đây cũng là một cách tốt nhất - và lần sau điều này xảy ra hãy thử và chạy sp_updatestatstrong cơ sở dữ liệu của bạn và xem bạn có nhận thấy sự khác biệt không

Các vấn đề về kế hoạch truy vấn Bạn có thể bị đánh hơi tham số - về cơ bản lần đầu tiên một truy vấn chạy một giá trị được truyền vào - truy vấn được tối ưu hóa cho giá trị đó. Khi bạn tiếp theo chạy nó với một giá trị khác sẽ được hưởng lợi từ một gói truy vấn khác, nó sẽ chịu đựng với kế hoạch truy vấn ban đầu dẫn đến một truy vấn chậm. Khi mọi thứ chạy chậm cho ứng dụng - chúng cũng chậm nếu bạn chạy cùng một truy vấn trong SQL Server Management Studio? Nếu nó nhanh trong SSMS nhưng chậm trong ứng dụng - đó có thể là một dấu hiệu tốt chỉ về việc đánh hơi tham số. Nếu nó luôn chậm trên bảng theo thời gian cho tất cả các truy vấn và bất kể tham số nào, thì tôi sẽ không nhìn vào đây. Bài viết này nói khá nhiều về việc đánh hơi tham số.

Không đủ bộ nhớ / quá nhiều kế hoạch ad hoc Có vẻ như bạn đang gửi ad hoc SQL đến SQL Server. Điều này đôi khi có thể làm bộ nhớ cache kế hoạch của bạn, đặc biệt nếu bạn có một gói riêng cho mỗi lần thực hiện truy vấn. Tùy thuộc vào bộ nhớ trên máy chủ của bạn, điều này cũng có thể dẫn đến sự cố. Có bao nhiêu bộ nhớ trên máy chủ của bạn? Kiểm tra liên kết này về vấn đề với các kế hoạch sử dụng duy nhất. Bạn không có nhiều giải pháp tuyệt vời trong SQL Server 2005 cho vấn đề này, nếu bạn có nó. Nếu bạn có thể tạo lại vấn đề này trong môi trường không prod, tôi khuyên bạn nên chạy DBCC FREEPROCCACHEtrong môi trường không prod nếu điều này xảy ra lần nữa. Xin lưu ý! Đây là một cài đặt rộng đối tượng, nếu bạn thực hiện điều này trong sản xuất - mọi kế hoạch truy vấn được lưu trữ trong bộ đệm cho bất kỳ cơ sở dữ liệu nào sẽ không còn ở đó nữa. Nó có nghĩa là bạn phải "trả tiền" cho các phần tổng hợp một lần nữa. Nếu bạn có tính đồng thời cao và một hệ thống bận rộn, điều này có thể gây ra sự cố. Nếu đây là cơ sở dữ liệu thực sự duy nhất và dù sao bạn cũng gặp vấn đề về hiệu năng, thì việc thử sản xuất này sẽ không hại gì. Nếu bạn có Cơ sở dữ liệu khác và chỉ muốn làm điều đó cho cơ sở dữ liệu này, bài đăng trên blog này giải thích cách tiếp cận rõ ràng cho chỉ một DB.

Phân mảnh chỉ mục - Có thể phân mảnh chỉ mục là vấn đề thực tế ở đây, nhưng tôi ngạc nhiên rằng nó trở nên rất tệ. Nếu các bảng của bạn được nhóm trên một khóa gây ra sự phân mảnh nhanh chóng và bạn có rất nhiều phần chèn, đây có thể là trường hợp. Nó sẽ trở nên tồi tệ hơn nhiều nếu bạn bị thiếu sức mạnh về bộ nhớ và đĩa IO. Thiết lập một công việc để xây dựng lại / sắp xếp lại các chỉ mục của bạn một cách thường xuyên sẽ tốt. Dựa trên câu trả lời của bạn cho một số câu hỏi trong các ý kiến trên có thể có những việc khác cần làm để giảm thiểu tác động của việc này.

— Mike Walsh
nguồn

+1 Tôi cũng cung cấp các lựa chọn thay thế để thử, ví dụ như cài đặt máy chủ Optimize for ad hoc workloadsvà cài đặt cơ sở dữ liệu parameterization forced.

— Aaron Bertrand

Tôi không đề xuất Tối ưu hóa cho khối lượng công việc đặc biệt vì chúng có trên SQL Server 2005 và đã đề cập đến điều đó trong câu trả lời. Cuộc gọi tốt về tham số bắt buộc, mặc dù.

— Mike Walsh

À đúng rồi, đã bỏ lỡ thẻ sql-server-2005. Vẫn hy vọng những tùy chọn đó hữu ích cho những độc giả tương lai gặp phải vấn đề này trên các phiên bản hiện đại của SQL Server. :-)

— Aaron Bertrand

+1 Tôi đồng ý :-) Và có lẽ đó là mồi nhử cho OP để xem xét hướng tới năm 2008 hoặc 2012 ;-)

— Mike Walsh

Có - chúng tôi chắc chắn đã xem xét cập nhật lên phiên bản SQL hiện đại, nhưng chúng tôi có thể sẽ không thể làm điều đó cho đến khi chúng tôi có đường cơ sở ổn định trước.

— dùng1825436

Chúng tôi đã có cùng một vấn đề với một trong những cơ sở dữ liệu sản xuất của chúng tôi. Howerver một tình huống hơi khác nhau. Các bảng đã được đọc / ghi và chứa khoảng. Hơn 20 triệu hồ sơ.

Chúng tôi xây dựng lại các chỉ mục mỗi tuần (cuối tuần) giúp cho đến chiều thứ Hai và sau đó hiệu suất sẽ giảm, vì lượng dữ liệu khổng lồ.

Tùy thuộc vào kích thước của bảng của bạn, đó có thể là vấn đề về bộ nhớ trong đó máy chủ chỉ có một dung lượng nhất định có sẵn cho một lượng bộ bản ghi nhất định trong bộ đệm. (Tỷ lệ truy cập bộ đệm Cache thấp hơn 90%). Giải pháp: Thêm nhiều bộ nhớ hơn vào phiên bản SQL Server có thể giúp ích. Điều này có thể cải thiện Tỷ lệ Lượt truy cập Bộ đệm Bộ đệm lên trên 90%. Kết quả là dữ liệu được lấy từ bộ nhớ chứ không phải từ các ổ đĩa vật lý.

Nếu đó là do công cụ cơ sở dữ liệu SQL đang "tối ưu hóa" các truy vấn nhằm lấy dữ liệu, thì đó có thể là một vấn đề thống kê chỉ mục. (Đây là vấn đề với bảng lớn của chúng tôi). Các giáo phái trở nên lỗi thời. Giải pháp: Làm mới Thống kê Chỉ số hàng ngày cho bảng này có thể giải quyết các vấn đề của bạn.

Xem như vấn đề của bạn là một vấn đề ngắn hạn, tôi đoán đó là vấn đề Tỷ lệ trúng bộ đệm Cache (bộ nhớ SQL quá ít). Trình tối ưu hóa truy vấn SQL sẽ xóa các bộ bản ghi nhỏ khỏi meomry để chứa dữ liệu thường xuyên được truy xuất.

— John aka hot2use
nguồn

Cảm ơn, phản hồi này cũng rất hữu ích. Chúng tôi cũng có một cái bàn rất lớn đang được truy vấn, 15 triệu hoặc hơn thế. Tôi đã không xem xét phân bổ thêm RAM cho máy chủ SQL, nhưng chắc chắn sẽ thử ngay bây giờ. Ngoài ra, làm mới các số liệu thống kê là điều tôi sẽ làm trong lần tới khi chúng ta ở trạng thái này và xem điều đó có giải quyết được không.

— dùng1825436

Một vài điều đến với tâm trí.

Các đối tượng kết nối ODBC có bị đóng và xóa ở cuối mỗi truy vấn không? Nếu không, nhóm kết nối sẽ tiếp tục phát triển.
Có bất kỳ chỉ số thiếu? Các quan điểm quản lý năng động sẽ cho bạn biết những gì đang xảy ra ở đó.

1) Không, chúng tôi sẽ duy trì một kết nối ODBC trong suốt thời gian tồn tại của ứng dụng. Các con trỏ Statement được đóng lại sau mỗi truy vấn. Có điều gì tôi đang thiếu với phương pháp này? Tôi sẽ xem xét bất kỳ và tất cả các khả năng tại thời điểm này. 2) Tôi sẽ xem xét các chỉ số còn thiếu, cảm ơn.

— dùng1825436