Các lệnh SQL Server để xóa bộ nhớ cache trước khi chạy so sánh hiệu năng

Khi so sánh thời gian thực hiện của hai truy vấn khác nhau, điều quan trọng là phải xóa bộ đệm để đảm bảo rằng việc thực hiện truy vấn đầu tiên không làm thay đổi hiệu suất của truy vấn thứ hai.

Trong Tìm kiếm của Google, tôi có thể tìm thấy các lệnh sau:

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

Trong thực tế, các truy vấn của tôi đang mất nhiều thời gian thực tế hơn để hoàn thành sau nhiều lần thực hiện so với trước đây. Tuy nhiên, tôi không chắc đây là kỹ thuật được khuyến nghị.

Thực hành tốt nhất là gì?

Cá nhân, đối với một truy vấn chung, lần thực hiện thứ 2 và tiếp theo quan trọng hơn.

Bạn đang kiểm tra IO đĩa hoặc hiệu năng truy vấn?

Giả sử truy vấn của bạn chạy thường xuyên và rất quan trọng, thì bạn muốn đo lường điều đó trong điều kiện thực tế. Và bạn không muốn xóa bộ đệm máy chủ prod mỗi lần ...

Nếu bạn muốn bạn có thể:

• DBCC DROPCLEANBUFFERSxóa sạch (chưa sửa đổi) các trang từ vùng đệm dữ liệu
  trước đó với một CHECKPOINTđể tuôn ra bất kỳ trang nào bẩn vào đĩa đầu tiên
• DBCC FLUSHPROCINDB xóa kế hoạch thực hiện cho cơ sở dữ liệu đó

Cũng xem (trên DBA.SE)

• Giải quyết thời gian tải trang cao bằng SQL Profiler

Trả lời muộn nhưng có thể được sử dụng cho các độc giả khác

DBCC DROPCLEANBUFFERS là một lệnh thường được sử dụng để kiểm tra truy vấn và đo tốc độ thực hiện truy vấn. Lệnh này (khi chạy) chỉ để lại các trang bẩn, đây thực sự là một phần nhỏ của dữ liệu. Nó loại bỏ tất cả các trang sạch cho toàn bộ máy chủ.

Hãy lưu ý rằng lệnh này không nên được chạy trên môi trường sản xuất. Chạy lệnh này sẽ dẫn đến bộ đệm bộ đệm trống hầu hết. Chạy bất kỳ truy vấn nào sau khi thực hiện lệnh DBCPC DROPCLEANBUFFERS, sẽ sử dụng các lần đọc vật lý để đưa dữ liệu trở lại vào bộ đệm, rất có thể sẽ chậm hơn rất nhiều so với bộ nhớ.

Một lần nữa, hãy đối xử với lệnh này tương tự như DBCC FREEPROCCACHE - nó không nên được chạy trên bất kỳ máy chủ sản xuất nào trừ khi bạn hoàn toàn biết bạn đang làm gì.

Đây có thể là một công cụ phát triển hữu ích vì bạn có thể chạy truy vấn trong môi trường kiểm tra hiệu năng nhiều lần mà không có bất kỳ thay đổi nào về tốc độ / hiệu quả do lưu trữ dữ liệu trong bộ nhớ.

Tìm hiểu thêm tại: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/

Tôi luôn được yêu cầu sử dụng:

dbcc dropcleanbuffers;

Từ MSDN :

Sử dụng DBCC DROPCLEANBUFFERS để kiểm tra các truy vấn với bộ đệm bộ đệm lạnh mà không tắt và khởi động lại máy chủ.

Để thả bộ đệm sạch khỏi vùng đệm, trước tiên, sử dụng CHECKPOINT để tạo bộ đệm bộ đệm lạnh. Điều này buộc tất cả các trang bẩn cho cơ sở dữ liệu hiện tại được ghi vào đĩa và dọn sạch bộ đệm. Sau khi bạn làm điều này, bạn có thể ban hành lệnh DBCC DROPCLEANBUFFERS để xóa tất cả bộ đệm khỏi nhóm bộ đệm.

Các câu trả lời khác là chính xác về lý do để không chạy DBCC FREEPROCCACHE. Tuy nhiên, cũng có một vài lý do để làm như vậy:

1. Tính nhất quán

Nếu bạn muốn so sánh hai truy vấn hoặc quy trình khác nhau đang cố gắng thực hiện cùng một cách theo những cách khác nhau, thì có khả năng chúng sẽ truy cập cùng một trang. Nếu bạn ngây thơ chạy truy vấn # 1 rồi truy vấn # 2, thì lần thứ hai có thể nhanh hơn nhiều chỉ vì các trang đó được lưu trữ bởi truy vấn đầu tiên. Nếu bạn xóa bộ đệm trước mỗi lần thực hiện, chúng sẽ bắt đầu ngay cả.

Nếu bạn muốn kiểm tra hiệu năng bộ đệm nóng, hãy nhớ chạy các truy vấn nhiều lần, xen kẽ và loại bỏ vài lần chạy đầu tiên. Trung bình kết quả.

2. Trường hợp xấu nhất

Giả sử bạn có một truy vấn mất một giây đối với bộ đệm nóng nhưng một phút đối với bộ đệm lạnh. Tối ưu hóa làm cho truy vấn trong bộ nhớ chậm hơn 20% nhưng truy vấn ràng buộc IO nhanh hơn 20% có thể là một chiến thắng lớn: trong các hoạt động bình thường, không ai sẽ nhận thấy thêm 200 ms trong các trường hợp thông thường, nhưng nếu có điều gì đó buộc truy vấn chạy với đĩa, mất 48 giây thay vì 60 có thể tiết kiệm được doanh số.

Đây không phải là vấn đề đáng lo ngại trên các hệ thống hiện đại với bộ nhớ hàng chục gigabyte và bộ lưu trữ SAN và SSD tương đối nhanh, nhưng nó vẫn còn quan trọng. Nếu một số nhà phân tích chạy một truy vấn quét bảng lớn đối với cơ sở dữ liệu OLTP của bạn, nó sẽ xóa sạch một nửa bộ đệm của bộ đệm, các truy vấn hiệu quả về lưu trữ sẽ giúp bạn quay lại tốc độ sớm hơn.