Cách đo Tra cứu khóa mỗi giây trên SQL Server


7

Tôi đang làm việc để giảm số lượng giao dịch thực hiện tra cứu chính trên Máy chủ SQL của chúng tôi.

Đầu tiên tôi muốn xác định đường cơ sở cho số bình thường hoặc có thể chấp nhận được trên số liệu đó và vì chúng tôi liên tục có các bản phát hành trong sản xuất, sau đó, tôi muốn tạo ra một tự động hóa dựa trên số đó thông báo cho tôi khi nó đi về phía nam.

Vấn đề mà tôi đang gặp phải thực sự là tìm đúng bộ đếm trên perfmon hoặc DMV SQL để lấy dữ liệu từ đó.

Tôi đã xem xét đối tượng rõ ràng SQL Server, Đối tượng phương thức truy cập , tôi không thể tìm thấy một đối tượng cụ thể. Tôi cũng đã thử các bộ đếm hoặc các khung nhìn SQL khác nhưng không thể tìm thấy nó.

Bất kỳ đề xuất sẽ được đánh giá rất cao!

Câu trả lời:


7

Tôi không biết một cách hoàn toàn chính xác và đáng tin cậy để theo dõi điều này.

Một cách để có được ít nhất một cái gì đó có khả năng hữu ích là giữ các ảnh chụp nhanh của sys.dm_db_index_usage_stats , cụ thể là user_lookupscột cho index_id 0 (Tra cứu RID) và 1 (Tra cứu khóa). DMV này có thể được thiết lập lại vì nhiều lý do, bao gồm cả khởi động lại cơ sở dữ liệu hoặc cá thể. Việc xây dựng lại (nhưng không tổ chức lại) và chỉ mục cũng xóa mục nhập DMV liên quan trên SQL Server 2012 trở lên, điều này có thể khiến mọi việc trở nên khó khăn hơn. Bạn sẽ cần phải nắm bắt thông tin khá thường xuyên và sử dụng phương pháp phỏng đoán để quyết định xem DMV có thiết lập lại giữa các lần chụp hay không.

Chỉ số sử dụng chỉ mục DMV cũng chỉ trả về số lần số lần gói có chứa Tra cứu được thực thi. Gói có chứa một Tra cứu khóa duy nhất sẽ tăng bộ đếm lên 1, bất kể số lần tra cứu thực sự được thực hiện. Nó cũng sẽ tăng ngay cả khi Tra cứu hoàn toàn không được thực hiện.

Các sys.dm_db_index_operational_stats DMV ghi lại số tra cứu singleton thực sự thực hiện, nhưng không phân biệt giữa singleton tìm kiếm trên các chỉ số trực tiếp, và những kết quả từ một khóa hoặc RID Lookup, vì vậy nó không phải là hữu ích cho mục đích của bạn.

Singleton tìm kiếm là một tên khác cho Quét thăm dò được báo cáo bởi Đối tượng Phương thức truy cập. Không có cách nào để phân biệt giữa tìm kiếm đơn lẻ 'bình thường' trên một chỉ mục duy nhất và tìm kiếm đơn lẻ xuất phát từ Tra cứu. Điều này có nghĩa là bộ đếm thăm dò Phương thức truy cập không hữu ích với bạn. Các quầy AM rất ồn ào, và không có cách nào để tương quan các quầy với một chỉ số cụ thể.


0

Một bài viết hay của Michael J. Swart dường như chỉ ra rằng việc tra cứu chính sẽ được tính vào bộ Probe Scans/secđếm theo các phương thức Access:

Tra cứu khóa ( Tài liệu khai thác Showplan )

Toán tử này còn được gọi là toán tử tra cứu bookmark. Nó luôn được tính vào bộ đếm hiệu suất thăm dò / giây. Điều thú vị là mặc dù có được một bản ghi tại một thời điểm, toán tử này thường được xem là một triệu chứng của hiệu suất kém. Đó là bởi vì số vụ hành quyết có thể trở nên lớn. Nhiều thực thi có thể giết chết hiệu suất của truy vấn. Nếu bạn tập trung vào các bộ đếm hiệu suất, bạn sẽ nhận thấy rằng mỗi lần thực hiện này sẽ được tính vào bộ đếm hiệu suất của Quét quét.

Mặc dù sử dụng bộ đếm hiệu suất sẽ chỉ cung cấp cho bạn một số. Bạn vẫn sẽ phải đào sâu vào bộ đệm kế hoạch để tìm các truy vấn cụ thể có tra cứu khóa. Điều này là có thể .

Lưu ý : Liên kết ở trên với toán tử showplan là những gì Michael liên kết đến, nhưng tôi tình cờ tìm thấy tài liệu hiện tại trong MSDN cung cấp thêm một chút thông tin hiện tại: Tham chiếu toán tử vật lý và logic của Showplan


2
Thật không may, người độc thân không Tra cứu tìm kiếm vào một chỉ mục được nhóm duy nhất cũng được báo cáo là Quét thăm dò, do đó, điều này không thể được sử dụng để phân biệt Tra cứu khóa / RID với tìm kiếm bình đẳng thành một chỉ mục được nhóm.
Paul White 9
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.